Examkin

Question

Difficulty: Very hardMulti-Account Identity and Access Management Federation

An enterprise is implementing a hub-and-spoke identity architecture across a multi-account environment managed by AWS Organizations. The central Hub account (Account A) hosts a SAML 2.0 Identity Provider (IdP) configuration. Users must authenticate via the IdP and assume a federated broker role named IdP-Broker-Role in Account A. From there, users must perform cross-account role assumption to access a target role named Application-Admin-Role in a member Production account (Account B). The security team requires that CostCenter attributes from the IdP be dynamically passed as session tags to enforce Attribute-Based Access Control (ABAC) in Account B. Additionally, an organizational guardrail must ensure that only federated access is permitted in Account B, with no direct IAM user access. During testing, users can log into Account A but receive an 'AccessDenied' error when attempting to assume the Application-Admin-Role in Account B. The session tags are also not propagating. Which configuration changes are required to successfully establish this federated access and session tag propagation while respecting organizational guardrails?

  1. A
    In Account A, configure the trust policy of IdP-Broker-Role to trust the SAML provider with sts:AssumeRoleWithSAML and sts:TagSession. In Account B, configure a Service Control Policy (SCP) at the OU level that explicitly allows sts:AssumeRole and sts:TagSession from Account A's IdP-Broker-Role to the Application-Admin-Role. This SCP configuration grants the necessary cross-account permissions, eliminating the need to manage individual trust policies on roles in Account B.
  2. B
    In Account A, configure the trust policy of IdP-Broker-Role to trust the SAML provider with sts:AssumeRoleWithWebIdentity and sts:TagSession. Attach a permissions policy to IdP-Broker-Role allowing sts:AssumeRole and sts:TagSession on the Application-Admin-Role in Account B. In Account B, configure the trust policy of Application-Admin-Role to trust the IdP-Broker-Role ARN with sts:AssumeRole, but omit sts:TagSession as session tags are automatically verified by the SAML assertion.
  3. In Account A, configure the trust policy of IdP-Broker-Role to trust the SAML provider with sts:AssumeRoleWithSAML and sts:TagSession actions. Attach a permissions policy to IdP-Broker-Role allowing sts:AssumeRole and sts:TagSession on the Application-Admin-Role in Account B. In Account B, configure the trust policy of Application-Admin-Role to trust the IdP-Broker-Role ARN with sts:AssumeRole and sts:TagSession actions. Ensure the Service Control Policy (SCP) allows these actions and restricts access based on principal path or role ARN rather than relying on the aws:FederatedProvider key in Account B.Answer
  4. D
    In Account A, configure the trust policy of IdP-Broker-Role to trust the SAML provider with the sts:AssumeRole action. Attach a permissions policy to IdP-Broker-Role allowing sts:AssumeRole on the Application-Admin-Role in Account B. In Account B, configure the trust policy of Application-Admin-Role to trust Account A's root principal, and rely on AWS Organizations' resource tag propagation to automatically carry the CostCenter attributes without enabling sts:TagSession.

Answer

In Account A, configure the trust policy of IdP-Broker-Role to trust the SAML provider with sts:AssumeRoleWithSAML and sts:TagSession actions. Attach a permissions policy to IdP-Broker-Role allowing sts:AssumeRole and sts:TagSession on the Application-Admin-Role in Account B. In Account B, configure the trust policy of Application-Admin-Role to trust the IdP-Broker-Role ARN with sts:AssumeRole and sts:TagSession actions. Ensure the Service Control Policy (SCP) allows these actions and restricts access based on principal path or role ARN rather than relying on the aws:FederatedProvider key in Account B.
The correct option correctly configures the trust policies in both the Identity Account and the member Production Account to support SAML federation and session tagging. The SAML broker role trust policy requires the sts:AssumeRoleWithSAML action to allow IdP federation and the sts:TagSession action to ingest the CostCenter attribute as a session tag. For the cross-account transition, the target role in the member account must trust the broker role and also allow sts:TagSession so the tags carry over. Lastly, it recognizes that the aws:FederatedProvider context key is not present in cross-account role sessions assumed via AssumeRole, meaning the SCP must restrict access using alternative attributes like the principal path or role ARN.

Step-by-Step Solution

1
Configure SAML federation trust in the Hub account (Account A).
Update the trust policy of IdP-Broker-Role to target the SAML provider as the principal with the sts:AssumeRoleWithSAML and sts:TagSession actions.
This allows successful federation from the IdP and maps the SAML attributes (such as CostCenter) as session tags within the initial broker session.
2
Enable cross-account role assumption with session tags in the member account (Account B).
Configure the trust policy of Application-Admin-Role in Account B to trust the IdP-Broker-Role ARN from Account A, and explicitly allow both the sts:AssumeRole and sts:TagSession actions.
This allows the federated session to transition across accounts while preserving and accepting the CostCenter session tag for ABAC evaluation.
3
Grant permission in the Hub account to perform the cross-account transition.
Attach an IAM permissions policy to IdP-Broker-Role in Account A that allows sts:AssumeRole and sts:TagSession targeting the ARN of Application-Admin-Role in Account B.
The broker session must have permission to call AssumeRole and transmit session tags to the target member account.
4
Align the Service Control Policy (SCP) with the cross-account context.
Ensure the SCP permits the necessary STS actions, and avoid restricting member account operations using the aws:FederatedProvider condition key since it is null for cross-account assumed roles.
SCPs must act as guardrails without blocking legitimate cross-account federation paths that rely on sts:AssumeRole rather than direct SAML authentication inside the member account.

Key Concept

Hub-and-spoke SAML federation requires sts:AssumeRoleWithSAML for the initial broker session, sts:AssumeRole and sts:TagSession for cross-account propagation, and proper understanding of SCP evaluation context boundaries.
Rate this question

Topics

Multi-Account Identity and Access Management Federation

More questions from this topic