An enterprise is implementing identity federation using an external SAML 2.0 Identity Provider (IdP) to enable single sign-on (SSO) to multiple member accounts within their AWS Organization. The solutions architect configures a SAML provider object in each member account and creates an IAM role named 'FederatedOperationsRole' in those accounts. However, when users attempt to federate into the member accounts from the IdP portal, they receive an error indicating that they are not authorized to perform the assume role action. Which of the following configurations is required in the trust policy of the 'FederatedOperationsRole' in the member accounts to resolve this issue?
- ADefine the Principal as the Amazon Resource Name (ARN) of the SAML provider, but set the Action to sts:AssumeRole to allow standard cross-account role assumption.
- BDefine the Principal as the root user of the member account, set the Action to sts:AssumeRole, and attach a Service Control Policy (SCP) to the Organizational Unit allowing the SAML provider to assume the role.
- Define the Principal as the Amazon Resource Name (ARN) of the SAML provider created in the member account, and set the Action to sts:AssumeRoleWithSAML.Cevap
- DDefine the Principal as the Amazon Resource Name (ARN) of the SAML provider, and set the Action to sts:AssumeRoleWithWebIdentity to support federated web access.
Cevap
Define the Principal as the Amazon Resource Name (ARN) of the SAML provider created in the member account, and set the Action to sts:AssumeRoleWithSAML.
To successfully federate using SAML 2.0, the IAM role trust policy in the target member account must trust the SAML provider. This is accomplished by setting the Principal to the ARN of the SAML provider created in the account and specifying the Action as sts:AssumeRoleWithSAML. This allows the AWS STS service to accept the SAML assertion and issue temporary security credentials.
Adım Adım Çözüm
Anahtar Kavram
SAML 2.0 Federation Trust Relationships
Tahmini Süre:2m 0s