SAML 2.0

Security Assertion Markup Language (SAML) 2.0 passes signed authentication statements in XML from an identity provider to a service provider. The identity provider authenticates the user once and issues an assertion holding their identity and attributes; each service provider consumes that assertion rather than collecting credentials itself, which is the mechanism behind most browser-based enterprise single sign-on in operation today. OASIS approved it as an OASIS Standard in March 2005 and the protocol has not changed since, so new integrations are built on OpenID Connect (OIDC) while SAML is an estate to maintain and migrate rather than one to extend.

What is SAML 2.0?

The standard is maintained by OASIS, the Organization for the Advancement of Structured Information Standards, and predates the JSON- and REST-oriented protocols that followed it: assertions, requests and responses are XML documents, secured with XML Signature and XML Encryption rather than with the JWS and JWE constructions an OIDC deployment uses. That lineage explains both its reach — practically every enterprise application shipped in the last two decades speaks it — and its cost, because the XML parsing and canonicalization it depends on are where most of its implementation weaknesses have been found.

Fundamental Concepts of SAML 2.0:

  1. Assertions: At the core of SAML 2.0 is the concept of assertions—XML-formatted statements that convey information about a user's identity and authentication status. Assertions are exchanged between the identity provider (IdP) and service provider (SP) during the authentication process.
  2. Identity Providers (IdP): The IdP is responsible for authenticating users and generating SAML assertions containing information about the user's identity.
  3. Service Providers (SP): Service providers consume SAML assertions to grant or deny access to their resources. Examples of service poviders are web applications, cloud services, and other online platforms.
  4. Single Sign-On (SSO): SAML enables SSO, allowing users to authenticate once with an IdP and gain access to multiple service providers without the need to re-enter credentials.

SAML and Its Relationship with Other Identity Technologies:

  1. OAuth 2.1: While SAML primarily focuses on authentication and SSO, OAuth 2.1 is designed for authorization.
  2. OpenID Connect (OIDC) - The Modern Successor: OIDC, an authentication layer built on top of OAuth 2.0, is the recommended replacement for SAML in new implementations. While OIDC shares similar goals with SAML (authentication and SSO), it offers several advantages: it's more lightweight, uses JSON instead of XML, is natively designed for modern web and mobile applications, and simplifies integration with RESTful APIs. Organizations planning new identity implementations should strongly consider OIDC over SAML, reserving SAML primarily for legacy system integrations and enterprise scenarios where it's already established.
  3. LDAP (Lightweight Directory Access Protocol): SAML often works in conjunction with LDAP directories for user attribute information. LDAP provides a centralized repository of user data, enhancing the overall identity management process.

Key Advantages of SAML 2.0:

  • Interoperability: SAML's standardized format ensures interoperability between different identity providers and service providers, fostering a seamless and secure authentication process.
  • Single Sign-On (SSO): SAML enables SSO, enhancing user experience by eliminating the need to remember multiple sets of credentials for various applications.
  • Security: SAML employs digital signatures and encryption, ensuring the integrity and confidentiality of exchanged assertions. This robust security framework is crucial for protecting sensitive user information.

Key Challenges and Considerations:

  • Complexity of Implementation: Implementing SAML can be complex, requiring a deep understanding of the protocol and coordination between multiple parties. The XML-based format and verbose specifications increase development and maintenance overhead.
  • Scalability: As organizations grow, managing a large number of SAML configurations and integrations can become challenging, requiring careful planning for scalability. Large multilateral federations mitigate this with signed metadata aggregates rather than pairwise exchange; OpenID Federation is the OIDC-era answer to the same problem, replacing the aggregate with trust chains resolved per request.
  • User Experience: While SAML enhances security, it may introduce additional steps in the user authentication process, potentially impacting user experience.
  • Legacy Technology Status: SAML is increasingly considered a legacy protocol for new implementations. Modern alternatives like OIDC offer better support for mobile applications, APIs, and cloud-native architectures. Organizations should evaluate OIDC for new projects and consider migration strategies for existing SAML deployments.
  • Limited Mobile and API Support: SAML was designed primarily for browser-based web applications and lacks native support for mobile apps and RESTful API authentication patterns that are common in modern architectures.

Conclusion:

SAML 2.0 provides a standardized and secure foundation for enterprise authentication and authorization, and it remains widely deployed and relevant for maintaining existing enterprise integrations. Organizations should nonetheless recognize that it is being superseded by OIDC for new implementations.

For greenfield projects and modern application architectures, OIDC (based on OAuth 2.0) is the recommended choice due to its lightweight JSON-based approach, superior mobile and API support, and alignment with contemporary development practices. SAML should primarily be considered for scenarios involving legacy system integration, existing enterprise SSO deployments, or specific compliance requirements that mandate its use.