Question

Difficulty: HardMulti-Account Identity and Access Management Federation

A multi-national enterprise manages its workloads across multiple AWS accounts organized under AWS Organizations. The company has established SAML 2.0 federation with Okta to allow database administrators to log in and manage resources in a dedicated database account. The administrators must assume an IAM role named `DBAdminRole` in the database account.

To enforce compliance, the security team attached a Service Control Policy (SCP) to the database account's Organizational Unit (OU) that explicitly allows only Amazon RDS and Amazon DynamoDB actions, while denying all other services. To minimize administrative overhead within the database account, the team created the `DBAdminRole` without any inline or managed IAM identity-based policies, assuming the OU-level SCP would grant the necessary database permissions to the federated role.

During testing, database administrators are unable to access any resources after authenticating through Okta. Additionally, logs show that some administrators cannot assume the role at all because the role's trust policy is configured with `sts:AssumeRole` instead of `sts:AssumeRoleWithSAML`.

Which combination of actions will resolve these issues and allow the database administrators to perform their duties?

  1. A
    Update the trust policy of `DBAdminRole` in the database account to use the `sts:AssumeRole` action with the Okta SAML provider as the principal, and attach an IAM identity-based policy to `DBAdminRole` that explicitly grants the required RDS and DynamoDB permissions.
  2. B
    Update the trust policy of `DBAdminRole` in the database account to use the `sts:AssumeRoleWithSAML` action with the Okta SAML provider as the federated principal, and modify the SCP at the OU level to include an Allow statement that explicitly grants database access to the federated role principal without attaching local IAM policies.
  3. Update the trust policy of `DBAdminRole` in the database account to use the `sts:AssumeRoleWithSAML` action with the Okta SAML provider as the federated principal, and attach an IAM identity-based policy to `DBAdminRole` that explicitly grants the required RDS and DynamoDB permissions.Answer
  4. D
    Update the trust policy of `DBAdminRole` in the database account to use the `sts:AssumeRoleWithWebIdentity` action with the Okta SAML provider as the principal, and modify the database account's default IAM settings to allow SCP permissions to inherit directly to all roles that have a trust relationship with external providers.

Answer

Update the trust policy of the role to use the `sts:AssumeRoleWithSAML` action with the Okta SAML provider as the federated principal, and attach an IAM identity-based policy to the role that explicitly grants the required RDS and DynamoDB permissions.
The correct solution resolves the federation failure by updating the role's trust policy to use `sts:AssumeRoleWithSAML`, which is the correct action for SAML 2.0 federation. It also resolves the access denied errors by attaching a local identity-based policy to the role. Because Service Control Policies (SCPs) serve only as filters (defining the maximum boundary of what is allowed) and do not grant permissions directly, the federated role must have its own IAM policy to permit database operations.

Step-by-Step Solution

1
Verify and correct the IAM role trust policy for SAML 2.0 federation.
The trust policy must use the `sts:AssumeRoleWithSAML` action and set the Okta SAML provider ARN as the federated principal.
SAML-based federation requires the specific AWS Security Token Service (STS) action `sts:AssumeRoleWithSAML` to process SAML assertions. The standard `sts:AssumeRole` action only supports cross-account or service assumptions.
2
Configure the local IAM permissions for the federated role.
Attach an identity-based IAM policy to the local role in the member account that explicitly grants RDS and DynamoDB permissions.
Service Control Policies (SCPs) in AWS Organizations do not grant permissions; they only act as a maximum permission filter. A local IAM policy is required to actually grant the permissions.

Key Concept

Interaction between SAML 2.0 trust policies and AWS Organizations Service Control Policies (SCPs).
Rate this question