An enterprise uses AWS Organizations to manage a multi-account structure including Production, Development, and Security member accounts. The identity team wants to implement single sign-on (SSO) using their on-premises Shibboleth SAML 2.0 Identity Provider (IdP) to allow database administrators (DBAs) to manage Amazon Aurora clusters across all member accounts. The solution must support dynamic session duration requests up to 12 hours specified by the IdP. The security department has attached Service Control Policies (SCPs) to all member Organizational Units (OUs) that permit rds:* actions. Which configuration strategy must the solutions architect implement to successfully authenticate the DBAs and grant them the required permissions?
- Establish a SAML Identity Provider pointing to the Shibboleth metadata in each member account. Create an IAM role in each member account with a trust policy that allows the sts:AssumeRoleWithSAML action from the local SAML provider. Configure the Shibboleth IdP to release assertions mapping the DBAs to these member account roles. Set the maximum session duration for each role to 12 hours, and attach an IAM policy to each role that explicitly grants rds:* permissions.Cevap
- BEstablish a SAML Identity Provider and an IAM role in a central Shared Services account with a trust policy allowing sts:AssumeRoleWithSAML. Have the DBAs federate into this central role, and then use role chaining to assume target DBA roles in the member accounts via sts:AssumeRole with a requested 12-hour duration. Rely on the trust policies in the member accounts to permit access from the central role, without creating SAML providers in those accounts.
- CEstablish a SAML Identity Provider and an IAM role in each member account with a trust policy allowing the sts:AssumeRoleWithSAML action. Set the maximum session duration for each role to 12 hours. Leave the permissions policies of these IAM roles blank, relying on the organization-level Service Control Policies (SCPs) that permit rds:* actions to implicitly grant the necessary permissions to the federated roles.
- DEstablish a SAML Identity Provider and an IAM role in each member account. Configure the IAM role's trust policy to trust the Shibboleth SAML provider using the sts:AssumeRole action instead of sts:AssumeRoleWithSAML to bypass session duration restrictions. Set the maximum session duration for each role to 12 hours, and attach an IAM policy to each role that explicitly grants rds:* permissions.
Cevap
Establish a SAML Identity Provider pointing to the Shibboleth metadata in each member account. Create an IAM role in each member account with a trust policy that allows the sts:AssumeRoleWithSAML action from the local SAML provider. Configure the Shibboleth IdP to release assertions mapping the DBAs to these member account roles. Set the maximum session duration for each role to 12 hours, and attach an IAM policy to each role that explicitly grants rds:* permissions.
The correct strategy requires configuring a SAML identity provider and role in each member account because role chaining (authenticating to a central role and then assuming member roles) limits the session duration to a maximum of 1 hour, failing the 12-hour requirement. Additionally, the trust policy must use the sts:AssumeRoleWithSAML action to allow SAML-based federation, and the IAM role must have an explicit policy granting rds:* since Service Control Policies (SCPs) act only as guardrails and do not grant permissions.
Adım Adım Çözüm
Anahtar Kavram
SAML 2.0 Federation and Session Duration Limits in Multi-Account Architectures