Manage a multi-account AWS organization with Okta and IAM Identity Center
The purpose of this article is to configure your multi-account AWS Organization to use Okta as the primary authentication source and for managing role-based access through Okta groups.
If you are questioning what an Organization is, read this primer: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html
When you’re managing multiple AWS accounts with Organizations, I believe its best practice to restrict all logins for the top level ‘management’ account (besides for the root user locked down with MFA). This allows you to have a definitive delegation point for authentication to all of your sub-accounts. However, since billing is consolidated with Organizations at the ‘management’ account, this may not be practical for every use case. You’ll need to make decisions on how you want to grant access to the ‘management’ account, but keep in mind that it should be as restricted as possible. For the purposes of this article, we’re just going to focus on creating Okta groups for role-based access to the sub-accounts.
Assumptions:
1. You have an Okta account.
2. You have a primary AWS account with Organizations enabled.
3. You have at least 1 other AWS account joined to your ‘AWS Organization’ besides the primary ‘management’ account.
If this suits your needs, lets get started!
- AWS: In your primary ‘management’ account of your Organization, search for ‘IAM Identity Center’ and then click Enable
2. AWS: In IAM Identity Center, select ‘Choose your identity source’
3. AWS: Select the ‘Actions’ drop down menu and choose ‘Change Identity Source’
4. AWS: Select ‘External Identity Provider’, Click Next.
5. AWS: Leave your browser on the ‘Configure external identity provider’ dialog and Open a New browser tab to the Okta Administration section.
6. Okta: Navigate to ‘Add Application’, then select ‘Browse App Catalog’
7. Okta: Search for ‘AWS’ and select the ‘AWS IAM Identity Center’ application
8. Okta: Click ‘Add Integration’, then define the Application Label (you can leave it as default if you wish). Click Done.
9. Okta: Navigate to the Sign-On tab and select ‘Edit’ under settings
10. Okta: For the ‘AWS SSO ACS URL’ field, go back to your AWS tab and get the value for ‘IAM Identity Center Assertion Consumer Service (ACS) URL’. For the ‘AWS SSO issuer URL’ field, get the value of ‘IAM Identity Center issuer URL’ from the AWS tab.
11. Okta: Click Save
12. Okta: Scroll down to the ‘SAML Signing Certificates’ section and select the ‘Actions’ drop-down and download the certificate. We also need to view the IdP metadata.
13. Okta: In the new tab with IdP metadata text, we need to copy:
- The entityID value for the ‘IdP issuer URL’ field in AWS
- The SingleSignOnService Location URI for the ‘IdP sign-in URL’ field in AWS
14. AWS: Select ‘Choose File’ and upload the Okta certificate you just downloaded in step 12. Click Next.
15. AWS: Review and confirm, we know that we want Okta to take over control of user management, so we write ‘ACCEPT’ in the field and click ‘Change Identity Source’.
16. AWS: Now that the identity source has been changed, we’ll enable Automatic Provisioning. Make note of the ‘SCIM endpoint’ value and the ‘Access Token’. If you happen to forget to copy down the access token, don’t worry, you can generate a new token.
17. Okta: Now that you have the SCIM endpoint URL and Access Token copied down, switch back to your Okta tab and navigate to the ‘Provisioning’ tab and click ‘Configure API Integration’
Click the checkmark for ‘Enable API integration’
The ‘Base URL’ field will be the ‘SCIM endpoint’ value. The API Token will be the token that was provided.
Note: when copying in the ‘Base URL’, you may encounter an error “Base URL: Does not match required pattern”. This just means you need to take off the trailing slash on the URL.
Click Save.
18. Okta: So now on the ‘Provisioning’ tab, we need to click edit to the right of ‘Provisioning to App’ so we can enable:
- Create Users
- Update User Attributes
- Deactivate Users
19. Okta: If you don’t already have a group to apply, lets first create a group in Okta for the AWS_Administrators. If you already have a group created that you want to apply to the Administrators role on your AWS organization, skip to step 20.
Navigate to Directory > Groups, the click Add Group
Create a group called ‘AWS_Administrators’ (or whatever you prefer for admins on all of your accounts).
Assign your user (and any others) to the group.
20. Okta: In the ‘AWS Identity Center’ Application, we navigate to the ‘Assignments’ tab. You can assign a single user or a group of users to this application.
21. Okta: Navigate to the ‘Push Groups’ tab. Select the ‘Push Groups’ button and choose ‘Find groups by name’. Search for the ‘AWS_Administrators’ group (or whatever you named it), Select it and then click Save. Via the Magic of SCIM, it will push the group and its users out to AWS IAM Identity Center.
22. AWS: Switch back to IAM Identity Center and click on ‘Users’. You should see your user provisioned in here. Click the refresh button if you don’t see it. Do the same for Groups, you should see your Group provision now too.
Okay, now that we’re getting users and groups provisioned from Okta, we need to map Okta Groups to specific AWS roles that will be pushed down to the sub accounts. So we need to start with creating Permission Sets.
23. AWS: Navigate to ‘Permission sets’ on the left menu, then select the ‘Create permission set’ button.
24. AWS: We’ll start with using the Predefined permission set for ‘AdministratorAccess’. Select that and click next.
25. AWS: On the next dialog you can leave everything default, except take a look at the Session Duration. However long you want your admin users to stay logged in for before they have to re-authenticate, this is the value to set. I think 4–8 hours is a reasonable timeframe so its not annoying to the user throughout their work day. However, if security is paramount, leave it set to 1 hour. Click Next.
26. AWS: On the final screen, just review your settings and click Create.
27. AWS: Now that we have a permission set created, we can apply the permission set to our sub account(s). Select ‘AWS accounts’ from the left menu and then select the checkbox of the account you want to apply the group to and click the ‘Assign users or groups’ button.
28. AWS: On the next dialog, select the ‘Groups’ tab and then select the checkbox for the group you want to add. In this case, I want to add ‘AWS_Administrators’. Click Next.
29. AWS: Now select the permission set we created (AdministratorAccess) then click Next.
And on the final dialog, click Submit.
30. This will now provision the permission set down to the sub-account and you will be able to sign into the sub-account as an administrator using your Okta credentials.
You can see that the AdministratorAccess role has been applied to the sub account and it maps to the group created in Okta:
31. Now, you simply need to navigate to the AWS access portal URL. This can be found on the IAM Identity Center dashboard on the right side under ‘Settings Summary’. This access portal URL can be customized if you like, but for testing purposes, you can just visit the existing URL.
32. This should result in a login dialog that allows you to select which AWS sub account to login to.
If your user is part of multiple groups that have multiple permission levels assigned, then it would give you multiple options for logging in.
That’s it! You’ve configured your Okta IdP to manage role-based access to your AWS organization and sub-accounts.
If you want additional groups configured, just follow steps 19–29 for each group to IAM role mapping you want. This gives you quite a bit of flexibility for permissions control and the best part is, you don’t have to worry about account management in all of those AWS sub-accounts. The beauty of SSO!
If this article was helpful, I would love to hear from you in the comments!
To keep building on this configuration, view the next article in the series:
Generating Dynamic Programmatic API Token for AWS CLI on macOS
