Privacy Policy
© 2025 linux101.dev

SAML SSO (Single Sign-On) Process

Introduction to SAML and its Roles

Single Sign-On (SSO) is a user authentication process that allows a user to access multiple applications with one set of login credentials. It enhances user experience by reducing password fatigue and streamlining the login process.

It is implemented using the SAML protocol which is built on top of HTTP protocol and defines three main roles:

  • Subject: The user who is trying to access a service.
  • Identity Provider (IdP): The service that authenticates the user and provides identity information.
  • Service Provider (SP): The application or service the user wants to access.

Single Sign-On (SSO) Process

1. Login Initiation

The user visits the login page of a SaaS application (Service Provider - SP) and provides their work email address (e.g., @company.com). The application recognizes the domain and knows that the user should be redirected to the company's authentication system.

2. Authentication Request

In this point the SP will return an HTTP 302 response with a Location header, which contains the URL for logging in to the IdP. Here is more details:

The SaaS application generates a SAML authentication request. This is an encoded XML document that contains the unique Entity ID of the SaaS application. This is how the SP informs the IdP who it is. The SP then sends HTTP Response with status 302 (Redirect) and redirects the user's browser to the login URL of the Identity Provider (IdP), adding the request to the URL.

The redirection URL is stored in a Location header of the HTTP response sent by SP. For example:

https://idp.example.com?SAMLRequest=...

The SAML Request is given as query parameter: XML compressed by GZIP and coded using Base64.

Note: Alternatively, the user may skip points 1 and 2 and use a special, dedicated company URL, which immediately initiates the SSO process.

3. Authentication at the IdP

The browser reaches the IdP. The IdP server reads and verifies the authentication request, recognizing which application the user intends to log in to. It prompts the user to enter their login and password (and often a second factor, like an MFA code). After successful authentication, the IdP:

  • Creates a global session for the user.
  • Saves a record in its database that the user is logging in to a specific application (SP).
  • Generates a SAML token (SAML Assertion). This is a digitally signed XML document that contains user information (e.g., email, first and last name, etc.) and is signed with the IdP's private key.

4. Sending the Token to the SP

The IdP redirects the user's browser back to the SaaS application, sending the SAML token in a hidden HTTP POST request. The user's browser does not store this token.

5. Verification and Authorization at the SP

The SaaS application receives the SAML token. At this point, the crucial verification and authorization stage begins:

  • Signature Verification: The SP uses the IdP's public key (which was previously manually exchanged in metadata during SP-IdP communication configuration) to verify the digital signature on the token. If the verification is correct, the SP knows that the token is authentic and comes from a trusted IdP.
  • Authorization (Permission Check): The SP checks if the user has the right to access the application, for example, whether their profile has an available license assigned as part of the Enterprise plan.

6. Session Establishment

If the verification and authorization were successful, the SP:

  • Creates a local session for the user.
  • Generates a session cookie and sends it to the user's browser. From now on, this cookie will be used for authorization in subsequent requests.
  • Redirects the user to the application's main page.

Important: If authorization fails (e.g., due to a lack of a license), the SP rejects the login and redirects the user to an error page. It does not notify the IdP, which is a known limitation of the protocol, and is why Enterprise systems often need to supplement this process with additional logic.

Single Logout (SLO)

Single Logout (SLO) is a mechanism that allows a user to log out of all associated services at once by clicking "Log out" in one of them. This process is crucial for security.

1. SP-initiated Logout:

The user clicks "Log out" in the SaaS application. The application (SP) generates a Logout Request, which is a digitally signed XML. The request contains unique data such as a request ID (ID) and a timestamp (IssueInstant). The SP then sends an HTTP 302 response to the browser, which redirects the user to the IdP's logout URL.

2. Logout at the IdP:

