ユーザーグループのマルチテナンシーのベストプラクティス - Amazon Cognito

ユーザーグループのマルチテナンシーのベストプラクティス

グループベースのマルチテナンシーは、アーキテクチャでアイデンティティプールを持つ Amazon Cognito ユーザープールが必要な場合に最適です。

ユーザープールの ID トークンとアクセストークンには cognito:groups クレームが含まれています。さらに、ID トークンには cognito:roles クレームと cognito:preferred_role クレームが含まれます。アプリケーションでの認証の主な結果がアイデンティティプールからの一時的な AWS 認証情報である場合、ユーザーのグループメンバーシップによって、そのユーザーが受け取る IAM ロールとアクセス許可が決まります。

例えば、それぞれがアプリケーションアセットを独自の Amazon S3 バケットに保存している 3 つのテナントを考えてみましょう。各テナントのユーザーを、関連付けられたグループに割り当て、グループの優先ロールを設定し、そのロールにバケットへの読み取りアクセスを許可します。

次の図は、アプリケーションクライアントとユーザープールを共有するテナントで、IAM ロールの適格性を決定するユーザープール内の専用グループがあるものを示しています。

各テナントが共有ユーザープールに独自のユーザーグループを持つ多対 1 マルチテナンシーモデルの図。
グループマルチテナンシーを実装するタイミング

AWS リソースへのアクセスが主な懸念事項であるとき。Amazon Cognito ユーザープールのグループは、ロールベースのアクセス制御 (RBAC) のメカニズムです。ユーザープールに多数のグループを設定し、グループ優先度に基づく複雑な RBAC 決定を行うことができます。アイデンティティプールは、優先度が最も高いロール、グループクレーム内の任意のロール、またはユーザーのトークン内の他のクレームからのロールに対して、認証情報を割り当てることができます。

労力レベル

グループメンバーシップのみでマルチテナンシーを維持する労力は、低レベルです。ただし、ユーザープールグループのロールを IAM ロール選択の組み込み容量を超えて拡張するには、ユーザーのトークンにおけるグループメンバーシップを処理するアプリケーションロジックを構築し、クライアントで何をするかを決定する必要があります。Amazon Verified Permissions をアプリケーションと統合して、クライアント側の認可に関する決定を行うことができます。現在のところ、グループ識別子は Verified Permissions IsAuthorizedWithToken API オペレーションでは処理されませんが、グループメンバーシップクレームなど、トークンの内容を解析するカスタムコードを開発できます。