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

グループベースのマルチテナンシーは、アーキテクチャで 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オペレーションでは処理されませんが、グループメンバークレームなど、トークンの内容を解析するカスタムコードを開発できます。