The IdP receives the logout request, verifies it (checks the digital signature with the SP's public key), and closes the user's global session. Because the IdP remembers which applications are synchronized with its session, it can log the user out of all of them.

3. Logout at other SPs (optional):

The IdP can send subsequent logout requests to other applications where the user was logged in, instructing them to terminate the local session.

4. Logout Response:

After the process is complete, the IdP redirects the user's browser back to the SP. It returns an HTTP 302 response that contains a Logout Response in the query parameter (SAMLResponse). The browser is then redirected to a page, such as "Logged out successfully."

Unlike login, logout often requires two-way communication between the SP and the IdP, but always through the user's browser.

Examples of SAML Requests

Here are examples of the XML documents used for login and logout, before they are compressed and encoded. These are the core messages exchanged between the SP and the IdP.

SAML Login Request (AuthnRequest)

This request is sent by the SP to the IdP. It asks the IdP to authenticate the user and return a token.

<samlp:AuthnRequest ID="_123a1a123a1a123a" Version="2.0" IssueInstant="2023-10-27T12:00:00.000Z"
                  Destination="https://idp.example.com/sso/login"
                  AssertionConsumerServiceURL="https://sp.your-company.com/saml/acs"
                  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
  <saml:Issuer>https://sp.your-company.com/saml</saml:Issuer>
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ds:SignedInfo>
      <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
      <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
      <ds:Reference URI="#_123a1a123a1a123a">
        <ds:Transforms>
          <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
          <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
        </ds:Transforms>
        <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
        <ds:DigestValue>EXAMPLE_DIGEST_VALUE_HASH_OF_REQUEST</ds:DigestValue>
      </ds:Reference>
    </ds:SignedInfo>
    <ds:SignatureValue>EXAMPLE_SIGNATURE_VALUE_ENCRYPTED_HASH</ds:SignatureValue>
    <ds:KeyInfo>
      <ds:X509Data>
        <ds:X509Certificate>EXAMPLE_X509_CERTIFICATE</ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
  </ds:Signature>
</samlp:AuthnRequest>
  • ID: A unique identifier for this specific request.
  • IssueInstant: A timestamp when the request was generated.
  • AssertionConsumerServiceURL: The URL on the SP's server where the IdP should send the user back with the SAML token.
  • <saml:Issuer>: The unique Entity ID of the Service Provider. This is how the IdP identifies the requesting application.
  • <ds:Signature>: The digital signature block that ensures the request's authenticity and integrity. It contains:
    • <ds:SignedInfo>: Details about the signing process, including the signing and digest algorithms.
    • <ds:SignatureValue>: The actual signature, which is the encrypted hash of the AuthnRequest message.
    • <ds:KeyInfo>: Contains the public key (or a certificate reference) used to verify the signature.

SAML Logout Request

This request is sent by the SP to the IdP when a user initiates a logout.

<samlp:LogoutRequest ID="_432b1b123a1a123a" Version="2.0" IssueInstant="2023-10-27T12:30:00Z"
                     Destination="https://idp.example.com/sso/logout"
                     xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                     xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
                     xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
  <saml:Issuer>https://sp.your-company.com/saml</saml:Issuer>
  <ds:Signature>
    <ds:SignedInfo>
      <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
      <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
      <ds:Reference URI="#_432b1b123a1a123a">
        <ds:Transforms>
          <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
          <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
        </ds:Transforms>
        <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
        <ds:DigestValue>EXAMPLE_DIGEST_VALUE_HASH_OF_REQUEST</ds:DigestValue>
      </ds:Reference>
    </ds:SignedInfo>
    <ds:SignatureValue>EXAMPLE_SIGNATURE_VALUE_ENCRYPTED_HASH</ds:SignatureValue>
    <ds:KeyInfo>
      <ds:X509Data>
        <ds:X509Certificate>EXAMPLE_X509_CERTIFICATE</ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
  </ds:Signature>
  <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">user@your-company.com</saml:NameID>
</samlp:LogoutRequest>
  • ID: A unique identifier for this specific request.
  • IssueInstant: A timestamp when the request was generated.
  • Destination: The URL on the IdP's server where the logout request is sent. Its value must match the URL of the IdP endpoint that receives the HTTP response, serving as a critical security check.
  • <saml:Issuer>: The unique Entity ID of the Service Provider.
  • <ds:Signature>: The digital signature block, identical in function to the one in the AuthnRequest.
  • <saml:NameID>: The user's unique identifier (in this case, an email address) that is being logged out. This is a crucial part of the logout request, as it tells the IdP exactly which user's session to terminate.