IdP & SAML - We bring light into the darkness

08.06.2022•Tom Trapp
Cloud Identity Provider SAML Single Sign On

After Stefan has already shown us a practical example on the topic of single sign-on with the identity provider KeyCloak in his TechUp on SSO with KeyCloak and Angular, today we want to take a step back and look at all the theory surrounding the topic of IdP. Here we want to look at the theory and history behind the concept of the IdP, as well as its most well-known option, SAML.

Identification vs. Authentication vs. Authorisation

To begin with, we would like to explain some important terminology around the topic of IdP or user logon in general on the web.

  • Identification: Who are you?

    • Identification states who or what you are.
    • This is classically done via a user name, an ID or another unique user feature such as an e-mail address.

  • Authentication: Prove who you are!

    • Authentication proves that the given identity is correct.
    • This is usually done using a combination of username/password, a one time password (OTP), a PIN or another security feature.

  • Authorisation: What are you allowed to do?

    • Authorisation states which rights you have to which resource.
    • This is classically done via a Role Based Access Control (RBAC) or another system for authorisation management.

It is important to note that these steps build on each other in this order.

IdP?

An Identity Provider (IdP) is a service, nowadays often cloud-based, that verifies the identity of a “Principal “. A principal is an entity that can be authenticated by a system such as the IdP. This can be not only a normal user, but can also refer to a technical user, a system, a service or a network component. Basically, each entity can be a principal, which can be identified and authenticated. Authorisations can then be assigned to the principal.

An IdP often includes a service for user authentication. The so-called Relying Party (or in the SAML context: Service Provider), for example a web application, outsources the user authentication to a trusted Identity Provider. All flows, templates for the input masks, etc. are then also located in the IdP. The Relying Party then receives a fully authenticated principal back from the IdP, the user is thus logged in. The actual user data is usually not stored directly in the IdP, but in a directory such as a LDAP.

This process is also called Federation. The IdP was previously connected to one (or more) Relying Parties, both trust each other. Thus there is a Single Control Point for Authentication, all systems rely on the IdP and do not need to perform authentication themselves.

Important keywords:

  • Realm: A logical grouping of security policies, flows, users and other items required for the authentication / authorisation process. Often a top-level domain represents a realm as an isolated client on the IdP.
  • Level of Assurance (LOA): The level of confidence of the correctness of the user’s identity.
  • Zero Trust: Various concepts and principles of how policies should be applied in the IAM domain. We have already published this TechUp on Zero Trust, check it out!

SSO

An important keyword that is often heard around the topic of IdP: SSO. 🤔

With the single sign-on (SSO) authentication concept, a principal can be recognised and used across multiple systems. The user only has to log on once for this and is logged on in all connected but still independent systems. A good example of this is the Google Suite. If you are logged in to Gmail, you are automatically logged in to all other Google services, such as Google Calendar, via SSO. It is important that not only logging in but also logging out works consistently.

SAML

Now let’s take a closer look at the first security protocol that most IdP’s support.

The Security Assertion Markup Language (SAML) is an open standard, an XML namespace and a protocol that allows authentication and authorisation data to be passed from an IdP to a Service Provider (SP). Specifically, SAML provides functions to describe and transmit security-related information correctly and securely. It is often used for single sign-on use cases.

SAML was developed in 2001 (!) by the so-called OASIS consortium, which included Microsystems, IBM, Nokia and SAP. After SAML 1.1, the standard SAML 2.0 was published in 2005, which is still in use today and is not backwards compatible with SAML 1.1. SAML itself only works with HTTP-based systems such as a browser.

