Amazon Cognito
開発者ガイド

ロールの信頼とアクセス権限

これらのロールが異なる点は、それらの信頼関係です。認証されていないロールの信頼ポリシーの例を見てみましょう。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Federated": "cognito-identity.amazonaws.com" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "cognito-identity.amazonaws.com:aud": "us-east-1:12345678-dead-beef-cafe-123456790ab" }, "ForAnyValue:StringLike": { "cognito-identity.amazonaws.com:amr": "unauthenticated" } } } ] }

このポリシーでは、cognito-identity.amazonaws.com のフェデレーションユーザー(OpenID Connect トークンの発行者)が、このロールを引き受けることを定義します。さらに、トークンの aud(ここでは ID プールの ID)が、ID プールに一致する制限を作成します。最後に、トークンの amr は認証されていない値を含むことを指定します。

Amazon Cognito がトークンを作成するときに、トークンの amr を「認証されている」または「認証されていない」に設定し、認証されているケースでは、認証中に使用されるプロバイダーを含めます。これにより、amr 句を次のように変更するだけで、Facebook 経由でログインしたユーザーのみを信頼するロールを作成できます。

"ForAnyValue:StringLike": { "cognito-identity.amazonaws.com:amr": "graph.facebook.com" }

ロールで信頼関係を変更するときや、ID プール間でロールの使用を試みるときは注意が必要です。ID プールを正しく信頼するようにロールが設定されていない場合は、STS から次のような例外が表示されます。

AccessDenied -- Not authorized to perform sts:AssumeRoleWithWebIdentity

これが表示された場合は、ID プール用の適切なロールと認証タイプを使用していることをもう一度確認します。