1. What is SSO and why it’s becoming essential for enterprise applications?

SSO & IAM

1. SSO belongs to the application management area, usually we have an IAM (Identity and Access Management) system to manage user access, for example: Azure Active Directory.
2. Our goal is to give the IAM users (e.g., Azure AD users) the SSO capability.

What does SSO capability mean?

• you only need to login once to your IAM system (e.g., login to your Microsoft account), then you don’t need to login again to the applications which are SSO integrated with your IAM (e.g., slack, github…)

In short, the Slack (Service Provider) has delegated the user authentication part to Azure AD (Identity Provider).

It’s authentication, not authorisation right?

Yes! SSO is the modern authentication approach.

• Authentication = prove you are an employee of company A
• Authorisation = prove you are a developer of company A (so you can access dev servers)

So in terms of user role and permission management, it is still the SP’s (e.g. Slack) job, not IDP (e.g., Azure AD)’s responsibility.

2. Authentication

Authentication is basically included in the user login process, and we have two approaches to achieve this.

Traditional Login (type username and password)

Modern Login (IDP issue token, server verify it)

3. How does SSO work?

We are focusing on SP-Initiated SSO because we are not using IDP-Initiated SSO and it has security vulnerabilities.

To learn more about the IDP-Initiated approach drawbacks, check this course .

In this example, we’ve got website 1 and website 2, both integrated with the IdP to enable SSO, so both websites are SP (service provider).

Let’s look at the blue part first.

Prerequisite

1. IdP and website1 have SSO contract (based on SAML or other protocols)
2. IdP and website2 have SSO contract (based on SAML or other protocols, can be different from website1)

SSO process (1st time login)

1. user browser access website1 (HTTP request)
2. website1 responses with a redirect request (authentication request) to the IdP (through user browser)
3. user sees the IdP login screen and logs in through IdP
4. IdP issues a token to the user browser (http post request) and then it goes back to Website1 to be verified (we will talk about verification of token later) Note: after the first IdP successful login, user browser will have an IdP session and user doesn’t need to login again to access website2.
5. once the IdP token is verified, website1 will send a cookie to user browser, this cookie is handled by website1 and there’s no IdP participation.

SSO process (2nd time login)

Let’s take a look at website2, assuming we have logged in to IdP successfully when accessing website1.

Note: I have copied the same steps from 1st login and stroke out the unrequired steps.

1. user browser access website2 (HTTP request)
2. website2 responses with a redirect request (authentication request) to the IdP (through user browser)
3. user sees the IdP login screen and logs in through IdP
4. IdP issues a different token to the user (http post request) and then it goes back to Website2 to be verified (we will talk about verification of token later)
5. once the IdP token is verified, website2 will send a cookie to user browser, this cookie is handled by website1 and there’s no IdP participation.

4. SSO Contract

Imagine we are running a company called Mango, Mango is a Service Provider, Mango needs to integrate their service with IdP to enable SSO.

To understand SSO in depth, we need to know how to establish the contract between IdP and SP.

Note: User also need to have a contract sort of thing with IdP, but let’s don’t worry about this, because the IdP will handle this through it’s own user management system.

Protocols

There’re different protocols to be used, the two popular ones are SAML and OpenID connect.

OpenID is using json, and SAML is using XML.

We’re focusing on SAML integration for now, but in the future we might need to consider OpenID integration as well.

SideNote: OpenID Connect vs OAuth 2.0

OpenID Connect is an authentication layer on top of OAuth 2.0, an authorization framework.

How to establish SSO contract between SP and IDP (using SAML protocol) ?

Let’s think about what are the information that needs to be exchanged.

Mango is a service provider, we have a website and we want to enable the users to login to Mango website through an Identity Provider (assuming it’s using Azure AD as IdP).

Objective: Mango (SP) needs to establish a contract with Azure AD (IdP).

User will open Mango website page, and it will redirect to Azure AD login page, once user is logged in, Azure AD sends the response back to Mango website.

Okay, in this workflow, we need several endpoints.

1. Where is SP redirecting to IdP?
2. Where is IdP sending the response to SP?

Also, we need to know how to link the SP user with the IdP user, and make sure the entire authentication process is secured (we cannot let anyone impersonate our user!).

That’s why we need something called SAML metadata from both SP and IdP, inside the metadata file, all the questions will be answered and both party can configure their application based on the metadata contract and fulfill the SSO functionality.

Example of SP metadata (provided by Mango)

The main things to note here:

1. entityid is the SP identifier (we are using portal address here)
2. we have 2 keys, 1 for signing, 1 for encryption (detail will be discussed later)
3. we have given the IdP our reply address (AssertionConsumerService location) and defined the binding (HTTP-POST)
4. we have set the NameIDFormat (how to connect users between IdP and SP)

Example of IdP metadata (provided by IdP)

The main things to note here:

1. ID is the IdP identifier
2. IdP also have 2 keys, 1 for signing, 1 for encryption (detail will be discussed later)
3. IdP has defined their endpoint and binding method (we can use the one agreed on, e.g., http-post)
4. there’re a lot of info but we just need to focus on what we need to use.

5. What is a SAML assertion and why it’s important?

A SAML assertion is created by IdP with the user related info.

Once user logged in from IdP page, IdP will send a response back to the SP reply address.

The response contains SAML protocol related info and the SAML assertion.

The assertion will be protected (it could contain user sensitive data, e.g., email).

6. Metadata

SP metadata

• (required) Identifier (Entity ID)
• (required) Reply URL (Assertion Consumer Service URL)
• (required) Public key

IdP metadata

• (required) Public key
• (required) Login URL