Okta + AWS: "Join All Roles" Setting
Hey! It’s Yasyf, Sym’s CEO. I thought I’d take the time to document some fun weekend Okta insanity, in case it was helpful for any future netizens. If you’re struggling with the “Join All Roles” option of Okta’s AWS SAML App, this post is for you.
Here’s the setup: Sym customers often use Okta’s SAML integration with AWS to delegate the ability to assume IAM Roles to specific Okta users and groups. In plain English, this means that you can say “give this Okta user the ability to assume this IAM role” (user delegation), or “give any user in this Okta group the ability to assume this IAM role” (group delegation). Pretty handy, right?
The catch lies in a little option called “Join All Roles”, which, if you’ve found this post, you’re probably familiar with. This annoying little option determines whether the group delegation functionality described above actually works, but the implementation is slightly baffling. In classic Sym fashion, our customer found something they didn’t understand, so we spent the day mapping out it’s behavior.
Docs to the rescue?
First off, let’s look at the docs for this option.
Select this check box to make AWS SAML use all roles.
If a user is directly assigned Role1 and Role2 (user-to-app assignment), and the user belongs to group GroupAWS with RoleA and RoleB assigned (group-to-app assignment), then:
Join all roles OFF: Role1 and Role2 are available upon login to AWS.
Join all roles ON: Role1, Role2, RoleA, and RoleB are available upon login to AWS.
Easy, right? Unfortunately, even if you followed that, it’s not quite the whole story.
Let’s start with some terminology you might see in the Okta UI:
- User: A single user record in Okta
- Group: A collection of Users in Okta
- App: An integration set up in Okta
- Individual: A User which has been assigned to an App directly
- SAML Role: An AWS IAM Role, represented in Okta
The last one is an important, but not always intuitive, detail. Users can be assigned to an Okta App two ways: as an Individual, or as part of a Group. If the user is already assigned to an App via a Group, they cannot be assigned as an Individual until they are removed from the Group. You can see which one of these states a User in an App is by checking the “Type” column in the “Assignments” tab.
Okta Assignment Tab
Spill the beans!
Now let’s dive into what this “Join All Roles” setting actually does!
If a User is assigned to an App via a Group, the “Join All Roles” setting appears to do nothing. Whether it is true or false, SAML Roles that are associated with the Group’s assignment to the App will be available to the User.
However, if a User is associated with an App as an Individual, the “Join All Roles” setting now applies. If it is false, the SAML Roles available to a User are only the roles manually associated with that User’s assignment to the App. If it is true, the SAML Roles available to the User are the union of the roles manually associated with that User’s assignment to the App, and, for each Group the User is a member of, the roles associated with the Group’s assignment to the App.
In other words, if a User is part of an App via a Group, don’t worry about “Join All Roles”. If instead a User is part of an App as an Individual, and you want that User to be able to assume SAML Roles based on their Okta Group membership, set “Join All Roles” in your Okta AWS App settings to true.
I hope this helped! If you’re messing around with Okta, AWS, and IAM roles, you’re probably trying to set up access controls of some sort around your infrastructure. Why not check out Sym and let us take that pain off your hands?
Sym Access enables just-in-time access to your cloud infrastructure with workflows that developers will love and ops teams can rely on. Automate access and provide ops teams visibility and reports for easy audits. Sign up for our mailing list!