What is an identity provider (IdP)?

ACM.148 Centralize user authentication for your organization

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Part of my series on Automating Cybersecurity Metrics. The Code.

🔒 Related Stories: AWS Security | IAM | Okta

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In my last post I wrote about security product assessments.

I’m going to be taking a look at a product in my upcoming posts. But first, I need to explain what I’m trying to do, and why. Along that, I need to explain a few terms, starting with these:

• User Directory
• Single Sign-On (SSO)
• Identity Provider (IdP)

I’m going to explain these terms using an example. Consider the following scenario and your options. I’m probably missing some pros and cons below because I’m thinking this through rather quickly, but I just want to explain a few key points.

Let’s say your company decides to use AWS, Azure, and GCP. How do you enable your users to log into each of those platforms? There are a number of ways you could solve this problem.

Option 1: Create a user in each cloud platform.

You could create an account in AWS, Azure, and GCP and create a new username and password in each account. Then when the user wants to log into each account, they would use the corresponding username and password in each one.

Pros:

• It’s easy to set up.
• If an attacker steals one set of credentials, they cannot get into all three cloud environments.
• The user hopefully has a different username and password in each account, so exposure of one set of credentials does not expose access to every cloud environment.

Cons:

• The user has to maintain three sets of credentials and keep track of them.
• When the user leaves the company, you have to remember to remove or disable the credentials in each cloud environment.
• This problem becomes exponential as the company adds more users and cloud services.

Option 2: Use a remote password management system that logs into systems for you.

The user enters the username and password for each cloud provider into a system that acts as a password manager. The user logs into the password management system which displays an icon for each cloud provider on a dashboard. When the user clicks an icon, the password management system logs into the cloud platform using the username and password it stored for that cloud platform.

Pros:

• Easy for the user.
• Different credentials for each cloud provider.

Cons:

• When the user leaves the company, you have to remember to remove or disable the credentials for each cloud environment.
• You may or may not want the third-party system to store the username and passwords for all your cloud environments.
• Although there are different credentials for each cloud provider they are all stored in one place, so the password manager becomes a single point of attack.
• Password resets may be challenging.

Option 3: Create a single user directory and sync users names and passwords to each cloud platform.

You might consider using the approach of adding all your users and their passwords to a corporate directory. A directory is a single database where you store all the information about the users in your organization and their password. That way you don’t have to keep track of users in multiple places. For this option, whenever you set up a new system, you sync the user names and passwords to the new system. That way the user can log into all the systems with the same username and password.

Pros:

• It’s easier for a user to login as they only have to remember one set of credentials.

Cons

• Multiple places where user names and passwords may be exposed.
• Syncing passwords is often a fragile and error-prone process with multiple points of failure.
• When a user leaves the company, you have to run the syncing process to update all three platforms to disable the user’s access.

Option 4: Create a single user directory and sync unique password hashes to each cloud platform.

I wrote about hashes in my book at the bottom of this post. A hash is an irreversible cryptographic representation of the password in this example. The user logs into the cloud provider. The cloud provider generates a hash. The hash is compared to the hash stored by the cloud provider.

Pros:

• It’s easier for a user to login as they only have to remember one set of credentials.
• An employee at the cloud with a hash cannot use that to log into other cloud platforms.
• A hash may not be very useful for an attacker, depending on where and how it is used by the systems.
• Each cloud platform can use a separate hash with a unique seed of the password so a hash from one platform won’t work on another (hopefully).

Cons:

• Syncing passwords is often a fragile and error-prone process with multiple points of failure.
• When a user leaves the company, you have to run the syncing process to update all three platforms to disable the user’s access.
• If the user enters the username and password at the cloud provider to generate the hash for comparison, then the cloud provider has access to the underlying username and password.

Option 5: Create a single user directory. When users login they log into and authenticate on a system outside the cloud provider, which passes information to the cloud provider indicating the user login is valid.

Pros:

• It’s easier for a user to login as they only have to remember one set of credentials.
• The username and password are never exposed to the three cloud platforms.
• When a user leaves the company, you terminate their credentials and future access in one place.
• Each cloud still manages separate sessions for access to each individual cloud.
• A single password reset works for all systems since there is one set of credentials.
• No error prone syncing that can get corrupted or fail.

Cons:

• The identity platform is now a single point of failure. If it fails — users can’t log into anything.

Identity Provider (IdP)

The last option is a true identity provider. The Identity provide contains the user credentials and does not expose them to a third-party system. The Identity Provider handles authentication of the users separately from the system the user is trying to log into. For example, many companies use Microsoft Active Directory as an Identity Provider. Users login via a page hosted by Azure Active Directory and applications integrate with AD to determine if users are properly authenticated before granting them access to systems.

There is another possible variation on identity provider. It could be a system that handles authentication when the user credentials are stored in different cloud platforms. For example, some platforms facilitate logging in with credentials stored in Facebook, Google, or Twitter. From the application’s point of view, it sends the authentication request to an identity provider. The IdP sends back an indication that the user has or has not been authenticated. The application doesn’t know or care how the user authenticated. It just knows that the user is valid.

Some may argue that last example is not a true IdP because the system that coordinates authentication is not storing the credentials or directly authenticating the users. But the point I’m trying to make here is the authentication and the authorization are handled by two different systems.

I want to see if I can use this approach to mitigate the CreateUser privilege escalation an backdoor issue I wrote about in prior posts:

There may be other scenarios, solutions, or variations on this theme, but hopefully now you can understand why a demo of a system that allows you to log into all your cloud environments is not enough to help you evaluate whether you want to use that product. And the issues I describe above are only scratching the surface of the things you would want to understand before using a product like this.

The risk associated with Single Sign-on (SSO)

Some people may consider some of the other scenarios above except for number one to be an IdP. The user logs in at one place, and then can access multiple systems. But that is really what is known as Single Sign-On (SSO).

With a Single Sign On (SSO) solution, a user can login to multiple systems with the same username and password. Whether that user name and password is stored in a single directory, hashed, or copied around is not the concern of the user. It doesn’t matter if authentication occurs in the system where the user logged in or the cloud platform they are trying to access from the user’s point of view. They only care that they don’t have to remember or manage separate sets of credentials.

The risk with SSO is similar to the multi-session compromise risk I described in this post:

If an attacker can get into a user’s SSO dashboard, then the attacker can get into anything the user is allowed to access. For this reason, it would reduce the risk of a devastating breach if the authentication platform would always require MFA when logging into a new system — and regardless of where the user is located. I once worked at a company that would not require MFA if the user was located in the office. Attackers can get onto a user’s workstation or laptop in the office, too. Use a zero-trust approach to security.

The objective — an IdP

My objective is to explore using an IdP that moves the authentication to a separate platform if possible. The access or authorization is provided by AWS roles, groups, and policies. However, when we try to integrate with a third-party platform, we may find that we have eliminated some problems while introducing others. I am already anticipating a number of potential new risks when introducing this integration, but I won’t know for sure until I get into the details.

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 Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow 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