In order to gain more control over their access to AWS resources, Okta administrators often need to create numerous AWS roles. This allows them to manage which users have access to sensitive and/or expensive AWS resources.

The challenge this creates is the screen below, where, throughout the day, users need to switch between various roles to get their work done.

Another challenge Okta administrators face is the need to modify existing policies to cover new resources. With AWS Session Tags, you can take a new approach around attribute-based access.

As resources come and go in your AWS environment, you can set a policy that grants access based on attributes. AWS Session Tags set the appropriate context for what can be accessed, ensuring that the user always has access to the correct resources.

In this post, we’ll provide some details on how you can use Okta’s Dynamic SAML Attributes with AWS Session Tags to simplify operations, giving you more control over what your users can see in AWS, plus a faster and easier experience when logging into it.

Note: Dynamic SAML Attributes is currently in Early Access and can be enabled in your production org by contacting Okta Customer Support and asking for the feature flag OIN_SAML2_DYNAMIC_ATTRIBUTES to be enabled.

What are AWS Session Tags?

AWS Session Tags allow you to simplify your end users’ SSO experience while giving you much more precise control over what each individual user can access.

In more concrete terms, AWS Session Tags are extra attributes that an IdP like Okta can add to SAML assertions or OIDC tokens. Then, on the AWS side, you will define IAM policies with conditions that only allow access to AWS resources with tags that match what is being passed in the Session Tags set by Okta.

If you’re familiar with SAML, an AWS Session Tag is simply a saml2:Attribute where the name is prefixed with “https://aws.amazon.com/SAML/Attributes/PrincipalTag:” or contains “https://aws.amazon.com/SAML/Attributes/TransitiveTagKeys”

As you may have noted above, there are two types of AWS Session Tags: “PrincipalTag” and “TransitiveTagKeys”

A “PrincipalTag” should contain the Okta profile attribute that you want to send to AWS. Examples of attributes you might want to sent to AWS include: countryCode, costCenter, organization, division, and department.

An example of setting “costCenter” as a “PrincipalTag” is shown below:

 <saml2:Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:costCenter"         NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">     <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"                 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"                 xsi:type="xs:string">         31415926     </saml2:AttributeValue> </saml2:Attribute

The TransitiveTagKeys attribute is optional, and used to tell AWS that you want to persist a “PrincipalTag” from session to session (for example, when moving between AWS accounts).

An example of setting the “costCenter” “PrincipalTag” as a Transitive Tag Key is below:

 <saml2:Attribute Name="https://aws.amazon.com/SAML/Attributes/TransitiveTagKeys"         NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">     <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"             xsi:type="xs:string">         costCenter     </saml2:AttributeValue> </saml2:Attribute>

Note: Using TransitiveTagKeys with Okta requires that your Okta org has the SAML_SUPPORT_ARRAY_ATTRIBUTES feature enabled. If you want to make use of the optional TransitiveTagKeys attribute, you’ll need to contact Okta support and request enablement of the SAML_SUPPORT_ARRAY_ATTRIBUTES feature.

What can you do with AWS Session Tags?

Imagine that you work for a company that has three different teams, and each team has three to four projects each.

If your company wanted to give your users access to only the resources they needed, you would have to have between 3 and 12 different roles in AWS. These roles would need to map to the exact attributes or resources specific to each role, then figure out how to assign those roles. Should they be assigned based on team membership, or project membership? How would you handle projects that span multiple teams? How would you handle things when a new project starts?

No matter how you group the users and assign roles, it’s likely that your users would have multiple roles assigned to them, and they’d have to switch between roles on a regular basis.

With AWS Session Tags, you can do away with all of that complexity. Okta simply passes along the teams and projects that each user is a member of, then create policies in AWS based on those memberships.

How to configure AWS Session Tags in Okta

AWS Session Tags can be configured in Okta using the Dynamic SAML Attributes feature inside of Okta.

To configure AWS Session Tags using the example with “team” and “project” attributes as discussed above, do the following:

1. As an Admin, open the Amazon Web Services app in Okta.
2. Open the Sign On tab of the Amazon Web Services app.
3. Click the Edit button
4. Open up the Attributes (Optional) portion of the SAML 2.0 sign-on method section.

You should see a page like the one below.

Once you’ve opened the Attributes section, configure it as follows:

 https://aws.amazon.com/SAML/Attributes/PrincipalTag:team

 user.team

 https://aws.amazon.com/SAML/Attributes/PrincipalTag:project

 user.project

 https://aws.amazon.com/SAML/Attributes/TransitiveTagKeys

 {"team", "project"}

As a reminder, using the optional TransitiveTagKeys attribute requires that your Okta org has the SAML_SUPPORT_ARRAY_ATTRIBUTES feature enabled. Contact Okta support and ask for enablement of the SAML_SUPPORT_ARRAY_ATTRIBUTES feature.

Also note that this example uses custom “team” and “project” claims, which you would need to add to your Okta User Profile as well as the App User Profile for your AWS app. If you are not familiar with custom user profile attributes, access the Okta Help Center article on how to work with Okta user profiles and attributes for more details.

Once you are done adding the attributes to your AWS App in Okta, click the Preview SAML button. You should get a SAML preview that looks like this:

 <saml2:Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:team" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">   <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">user.team</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:project" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">   <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">user.project</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute Name="https://aws.amazon.com/SAML/Attributes/TransitiveTagKeys" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">   <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">{"team", "project"}</saml2:AttributeValue> </saml2:Attribute>

You may notice that the “TransitiveTagKeys” tag contains the string {"team", "project"}; this is just for the preview. The real SAML Assertion will contain the proper nested attributes, provided that the SAML_SUPPORT_ARRAY_ATTRIBUTES feature is enabled in your Okta org.

Once completed, you’ll need to create or update the policies in AWS IAM to reflect the names of attributes being passed in the SAML Assertion (“team” and “project” in this example.) For an example of how to do this, see the AWS Documentation on Session Tags.

Looking for more?

This post covered the new Session Tags feature in AWS with an example of how you might use it with Okta. This coupling gives you greater efficiency and control over your cloud resources. Haven’t used Okta for AWS yet? Try it for free by signing up for an Okta account today.

And if you’re looking for more detailed documentation, check out our Dynamic SAML Attributes article in the Okta Help Center. To learn more about AWS Session Tags, check out the AWS Documentation.