Important keywords

  • Identity Provider (IdP): Verifies that the user is who they say they are. Sends data and access rights back to the SP (see above).
  • Service Provider (SP): The target application, web application or generally a service, requires the authentication of the user by the identity provider, as the user is to be granted permissions (also called Relying Party).
  • Assertion: An XML document sent by the IdP to the SP contains information about the user, his rights and the authentication used. The document is signed with an X.509 certificate to ensure authenticity. It also contains metadata such as conditions (how long it is valid for, etc.) and an issuer ID.
  • Metadata File: An XML file containing the SAML configurations, certificates and other information for IdP and SP that must be exchanged. The correct config must exist on both sides for the SAML flow to work. The Metadata Exchange is used to establish the trust between SP and IdP.
  • Bindings: Defines how assertions and messages are sent between IdP and SP. Classically via HTTP Redirect Binding or via HTTP Post Binding.
  • SAML Context Classes: Shows which authentication method was used. Sent to the SP in the assertion, SP can accept or reject this and ask for a stronger authentication method. Can be specifically extended with own methods. For example: “urn:oasis:names:tc:SAML:2.0:ac:classes:Password” for the Password Auth Method.

Technically, SAML uses a session cookie in the background. This cookie is sent to the service provider for all requests. This means that no direct connection between SP and IdP is necessary.

Flow

Basically, the flow in the SAML context is easy to explain, but one should distinguish between two types. It should be noted here that the data transmission, whether a POST or a redirect is made, can differ depending on the binding.

IdP-Initiated Flow

With IdP Initiated Flow, the user requests the IdP directly. There, an IdP session is created for the user if it does not already exist. The user is authenticated and the SAML assertion is then sent to the client and then to the SP.

SAML_IDP_init_flow1.png

  1. user calls the IdP directly
  2. user enters his login data on the IdP
  3. the IdP authenticates the user, issues a SAML assertion and sends this to the user
  4. the user agent sends the assertion to the SP via a POST request (depending on the binding).

A session is then started between the user agent and the SP and the user is correctly recognised in the SP.

SP-Initiated Flow

With SP-initiated flow, the first call goes directly to the SP. The SP recognises that no session exists yet and sends a “Request for Authentication Message” via redirect to the IdP. The IdP then takes care of the authentication, creates a session and the SAML assertion is sent to the SP via the user agent.

SAML IdP SP initialed flow

  1. user calls the SP
  2. since the user is not authenticated, the SP sends a redirect to the IdP, called “request for authentication
  3. via the redirect, the user reaches the IdP
  4. after entering the credentials, the user is authenticated
  5. the SAML assertion is created by the IdP and sent via the user agent…
  6. … sent to the SP

A session is then started between the user agent and the SP and the user is correctly recognised in the SP.

This is usually the classic way, as the user wants to go directly to the application and the application then makes the redirect to the IdP with all the parameters, etc.

Advantages

  • Increased security
  • Ideally, only one username / password combination is required
  • Cost reduction, as user management is done centrally
  • User experience is enhanced thanks to SSO
  • SAML support is more widespread

Disadvantages

  • Single point of failure = IdP
  • Theft of the session cookie enables misuse of the session

Briefly summarised

Let’s assume we want to buy a portion of fries at a street festival. However, at the chip shop we find out that a personalised receipt is required for the chips. So we go to the cashier, give our name, the code word and whether we want ketchup or mayo and pay for the fries. After our details have been checked, we walk to the chip shop with our receipt in hand and now receive our chips! 🍟

In this example, the chip shop acts as a service provider (SP). You can only get your fries with a receipt, the SAML assertion. You get this receipt at the cash register after you have registered there in person. The cash register acts as an identity provider (IdP). The code word (metadata & certificate) between the SP and the IdP acts as a federation, a trust exists between both entities.

Depending on whether I go directly to the checkout or first to the chip shop, I have either an IdP or an SP initiated flow.

Outlook

In the next part of the Identity & Access Management (IAM) series we will take a closer look at OAuth and OIDC! Stay tuned! 🚀

Tom Trapp

Tom Trapp – Problemlöser, Innovator, Sportler. Am liebsten feilt Tom den ganzen Tag an der moderner Software und legt viel Wert auf objektiv sauberen, leanen Code.