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

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

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

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

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

グループマルチテナンシーを実装するタイミング

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

労力レベル

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