Examkin

Question

Difficulty: HardMulti-Account Identity and Access Management Federation

A financial services company is designing a federated access model for its multi-account AWS environment managed by AWS Organizations. The company utilizes a centralized identity account (Hub) to federate users from an external SAML 2.0 Identity Provider (IdP). Federated users must assume cross-account IAM roles in various destination member accounts (Spokes). The security team requires that federated session tags (such as CostCenter and Department) passed by the SAML IdP are propagated transitively to the destination roles in the member accounts to support Attribute-Based Access Control (ABAC). Additionally, member account roles must restrict access to only those sessions that originated from the central federation role in the Hub account.

Which configuration strategy correctly establishes this federated trust chain while meeting the security requirements?

  1. Configure the SAML identity provider in the Hub account. Create an IAM role in the Hub account with a trust policy that permits sts:AssumeRoleWithSAML and sts:TagSession for the SAML provider. In the Spoke accounts, configure the trust policy of the destination IAM roles to permit sts:AssumeRole and sts:TagSession for the Hub account's IAM role, and enforce tag presence using aws:PrincipalTag condition keys.Answer
  2. B
    Configure the SAML identity provider in the Hub account. Create an IAM role in the Hub account with a trust policy that permits sts:AssumeRole and sts:TagSession for the SAML provider principal. In the Spoke accounts, configure the trust policy of the destination IAM roles to permit sts:AssumeRoleWithSAML and sts:TagSession for the Hub account's IAM role, relying on SAML assertion forwarding.
  3. C
    Configure the SAML identity provider in the Hub account. Create an IAM role in the Hub account with a trust policy permitting sts:AssumeRoleWithSAML. Apply a Service Control Policy (SCP) at the Root organizational level that explicitly allows sts:AssumeRole and tag propagation across all member accounts, thereby bypassing the need to configure individual trust policies or permissions on the destination IAM roles in the Spoke accounts.
  4. D
    Configure the SAML identity provider in the Hub account. Create an IAM role in the Hub account with a trust policy that permits sts:AssumeRoleWithSAML for the SAML provider. For the destination roles in the Spoke accounts, enable resource sharing via AWS Resource Access Manager (RAM) to share the Hub role with the Spoke accounts, allowing users to assume the role directly without configuring trust policies.

Answer

Configure the SAML identity provider in the Hub account. Create an IAM role in the Hub account with a trust policy that permits sts:AssumeRoleWithSAML and sts:TagSession for the SAML provider. In the Spoke accounts, configure the trust policy of the destination IAM roles to permit sts:AssumeRole and sts:TagSession for the Hub account's IAM role, and enforce tag presence using aws:PrincipalTag condition keys.
The correct configuration establishes a secure trust chain that supports transitive tag propagation. By permitting both sts:AssumeRoleWithSAML and sts:TagSession on the Hub role, the SAML assertions and their associated attributes are correctly ingested as session tags. Subsequently, by permitting sts:AssumeRole and sts:TagSession on the Spoke roles for the Hub role principal, those session tags are carried over to the destination role session, allowing for ABAC using aws:PrincipalTag condition keys.

Step-by-Step Solution

1
Configure the identity federation in the Hub account by creating a SAML Identity Provider resource and an IAM role representing the federated users.
The Hub role's trust policy permits sts:AssumeRoleWithSAML and sts:TagSession, allowing SAML assertions to be converted into AWS security credentials containing session tags.
The sts:TagSession action is required in the trust policy to permit the SAML IdP to pass session tags (such as CostCenter and Department) during the federation process.
2
Configure the cross-account trust relationship on the target roles in the Spoke accounts.
The target roles in the Spoke accounts trust the Hub role ARN and allow the sts:AssumeRole and sts:TagSession actions.
To propagate session tags transitively during a cross-account role assumption, the target role's trust policy must explicitly permit sts:TagSession in addition to sts:AssumeRole.
3
Enforce Attribute-Based Access Control (ABAC) in the Spoke accounts using policies with PrincipalTag condition keys.
Access is granted or denied dynamically based on the session tags matching resource tags or specific values.
Propagating the session tags transitively ensures they are present as principal tags (aws:PrincipalTag/TagKey) when evaluating policies in the Spoke accounts.

Key Concept

Transitive session tag propagation in multi-account SAML federation
Estimated Time:3m 0s
Rate this question

Topics

Multi-Account Identity and Access Management Federation

More questions from this topic