AWS SCIM and AWS IAM Identity Center
AWS.151 Taking a look at AWS SCIM options
This is a continuation of my series on Automating Cybersecurity Metrics.
Free Content on Jobs in Cybersecurity | Sign up for the Email List
In my last post I wrote about SCIM (System for Cross-domain Identity Management).
Today we’ll take a look at how AWS implements SCIM.
AWS SCIM Documentation
If you read my last blog post you understand how SCIM works and how to use it to manage identities across systems. In my case, I was looking at SCIM in relation to using Okta with AWS.
You’ll find the AWS SCIM and SAML implementation here:
You can read the full documentation here:
The AWS documentation goes into detail if you want to build your own implementation between AWS and some third-party system that manages your identities (and IdP).
AWS explains one way to integrate with Okta here:
Where do your identities end up when you use AWS SCIM per the AWS documentation?
The document says that AWS SCIM integrates with “AWS IAM Identity Center.” That implies that the users you create will end up in what was formerly known as AWS SSO, now AWS IAM Identity Center.
Note that AWS IAM Identity Center is not the same as AWS IAM. I am not real keen on the name change which I feel tries to trick users into using what used to be called AWS SSO instead of making SSO so much better that people would want to move over to it on their own. There is a reason people aren’t clamoring to use it and changing the name doesn’t fix those problems. I wrote about how AWS might fix the problems wtih a simpler implementation here:
If you log into AWS and navigate to the AWS IAM Identity Center console, you can see how you can change the directory (your source for users) in the console.
- The first option would be to store all your users in a directory at AWS. I explained what directories are in my post on identity providers (IdPs).
- I could change this here to an External Identity Provider and choose to integrate with Okta, for example.
- There’s also an option to integrate with Active Directory, which technically could be an External Identity Provider as well, but AWS offers different mechanisms for using Active Directory in or with your AWS account.
AWS supports SCIM. It’s great that AWS is using standards and making it easier to integrate with external IdPs — unlike some cloud providers who try to maintain control for the sake of their industry dominance in a particular area.
On the other hand, I’m a bit frustrated that this approach tries to force you to use AWS Identity Center. I’ve written about some of the limitations of AWS Identity Center (SSO) when compared to AWS IAM and it’s ability to create fine-grained trust policies. The AWS CLI approach has an increased attack surface as well. I don’t like that I cannot control the roles created in my accounts and store them in source control and deploy them myself (easily).
I started reiterating those problems here but I’ll save that for another post — and a potential solution that would fix AWS IAM Identity Center — after I look at how Okta works and see if there is a solution to my problem or if I face the same or additional challenges.
If you missed my earlier posts and are not familiar with trust policies read the following post which explains what they are because this is important to understand when considering your options in the remainder of this post.
Using an IdP With AWS IAM
Well, I’m not yet sure if I can use SCIM with AWS IAM but I know I can use an IdP like Okta or Active Directory because this was possible long before AWS IAM Identity Center (AWS SSO).
Navigate to AWS IAM. Click on “Identity providers” on the left. Click “Add provider.”
Here you can see that AWS SSO (IAM Identity Center) is actually an Identity Provider for AWS IAM. It uses SAML as a way to integrate all your accounts with AWS IIC (SSO). SAML itself has a myriad of configuration problems.
The fact that the “DO_NOT_DELETE” phrase has been added to the name of this identity provider name gives some indication of the fragility of this approach. AWS is adding things behind the scenes in AWS accounts that the customer can see and break but not easily manage or control (as opposed to generating the source code and checking it into their own GitHub repo and deploying it through customer managed processes).
I wrote about how AWS could simplify the AWS Identity Center implementation and avoid SAML here:
Click on “Add provider” on the screen above. Notice that you have the option to use OpenID Connect instead of SAML.
A full discussion of OIDC vs. SAML is beyond the scope of this post. Which is better, more secure, or which one should you choose? There are many blog posts and web pages covering this topic with conflicting information.
For the answer to that question, I refer you to the specifications and research into which has contributed most to data breaches, which I don’t have time to cover in this post. Maybe later. I will also mention that, as always, it depends how you configure either one. Misconfigurations in either case can lead to devastating consequences for an organization.
AWS SCIM Attack Surface
If you plan to use AWS SCIM, one question you’ll want to be asking yourself is how someone might leverage the automation to create a backdoor user in your account.
My whole goal of this latest tangent from automating batch jobs that require MFA is to separate the creation of users from the assigning of permissions to prevent this CreateUser escalation attack:
So let’s say you have an administrator that has access to create users in Okta and you’re using SCIM to automatically sync all the changes in Okta over to AWS.
Using that process, can you separate permissions for creating a user from the permissions of granting that user access?
If an Okta administrator creates a user and adds them to a group in Okta do they automatically get all the permissions assigned to that group — in either IAM or AWS IAM Identity Center — when that data is pushed or pulled over to AWS?
In other words, using the same attack described in my CreateUser attack above, could an Okta Admin:
- Create a user in Okta
- Obtain the credentials
- Assign the user to a group in Okta
- Wait for the SCIM syncing process to complete.
- Log into AWS and do whatever that user based on the group permissions?
Or, can we somehow have separate users that create new users and other users that perform the actions that grant those users specific permissions in your AWS account?
How does MFA work if you are using Okta? Can you enforce that a specific user with a specific MFA device is allowed to take an action and only that user in AWS where AWS might not have the context to know if the correct MFA device was used?
Concerns with AWS Identity Center and Okta Integration via SCIM
In my earlier posts, I was granting permission to assume a role to users in specific AWS IAM groups. My implementation required the the user to be added in two places before they could assume a role: 1.) to the group and 2.) to the trust policy.
The trust policy granted access to specific users and could even be limited to specific MFA devices and IP addresses if I wanted to do that. That is not possible with AWS IAM Identity Center, which magically creates roles and trust policies behind the scenes for you which look something like this:
Note that the trust policy for each AWS SSO / IIC role looks the same except that it has a ID in the name above where it says “Federated.” That ID is not a user ID or a group ID. Maybe it’s a permission set ID, not sure. I haven’t looked into it because this is much less granular than the trust policies I have been creating for automation.
There is no MFA enforcement in these policies. It wouldn’t be easy to add and maintain conditions in these policies since they are controlled by AWS SSO/IIC and would possibly be overwritten in the future.
If I use Okta for federation with SCIM, it looks as though I have to use AWS IAM Identity Center and lose the ability to create and manage the trust policies associated with roles. I cannot add conditional elements to control the context in which the role assumption is allowed.
And I won’t get into the issues with AWS SSO / IIC and the CLI again which is another reason I don’t want to use AWS IIC. I also cannot restrict AWS console and programmatic access (except for billing users as of a recent change).
So I want to use AWS IAM. But will I have the same problems with the trust policies when federating to Okta when I use AWS IAM that I have with federating to AWS SSO / IIC?
Will I be able to enforce MFA or add IP restrictions or is the use of federation going to make that impossible? Will I be able to tell who did what in my AWS and Okta logs? Easily? How will I correlate AWS and Okta logs?
How would external IDs work and granting access to perform a penetration test the way I do currently, where I tell customers to set up specific roles for specific users that require MFA? An attacker needs to know I’m performing a penetration test or assessment for a customer and have not only access to assume the role but also my MFA device (or the one belonging to one of my pentesters that help me) to take action in a customer account via the AWS APIs.
And back to the point of all of this — does the way Okta works help me limit the scenario that facilitates the CreateUser privilege escalation attack?
Those are some of the questions I hope to answer in upcoming blog posts.
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2023
About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight LabNeed Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for PresentationFollow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab