AWS Single Sign-On enables attribute-based access control for workforce users to simplify permissions in AWS
AWS Single Sign-On (SSO) now enables you to create fine-grained permissions for your workforce in AWS using attributes, such as cost center and department, defined in your AWS SSO identity source. Your administrators can now implement attribute-based access control (ABAC) with AWS SSO to centrally manage access to your AWS accounts and simplify permissions management at scale.
AWS Single Sign-On (SSO) now enables you to create fine-grained permissions for your workforce in AWS using attributes, such as cost center and department, defined in your AWS SSO identity source. Your administrators can now implement attribute-based access control (ABAC) with AWS SSO to centrally manage access to your AWS accounts and simplify permissions management at scale.
Using user attributes as tags in AWS helps you simplify the process of creating fine-grained permissions in AWS and ensures that your workforce gets access only to the AWS resources with matching tags. For example, you can assign developers Bob and Sally from two different teams to the same permission set in AWS SSO, and then select the team name attribute for access control. When Bob and Sally sign in to their AWS accounts, AWS SSO sends their team name attributes in the AWS session, so Bob and Sally can access AWS project resources only if their team name attribute matches the tag value of the project resource. If Bob moves to Sally’s team in the future, you can modify his access by simply updating his team name attribute in the corporate directory. When Bob signs in next time, he will automatically get access to the project resources of his new team without requiring any permissions updates in AWS. This approach also helps in reducing the number of distinct permissions you need to create and manage in AWS SSO as users associated to the same permission sets can now have unique permissions based on their attributes.
The new feature works with any supported AWS SSO identity source, including AWS SSO’s identity store, Microsoft Active Directory, or a Security Assertion Markup Language (SAML) 2.0 identity provider (IdP). AWS SSO provides two ways of passing attributes to AWS session for ABAC. First, regardless of the identity source used, you can select supported user attributes from AWS SSO’s identity store, and AWS SSO then passes them in the AWS session. Second, if you use a SAML 2.0 IdP as your identity source, you can also pass attributes to AWS directly from your IdP in a SAML 2.0 assertion.
AWS partners Okta, OneLogin, and Ping Identity validated end-to-end interoperability between this new capability and their identity solutions, and we look forward to additional AWS partners to support it. To learn how to connect your corporate identities to permissions rules in AWS SSO, see the AWS SSO User Guide.
It is easy to get started with AWS SSO. With just a few clicks in the AWS SSO management console, you can choose AWS SSO’s identity store, Active Directory, or a supported SAML 2.0 IdP as your identity source, and enable ABAC for fine-grained permissions in AWS. You can also configure ABAC programmatically using the AWS SDK or AWS CLI, with support for AWS CloudFormation coming soon. To learn more, visit AWS Single Sign-On.
There is no cost for AWS SSO, and it is available in the US East (N. Virginia), US East (Ohio), US West (Oregon), Canada (Central), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Seoul), Asia Pacific (Tokyo), Asia Pacific (Mumbai), EU (Ireland), EU (Frankfurt), EU (London), and EU (Stockholm) Regions.