A financial services company is implementing a multi-account AWS environment managed by AWS Organizations. The company utilizes a central Identity account to federate corporate identities from an on-premises Active Directory Federation Services (AD FS) server using SAML 2.0. Users first federate into a baseline IAM role in the Identity account. From there, they assume target IAM roles in various Member accounts using the AWS Security Token Service (AWS STS) cross-account role assumption pattern.
The security team requires Attribute-Based Access Control (ABAC) to restrict access to resources. When users federate into the Identity account, the SAML assertion includes the user's department as a session tag. However, when users attempt to assume the target IAM roles in the Member accounts while passing this session tag, the `sts:AssumeRole` API call fails with an Access Denied error.
Which of the following configuration changes is required to resolve this issue and enable session tag propagation for cross-account access?
- AConfigure the on-premises AD FS server as a SAML Identity Provider (IdP) in each Member account, and update the target IAM roles' trust policies to allow the `sts:AssumeRoleWithSAML` action instead of `sts:AssumeRole`.
- BModify the trust relationship policy of the IAM role in the central Identity account to allow the `sts:AssumeRole` action for the target IAM roles in the Member accounts, and specify the department tag in the `sts:TransitiveTagKeys` parameter.
- Modify the trust relationship policy of the target IAM roles in the Member accounts to allow the `sts:AssumeRole` and `sts:TagSession` actions for the IAM role principal from the central Identity account.Answer
- DAttach a Service Control Policy (SCP) to the organization's root that allows the `sts:TagSession` action for all resources, as this will inherit down to the target roles in the Member accounts and grant the required tag propagation permission.