A global shipping corporation is configuring federated single sign-on (SSO) to their AWS multi-account environment managed by AWS Organizations. They have established a SAML 2.0 identity provider (IdP) connection. In each member account, they have created a SAML provider entity named CorporateIdP and an IAM role named OperatorRole.
The IAM role in the member account (Account ID: 111122223333) is configured with the following trust policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:saml-provider/CorporateIdP"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
}
]
}
Users are authenticated successfully by the corporate IdP but receive an Access Denied error when attempting to assume the OperatorRole in AWS. Which of the following actions will resolve this issue and allow users to federate successfully?
- Update the Action in the role's trust policy to sts:AssumeRoleWithSAML instead of sts:AssumeRole.Cevap
- BModify the root Service Control Policy (SCP) to explicitly allow sts:AssumeRole for the SAML provider ARN, as SCPs inherit and grant trust across accounts automatically.
- CAttach a permissions policy to the IAM role that allows the sts:AssumeRole action for the SAML provider principal.
- DImplement a Service Control Policy (SCP) at the Organizational Unit (OU) level that allows sts:AssumeRoleWithSAML to bypass the role's local trust policy.