Enterprise Single Sign-On (SSO) Solution using KeyCloak, Azure DevOps, .NET6 with IaC Sprinkled on Top.

/Part 1/4 - 4/9/22 /

Take control of your identity and limit what you’re exposing about you or your users.

Protocols:

SAML,OIDC, OAUTH2, WS-Fed, ADFS

Ever wonder what those Login with <Social/>buttons actually do? Why would you even want to login with your Microsoft account to a modest note taking app? They can even be aggressive at times!

But take a step back for a second and think about the problem they are trying to solve. Let’s face it, Neo doesn’t need more accounts to juggle and forget the password to, or even remember existed!

I was once weary of using those; I didn’t want them to ‘have’ my information, or, ‘know’ my Google credentials or giving Google my web footprint, whatever that means.

No, I’d rather just sign up with email, using that same Google account, and get issued a password. Literally, the weakest , form of security you can imagine.

Until, it came time to develop and deploy to production; this exact, single sign-on solution.

It wasn’t until I had worked with a few enterprise-scaled, multi-tenant, SSO solutions and wrote custom SAML libraries, that I started to see it. It’s like when you stop seeing the Company as a machine and start seeing the people instead. Maybe they were onto something.

They’ve setup a highly secure, robust and trusted means of sharing information about a user, on a per client basis. This allows you to manage an internal catalog, for example, of your company’s internal apps and/or how they connect with outside resources.

From the Start: A Refresher

To be accurate, these protocols and methods have been around for a little while. However these tech giants helped document and standardize these methods publicly, enabling a consistent, secure and highly configurable set of “Auth Flows” (more on that later). They made them cool.

This rule book and best practices of authentication patterns make your security team sleep at night all the while giving you that easy, trusted access. So, how does that app establish a link between your Google account and them? And what properties or information is possible to get about you? Can the app you’re logging into send stuff back or track you from this?

These are answered in the protocols and flows themselves as well as the user attributes made available from the IdP.

Although, to be clear, that note app cannot track other apps you’ve used

SAML

SAML is one of the older protocols for exchanging information between two trusted systems. The User’s Identity Provider has a trust with each Service Provider (Client) that’s registered to use it. They’ve exchanged keys and are set to only work with one another. Simply put, SAML is an XML-based markup language for security assertions.

You can have one IdP for many clients or many IdP’s for one client. You can even have an IdP be the IdP for your another system. It’s all about trust and clear communication in the SAML world. Which is one of its triumphs, simplicity.

Once you understand it, anyways.

Let’s start by looking at what information is being provided and how it reaches the client application. The below diagram shows the user attributes from LDAP as the base, source of truth.

Next, if there are IdP Brokers setup, (Forwarding the user to another IdP to allow sign on at the target IdP and account linking with auth flows), they may provide additional security or claims also.

Now at this point your user may look a bit different than what’s in LDAP. And that’s fine, we’re shaping data that’s leaving LDAP and our IdP, to present user fields, such as name or email, in a way that the clients can consume them. Because first they have to tell us what properties they are requesting and how those values should be accessed/mapped on the response back to the client.

Service Provider (Client)

The client’s registration that gets setup at the IdP (KeyCloak for instance), is the ticket that specific website, web application, mobile app, desktop app, needs to authenticate a specific user.

So in order for that Note taking app to even use your IdP (or Google or MSFT), they need to register and exchange information with each other. Meaning, an initial registration and certificate exchange needs to happen, manually, before a user can be authenticated with that client. Man, that sounds wordy.

The client, or Service Provider, is the application the user wants to use. There, less wordy.

Identity Provider (IdP)

The Identity Provider, often referred to as the “IdP”, is the server responsible for providing user authentication and or authorization for any given client or system.

For example; Google is an IdP for the ocean of blogs you’ve seen on the internet, or MSFT is an IdP for StackOverflow, Teams, GitHub, etc..

Most IdP’s keep a copy of the original user store while syncing changes and updates with the raw source-of-truth (such as LDAP). This copy allows you to add additional attributes or fields to your users that you’re authenticating while only leaning on the source of truth for key identifiable attributes (email, uid, cn… anything that’s unique).

What the hell does that mean?

