Examkin

Question

Difficulty: MediumMulti-Account Identity and Access Management Federation

A media streaming company is implementing a federated authentication solution for its engineering team to access resources across multiple AWS accounts within an AWS organization. The company uses Okta as its external identity provider (IdP). To satisfy legacy integration requirements, the solutions architect must configure direct SAML 2.0 federation to target IAM roles in the member accounts, bypassing AWS IAM Identity Center. The engineers must be able to federate into a role named DeveloperDeploymentRole in the target member accounts. Which two configuration steps are required to establish this federated access?

  1. Configure a trust policy on the DeveloperDeploymentRole in the target accounts that lists the SAML provider as the federated principal and allows the sts:AssumeRoleWithSAML action.Answer
  2. Configure the SAML application in Okta to include a SAML attribute named https://aws.amazon.com/SAML/Attributes/Role that contains the comma-separated Amazon Resource Names (ARNs) of the target IAM role and the SAML provider.Answer
  3. C
    Configure an IAM policy in the target accounts allowing the sts:AssumeRoleWithWebIdentity action and attach it to the developers' local IAM users.
  4. D
    Create a Service Control Policy (SCP) at the Root OU level that allows the sts:AssumeRoleWithSAML action for Okta users to grant access to the target member accounts.
  5. E
    Create a SAML identity provider in each target account and attach an IAM policy to the provider object that explicitly grants sts:AssumeRole permissions to Okta groups.

Answer

Configure a trust policy on the DeveloperDeploymentRole in the target accounts that lists the SAML provider as the federated principal and allows the sts:AssumeRoleWithSAML action, and configure the SAML application in Okta to include a SAML attribute named https://aws.amazon.com/SAML/Attributes/Role that contains the comma-separated Amazon Resource Names (ARNs) of the target IAM role and the SAML provider.
The correct configurations involve creating a trust relationship using the sts:AssumeRoleWithSAML action on the target role in the member accounts, referencing the SAML provider. Additionally, the IdP must send the specific role attribute containing the comma-separated role and provider ARNs to complete the authentication handshake.

Step-by-Step Solution

1
Set up the IAM trust policy on the target role.
The DeveloperDeploymentRole in the target member accounts is configured to trust the SAML identity provider ARN.
This is necessary so that AWS knows which external identity provider is authorized to assume the role via SAML.
2
Configure SAML assertion attributes in the Okta portal.
The Okta SAML assertion is configured to send the role and provider ARNs in the https://aws.amazon.com/SAML/Attributes/Role attribute.
This attribute is mandatory for AWS to successfully map the federating identity to the target role during the sts:AssumeRoleWithSAML operation.

Key Concept

Direct SAML 2.0 federation and IAM role trust relationships in multi-account environments
Estimated Time:2m 0s
Rate this question

Topics

Multi-Account Identity and Access Management Federation

More questions from this topic