Examkin

Question

Difficulty: Very hardMulti-Account Identity and Access Management Federation

A multi-national corporation uses AWS Organizations to manage a multi-account structure with hundreds of member accounts. The corporation uses an external SAML 2.0 compliant Identity Provider (IdP) for federating access to the AWS Management Console and AWS CLI. The security team has implemented a tagging standard where all IAM roles in member accounts must be tagged with a Department key indicating which team owns the role. To enforce strict security boundaries, the security team requires that federated users can only assume an IAM role if their department membership in the corporate directory (sent as a SAML attribute) matches the Department tag of the IAM role. Additionally, this matching policy must be enforced centrally such that member account administrators cannot bypass it or misconfigure their local roles to allow unauthorized cross-department access. Which configuration strategy will meet these requirements while allowing successful federation?

  1. A
    Configure the SAML IdP to release the department attribute as a SAML attribute named https://aws.amazon.com/SAML/Attributes/PrincipalTag:Department. In each member account, configure the target IAM roles' trust policies to trust the SAML provider and allow the sts:AssumeRoleWithSAML action. Attach a Service Control Policy (SCP) to the root of the AWS Organization that denies the sts:AssumeRoleWithSAML action if the value of aws:PrincipalTag/Department does not match the value of the role's Department tag.
  2. B
    Configure the SAML IdP to release the department attribute as a SAML attribute named https://aws.amazon.com/SAML/Attributes/RoleSessionName. In each member account, configure the target IAM roles' trust policies to trust the SAML provider and allow the sts:AssumeRoleWithSAML and sts:TagSession actions. Attach a Service Control Policy (SCP) to the root of the AWS Organization that allows the sts:AssumeRoleWithSAML action if the value of aws:PrincipalTag/Department matches the value of the role's Department tag.
  3. Configure the SAML IdP to release the department attribute as a SAML attribute named https://aws.amazon.com/SAML/Attributes/PrincipalTag:Department. In each member account, configure the target IAM roles' trust policies to trust the SAML provider and allow both the sts:AssumeRoleWithSAML and sts:TagSession actions. Attach a Service Control Policy (SCP) to the root of the AWS Organization that denies the sts:AssumeRoleWithSAML action if the value of aws:RequestTag/Department does not match the value of the role's Department tag.Answer
  4. D
    Configure the SAML IdP to release the department attribute as a SAML attribute named Department. In each member account, configure the target IAM roles' trust policies to trust the SAML provider and allow the sts:AssumeRoleWithSAML and sts:TagSession actions. Attach a Service Control Policy (SCP) to the root of the AWS Organization that denies the sts:AssumeRoleWithSAML action if the value of saml:Attribute/Department does not match the value of the role's Department tag.

Answer

The configuration strategy that maps the department attribute to a PrincipalTag SAML attribute, permits both sts:AssumeRoleWithSAML and sts:TagSession in the IAM role trust policies, and uses a centralized SCP to deny the sts:AssumeRoleWithSAML action if the request tag does not match the resource tag.
The correct configuration requires mapping the department attribute in the Identity Provider (IdP) to a session tag by naming it https://aws.amazon.com/SAML/Attributes/PrincipalTag:Department. The IAM role's trust policy in the member accounts must allow both sts:AssumeRoleWithSAML and sts:TagSession to authorize STS to apply these tags to the federated session. Finally, a Service Control Policy (SCP) must be attached at the organization root to deny the role assumption if the incoming department tag (aws:RequestTag/Department) is not equal to the role's Department tag. This denies the request before the session is established and ensures compliance centrally.

Step-by-Step Solution

1
Configure the SAML Identity Provider (IdP) to pass the user's department attribute as a session tag.
The SAML assertion includes the attribute mapped to the claim https://aws.amazon.com/SAML/Attributes/PrincipalTag:Department.
This prefix is required by AWS STS to ingest the attribute as a session tag that can be evaluated during role assumption.
2
Configure the local IAM role trust policies in the member accounts to permit trust relationship actions.
The trust policies allow both sts:AssumeRoleWithSAML and sts:TagSession actions for the SAML provider principal.
Allowing sts:TagSession is mandatory whenever session tags are passed in the SAML assertion; omitting it results in an Access Denied error.
3
Implement a Service Control Policy (SCP) at the root level of the AWS Organization.
The SCP contains a Deny statement on sts:AssumeRoleWithSAML with a condition checking if aws:RequestTag/Department matches the dynamic resource tag value ${aws:ResourceTag/Department}.
This centrally enforces the department matching boundary across all member accounts, preventing local administrators from bypassing the security requirements.

Key Concept

SAML 2.0 Session Tagging and Policy Guardrails in Multi-Account Organizations
Estimated Time:3m 0s
Rate this question

Topics

Multi-Account Identity and Access Management Federation

More questions from this topic