It means you’re user’s email address can act as a unique id for Google, while having the users ‘uid’ LDAP attribute serve as the identifier for Microsoft Azure. Or perhaps you’re federating with another domain; then your user’s ‘cn’ attribute may be a unique and shared value. 🤷‍♂️, It’s up to you, it just has to be unique and a shared/requested value.

User Store (LDAP)

Any authentication/ authorization/ identity access management solution starts with a set of users and groups. Most commonly, some form of LDAP or sync is setup to be the foundation of your users. In my case, this has always been Active Directory. When new users are onboarded and key, uniquely identifiable attributes are setup, our reliant IdP should synchronize those updates and away they go.

Changes to a users attributes in LDAP will allow the account linking by external IdP’s to occur as well as define the values that the clients will ultimately be requesting about that user.

So if your solution is to use Azure Active Directory (AAD) as your company’s Brokered IdP, then in your attribute store there should live an attribute on the user object that can be used to identify a user in AAD.

For example:

LDAP Attribute: mail (josh@lavely.io) must be equal to AAD Attribute: emailAddress (josh@lavely.io)

allowing access to client in the form of a SAML request made to the IdP, Client Requests: email as NameID

Long story short, the LDAP attributes you setup here are the keystone for your entire SSO solution. They are your users keys into the common, trusted system.

IdP Brokering

While this was touched on throughout, this topic deserves a section of its own. Historically, enterprises and companies alike have managed with their own Active Directory or User Store. But with the domination of the cloud and IdaaS (Identity as a Service, like AAD, AWS, GOOGLE), the transition to a brokered IdP connection is growing exponentially.

The DoD is doing this quite well already with CloudOne (C1DL) and Akamai being the front runners of a globally managed identity solution for multiple agencies to make a users life a bit easier. A perfect example for IdP Brokering is in the case of user certificates and x509 authentication.

DoD employees all share one common card that they have, the CAC (Common Access Card). This CAC, if you don’t know, is like an UbiKey, a physical form of identification. On that card lives a user certificate that’s issued for that user explicitly, with some key identifying attributes. One of those is used to backfill a users LDAP attribute when onboarding. This sets the value that is used to link the external user to your system. To clarify:

• LDAP user attribute ‘uid’ gets set to match a property from the CAC.
• When the user gets redirected to the IdP to authenticate, to CloudOne or Akamai, and their CAC has been verified, that IdP will redirect the user back to KeyCloak with assertion in tow.
• One of those assertions coming back from the target IdP will contain a unique value that matches the ‘uid’ we set during the user on boarding process earlier.
• Once back at KeyCloak, we link the user to the external IdP and pass the request to the Requesting Client (the Note taking app)

It’s all about clear communication ahead of time and again, that initial exchange of information when registering the client with your IdP (KeyCloak).

SSO Architecture

Diagrams.

They should explain visually, what words can sometimes just clutter up. I have an endless supply of examples and metaphors that can describe this process but nothing beats a clean, well thought out diagram. Let’s look at a couple of common SAML SSO patterns and authentication flows.

IdP Initiated Login

This is when your client applications send the user to a predefined url at the IdP to let the IdP itself generate and respond to the SAML request for login. Typically this url is referred to as the “SLO” (Single Logout/Logon) url. Upon registration, the IdP registers a client with a preset Audience and redirect urls so when requested, it knows where to send that user next.

This is getting increasingly riskier and attacks have been successful when IdPs follow this pattern. If you’re using SAML, don’t use this method, I’m covering it for documentation and knowledge purposes but ultimately it should not be used, since OIDC is the preferred method these days.

SP Initiated Login

This is when a client application generates the SAML request and send it off with the user to the IdP. This request generation process encapsulates the public and private keys of the system and further verifies the client to the IdP. Upon registration of this client, a redirect or ACS (assertion consumer service) url is required. This allows the IdP to know where to send the user back after authentication.

As of the time of this writing, this is the more secure pattern and the recommended flow when utilizing SAML.

Up Next

It’s amazing you’re still with me!

We covered a lot of high level, pattern type of stuff in this article and I know it’s not the most riveting. However, a fundamental understanding of all of these pieces allows the bigger picture to come in neatly and will make you a rockstar at Identity and Access Management/ SSO.

Continue to the next article, Setup LDAP and get KeyCloak Installed, Part 2 of this 4 part series. Thanks.