Identity Management System

• example of identity providers (IdP): Okta, ADFS, ForgeRock
• in real world, there will usually be a mixture of applications using different authentication mechanism, some using SAML, some using OIDC.

Security Assertion Markup Language (SAML)

• a popular authentication mechanism for SSO
• other alternative mechanism are OAuth/OIDC and AD directory services

SAML Theory & Terminology

• Subject - End User
• User Agent - The Browser
• Identity Provider (IdP)
• Service Provider (SP) - E.g. SaaS Application
• Circle of Trust
• SAML Metadata
• SAML Assertion
• Protocol Binding
• Subject - User of Application
• XML - SAML's Requests & Response data format
• HTTP-Redirect
• HTTP-POST
• Entity ID - Identifier associated with SP & IdP
• Relay State
• Relying Party (refer to the SP too)
• Assertion - the XML within the response that contains user and group attributes
• Attributes - sometimes called SAML claims
• Assertion Consumer Service (ACS) URL

IdP

• is responsible for authenticating end users, managing their account, and issuing SAML assertions about them.

SP

• The provider of the service or application that the end user is trying to access.
• has a trust relationship with the IdP, which enables the SP to rely on the assertions it receives from the IdP.

Single Sign-On (SSO)

• The ability for an end user to authenticate once but gain access to multiple applications, without having to authenticate separately to each one.

Trust Relationship

• to be set up between IdP and SP
• a quick way to achieve this trust is to exchange the SAML metadata file (an XML formatted) file.

SAML's Protocol Binding

• defines what forwarded mechanisms to use
• can be HTTP 302 redirect or HTTP Post
• either way, a similar request is being sent to the SAML IdP from the browser (user agent)

SAML Authentication Flow

1. SP Initiated SAML Single Sign On
2. IdP Initiated SAML Single Sign On

1. SP Initiated SAML SSO

SP initiates the SAML Request Redirect back to the browser after User access the SP from the browser.

Sample SP Initiated SAML SSO Flow

1. User accessed Application on Browser
2. Browser (as agent) forwards Request to IdP
3. IdP displays login screen
4. IdP authenticates the user against directory
5. IdP forwards Response to Application

Understanding Entity ID

Both the IdP and SP are entities and both have Entity ID associated with them. With Entity ID, we can identify who is the issuer of a request or who is the recipient of the response.

Understanding Relay State Here

When User first requests (1) a URL (e.g. SaaS Application), this accessed URL is usually passed as Relay State when (2) Browser forwards the request to IdP. And it will be returned in the Response (5) for application to act on.

2. IdP Initiated SAML SSO

IdP initiates the SAML Response. The application gets a SAML Response without it requesting an authentication.

Sample IdP Initiated SAML SSO Flow

1. User accesses & logs into IdP
2. IdP authenticates the user against directory
3. IdP creates a Response XML with the right assertion (XML within the response that contains user and group attributes)
4. The assertion is digitally sign and encrypted
5. The Response is being sent to the SP

Understanding Relay State Here

Since it is not SP-initiated, there is no initial URL to store as Relay State. In this case, the IdPs can store a default Relay State to sent back to the Application on Browser. Application gets the response from the IdP and verify the assertion.

Reference

• https://developer.okta.com/docs/concepts/saml/
• https://backstage.forgerock.com/docs/am/7/saml2-guide/saml2-introduction.html