An enterprise is migrating its identity architecture to a federated model. The solutions architect has established a SAML 2.0 federation between the corporate Identity Provider (IdP) and AWS Organizations. Users must federate directly into a shared services member AWS account and assume a specific role called NetworkEngineer to manage network resources. However, when users attempt to federate from the corporate portal, they receive an error indicating they are not authorized to perform the role assumption. Which configuration change is required to resolve this federation error?
- AModify the trust policy of the NetworkEngineer role in the shared services account to allow the action sts:AssumeRole, and set the Principal to the external SAML provider's metadata URL.
- Update the trust policy of the NetworkEngineer role in the shared services account to allow the action sts:AssumeRoleWithSAML, and set the Principal to the ARN of the SAML provider created in the shared services account.Cevap
- CCreate a Service Control Policy (SCP) that allows the sts:AssumeRoleWithSAML action, and attach it to the Organizational Unit containing the shared services account.
- DConfigure the trust policy of the NetworkEngineer role in the shared services account to trust the root user of the AWS Organizations management account and allow the sts:AssumeRole action.
Cevap
Update the trust policy of the NetworkEngineer role in the shared services account to allow the action sts:AssumeRoleWithSAML, and set the Principal to the ARN of the SAML provider created in the shared services account.
For direct SAML 2.0 federation to succeed, the target IAM role's trust policy must explicitly trust the SAML provider created in that specific AWS account by referencing its ARN as the principal and permitting the sts:AssumeRoleWithSAML action.
Adım Adım Çözüm
Anahtar Kavram
SAML 2.0 Role Trust Policy Configuration