カスタム属性マルチテナンシーのベストプラクティス - Amazon Cognito

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

カスタム属性マルチテナンシーのベストプラクティス

Amazon Cognito は、選択した名前のカスタム属性をサポートします。カスタム属性が役立つシナリオの 1 つは、共有ユーザープール内のユーザーのテナンシーを区別する場合です。などの属性に値をユーザーに割り当てるとcustom:tenantID、アプリケーションはそれに応じてテナント固有のリソースへのアクセスを割り当てることができます。テナント ID を定義するカスタム属性は、アプリクライアントに対してイミュータブルまたは読み取り専用にする必要があります。

次の図は、アプリケーションクライアントとユーザープールを共有するテナントと、それらが属するテナントを示すユーザープール内のカスタム属性を示しています。

各ユーザーが共有ユーザープールに独自のテナントユーザー属性を持つ many-to-one マルチテナンシーモデルの図。

カスタム属性がテナンシーを決定する場合、単一のアプリケーションまたはサインイン URL を配布できます。ユーザーがサインインすると、アプリはロードするアセット、適用するブランド、表示する機能を決定するcustom:tenantIDクレームを処理できます。ユーザー属性からの高度なアクセスコントロールの決定については、Amazon Verified Permissions で ID プロバイダーとしてユーザープールを設定し、ID またはアクセストークンの内容からアクセス決定を生成します。

カスタム属性マルチテナンシーを実装するタイミング

テナンシーが表面レベルの場合。テナント属性は、ブランド化とレイアウトの結果に貢献できます。テナント間で大幅な分離を実現する場合、カスタム属性は最適な選択肢ではありません。MFA やホストされた UI ブランドなど、ユーザープールレベルまたはアプリクライアントレベルで設定する必要があるテナント間の違いは、カスタム属性が提供しない方法でテナント間の区別を作成する必要があります。ID プールを使用すると、ID トークンのカスタム属性クレームからユーザーから IAM ロールを選択することもできます。

労力レベル

カスタム属性のマルチテナンシーは、アプリケーションに対するテナントベースの承認決定の義務を転送するため、労力のレベルが高い傾向があります。OIDC クレームを解析するクライアント設定、または Amazon Verified Permissions を既に熟知している場合、このアプローチには最低レベルの労力が必要になる場合があります。