SAML SSO 101

I have been asked countless times by my professional network why I am so intrigued with SSO (Single Sign On) technologies.

The answer is not very complicated, I was amazed that not only could I login with ease but that my access was meticuliously matched to do what was necessary in my day-to-day role. Because of this curiosity I wanted to know how the redirects worked and what the configuration was behind them.

Every organization that uses SaaS must not only safeguard their authentication, but their authorization as well. These two items are not the same. You can read more about this via Okta - https://www.okta.com/identity-101/authentication-vs-authorization/

For those that are unfamiliar, but want to know more about different flavors of SSO, I will give a brief overview of SAML (Security Assertion Markup Language) here:

SAML, in the most briefest of descriptions, allows users to login with the click of a button.

There are two different assertions. IdP (Identity Provider) and SP (Service Provider)

IdP initiated SAML = Start at the Identity Provider (Okta, PingIdentity, ADFS, etc.)

-> Redirects to the Service Provider (the platform you are attempting to access).

SP initiated SAML = Start at the Service Provider (the platform you are attempting to access) -> Redirects to the Identity Provider for authentication (Okta, PingIdentity, ADFS, etc.) -> Redirects back to the Service Provider.

When configuring either assertion, you must have administrative access to the Identity and Service Providers.

Most identity providers are different with regards to their configuration, however, typically you take the following high-level steps:

Service Provider (SP):

1. Add SAML configuration

2. Insert FQDN / port numbers

3. Enter the Entity ID

4. Fill out the necessary attributes

5. Download the SP Metadata (otherwise known as your "cheat sheet")

Identity Provider (IdP):

1. Create a new web platform / SAML 2.0 application

2. Enter configuration items that can be retrieved from the SP Metadata

3. Configuration items include SSO URLs, Audience URI (SP Entity ID), Name ID, and any other attributes

4. Save the IdP Metadata with a .xml file extension

5. Return to your SP and upload this file

6. Navigate back to the IdP and choose the necessary user assignments

There you have it. That is a very quick look at the configuration and the differences between the assertions.

If you run into error messages, not only could it be a configuration issue via the IdP or the SP, but it could also be a malformed XML, or certification issue.

I can delve into those topics in a future post.