How SSO works?

Table of Contents
  1. User Logs In: The user accesses the SSO portal (or initiates login through a service provider) and enters their credentials (username and password).
  2. Credential Verification: The SSO system sends the credentials to an authentication server, which could use protocols like LDAP, Active Directory (AD), OAuth, or SAML to verify the user’s identity.
  3. Authentication: The authentication server checks the credentials against a database (like AD or a cloud identity service) and either approves or denies the login request.
  4. Token Issuance: If the credentials are correct, the SSO system issues an authentication token, which can be in the form of a JWT, SAML assertion, or OAuth token.
  5. Accessing Applications: The user uses this token to request access to various linked applications without re-entering their credentials.
  6. Application Verification: Each application the user tries to access checks the validity of the token with the SSO system or validates it locally based on the application’s configuration.
  7. Session Management: The user remains authenticated across multiple applications until the session expires or the user logs out.

Different Protocols Used in SSO:

  • SAML (Security Assertion Markup Language): XML-based, widely used in enterprise environments for browser-based SSO.
  • OAuth (Open Authorization): Token-based, typically used in mobile and web apps for secure API access.
  • OpenID Connect (OIDC): Built on top of OAuth 2.0, it adds an identity layer to OAuth, making it suitable for both authentication and authorization.

SAML (Security Assertion Markup Language)

SAML is an XML-based protocol that enables Single Sign-On (SSO) by exchanging authentication and authorization data between two entities: the Identity Provider (IdP) and the Service Provider (SP). It is commonly used in enterprise environments to allow users to access multiple web applications without having to log in repeatedly.

Key Components

  1. Identity Provider (IdP): The system that authenticates the user and stores their digital identity. Examples of IdPs include Active Directory Federation Services (ADFS) or Okta.
  2. Service Provider (SP): The application or service that the user is trying to access (e.g., Salesforce, Google Apps). The SP relies on the IdP to authenticate the user.

SAML Assertion

A SAML assertion is an XML document generated by the IdP, which contains the user’s identity information and authentication status. It serves as proof that the user has been authenticated.

The SAML assertion includes:

  • Attributes: Information about the user (e.g., name, email, roles, permissions).
  • Issuer: The IdP that generated the assertion.
  • Signature: A digital signature from the IdP to ensure the assertion cannot be altered in transit.
  • Conditions: Time constraints like validity period (issue time and expiration).
  • Subject Confirmation: A mechanism ensuring that the assertion is presented by the right user.

SAML Workflow

SAML operates in two major flows: SP-initiated and IdP-initiated. ![[Pasted image 20241017123054.png]]

1. SP-Initiated Flow:

  • Step 1: The user attempts to access an application (SP) but is not authenticated yet.
  • Step 2: The SP generates a SAML authentication request and redirects the user to the IdP.
  • Step 3: The user logs in to the IdP (if not already authenticated).
  • Step 4: Upon successful authentication, the IdP generates a SAML assertion and redirects the user back to the SP.
  • Step 5: The SP validates the SAML assertion (verifying the digital signature and expiration).
  • Step 6: If valid, the SP grants access to the user.

2. IdP-Initiated Flow:

  • Step 1: The user accesses the IdP directly and logs in.
  • Step 2: After successful authentication, the IdP generates a SAML assertion.
  • Step 3: The IdP sends the SAML assertion to the SP, often via a browser redirect.
  • Step 4: The SP validates the assertion and grants access to the user.

SAML Protocols

SAML consists of three main protocols:

  1. Authentication Request Protocol: The SP sends a request to the IdP asking for an authentication assertion.

  2. Assertion Protocol: The IdP responds to the authentication request with an assertion, confirming whether the user is authenticated.

  3. Artifact Resolution Protocol: A method where the IdP can send an artifact (a reference to the assertion) instead of sending the full assertion directly, improving security.

SAML Bindings

SAML supports multiple binding mechanisms, the most common of which are:

  • HTTP Redirect Binding: Used to pass the SAML authentication request from the SP to the IdP via an HTTP redirect.
  • HTTP POST Binding: The SAML assertion is passed back from the IdP to the SP via an HTTP POST request.
  • SOAP Binding: Used for back-channel communication between the IdP and SP. This ensures that messages are exchanged securely between them without relying on the user’s browser.

In-depth Security in SAML

SAML includes robust security mechanisms to ensure the confidentiality, integrity, and authenticity of the authentication and authorization processes.

1. Digital Signatures

  • Purpose: Digital signatures are used to ensure the integrity and authenticity of SAML assertions and requests.

  • How It Works:

    • The IdP digitally signs the SAML assertion using its private key.
    • The SP validates the signature using the IdP’s public key.
    • This process ensures that the assertion has not been tampered with during transmission and that it originated from the trusted IdP.

    Without digital signatures, attackers could alter assertions to elevate permissions, impersonate users, or extend the session’s validity.

2. Encryption

  • Purpose: Encryption ensures the confidentiality of sensitive information, such as user attributes, within a SAML assertion.

  • How It Works:

    • The IdP can encrypt parts of the SAML assertion using the SP’s public key.
    • Only the SP can decrypt the encrypted parts using its private key.
    • This ensures that sensitive data, like user roles and permissions, remains confidential and secure in transit.

    While encryption of the assertion itself is optional, it is often implemented when sensitive user attributes are exchanged.

3. Replay Attack Prevention

  • Purpose: Prevent an attacker from resubmitting a SAML assertion that has already been used to gain unauthorized access.

  • How It Works:

    • SAML assertions include timestamps that specify their validity window (usually a few minutes).
    • Nonces are used to identify requests uniquely, ensuring each assertion can be used only once.
    • The SP checks the validity of the timestamp and ensures the assertion has not been replayed within the allowed time frame.

    By doing so, SAML prevents attackers from capturing a valid SAML assertion and reusing it later to gain unauthorized access.

4. Mutual Authentication Between IdP and SP

  • Purpose: Ensure both parties (IdP and SP) are communicating securely and trust each other.
  • How It Works:
    • Certificates are exchanged between the IdP and SP during the initial setup. Both parties store each other’s public keys.
    • During communication, the IdP signs assertions, and the SP verifies them using the stored public key.
    • This mutual authentication ensures that neither party is impersonating the other, preventing man-in-the-middle attacks.

5. Single Logout (SLO)

  • Purpose: Allow users to log out from all connected applications (SPs) with one action.
  • How It Works:
    • When a user logs out from one application, the SP sends a Logout Request to the IdP.
    • The IdP then notifies all other SPs involved in the user’s session, instructing them to log the user out as well.
    • This centralized logout process ensures that once the user logs out from one service, they are logged out from all services connected via SSO.

6. Transport Layer Security (TLS)

  • Purpose: SAML messages are usually transmitted over HTTPS, ensuring the data exchanged between the IdP and SP is protected by TLS.
  • How It Works:
    • TLS provides encryption, data integrity, and server authentication, securing the communication channel.
    • While the SAML messages themselves are signed and may be encrypted, using TLS adds an additional layer of security, protecting against network-level attacks (e.g., packet sniffing).