avatarTeri Radichel

Summary

The web content discusses the concept of an Identity Provider (IdP) and its role in centralizing user authentication, comparing various approaches to managing user access across multiple cloud platforms, and emphasizing the importance of security and convenience.

Abstract

The article delves into the role of an Identity Provider (IdP) as a centralized solution for user authentication across various cloud services such as AWS, Azure, and GCP. It outlines five different methods for user access management, from creating individual accounts on each platform to using a single user directory with synchronized passwords or hashes, and finally, employing an IdP to handle authentication separately from the service provider. The author, Teri Radichel, highlights the pros and cons of each approach, including ease of use, security risks, and the challenges associated with password management and synchronization. The text also touches on the risks of Single Sign-On (SSO) solutions, advocating for a zero-trust security model and the use of Multi-Factor Authentication (MFA) to mitigate potential breaches. The objective is to explore the use of an IdP to enhance security by separating authentication from authorization, while acknowledging the introduction of new risks with third-party platform integrations.

Opinions

  • The author suggests that using an IdP is a superior method for managing user access due to its ability to centralize authentication and simplify credential management.
  • Creating individual accounts on each cloud platform is deemed easy to set up but impractical for managing a large number of users and services.
  • Password management systems are seen as convenient but introduce a single point of attack and potential issues with password resets.
  • Syncing usernames and passwords or even unique password hashes across platforms is considered error-prone and creates multiple points of failure.
  • The author emphasizes that an IdP should not expose credentials to third-party systems and should handle authentication independently, with Microsoft Active Directory being an example of a commonly used IdP.
  • The risk associated with SSO is acknowledged, particularly the potential for an attacker to gain access to multiple systems if they compromise the SSO dashboard.
  • The author advocates for always requiring MFA for new system logins, regardless of the user's location, to reduce the risk of breaches.
  • Radichel anticipates new risks when integrating with third-party platforms but views the separation of authentication and authorization as a necessary step to improve cloud security.

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
Idp
Identity Provider
Sso
Authentication
Cloud Security
Recommended from ReadMedium