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

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

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

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

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

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

労力レベル

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