Web Single Sign-On Authentication using SAML

Companies have increasingly turned to application service providers (ASPs) or Software as a Service (SaaS) vendors to offer specialized web-based services that will cut costs and provide specific and focused applications to users. The complexity of designing, installing, configuring, deploying, and supporting the system with internal resources can be eliminated with this type of methodology, providing great benefit to organizations. However, these models can present an authentication problem for corporations with a large number of external service providers. This paper describes the implementation of Security Assertion Markup Language (SAML) and its capabilities to provide secure single sign-on (SSO) solutions for externally hosted applications.

💡 Research Summary

The paper addresses the growing challenge faced by enterprises that consume a multitude of external SaaS and ASP services: the proliferation of separate usernames and passwords for each provider, which re‑creates the “sticky‑note” problem that centralized internal authentication was designed to eliminate. To solve this, the authors propose and implement a Single Sign‑On (SSO) solution based on the Security Assertion Markup Language (SAML) version 2.0, a widely adopted XML‑based standard for federated identity.

The introduction outlines the benefits of a central identity store for internal applications and explains why the same model is needed for externally hosted services. The background section traces the evolution of SAML from its 1.0 roots through the 1.1 interim to the 2.0 release in 2005, highlighting the major new capabilities introduced in 2.0: XML encryption, service‑provider‑initiated SSO, and Single Logout. The authors then break down the SAML architecture into its four layers—Assertions, Protocols, Bindings, and Profiles—explaining how each layer can be customized to meet specific business requirements.

Two SAML profiles are examined in depth: the Web Browser SSO Profile and the Artifact Resolution Profile. The Web Browser SSO Profile uses HTTP‑Redirect, HTTP‑POST, or HTTP‑Artifact bindings to transport a signed and optionally encrypted Assertion from the Identity Provider (IdP) to the Service Provider (SP). The SP validates the signature, decrypts if necessary, extracts attributes, and grants the user access without further credential entry. The Artifact Resolution Profile, by contrast, passes only a small “artifact” via the browser; the actual Assertion is exchanged out‑of‑band over a secure channel (e.g., SSL‑VPN), reducing exposure of sensitive data and eliminating the need for per‑message signing or encryption overhead.

Implementation details cover both open‑source and commercial federation products that support SAML 1.1 and 2.0, such as OpenSAML, Shibboleth, OpenSSO, CA SiteMinder, and RSA Federated Identity Manager. The authors emphasize that strict adherence to the SAML standard ensures interoperability among these solutions. A key practical contribution is the discussion of metadata exchange. In SAML 2.0, each party publishes an XML metadata file containing an EntityDescriptor, IDPSSODescriptor or SPSSODescriptor, supported bindings, endpoint URLs, and cryptographic key information. By importing a partner’s metadata, administrators can automatically configure trust relationships, enforce signing requirements (WantAuthnRequestsSigned, WantAssertionsSigned), and define Single Logout services, thereby minimizing manual configuration errors. Sample metadata for both an IdP and an SP are provided, illustrating optional elements such as NameID formats (transient, email) and multiple Assertion Consumer Service endpoints (POST and Artifact).

The paper also addresses attribute mapping: unique user identifiers (e.g., corporate email or employee number) are selected as NameID values, and additional attributes can be sourced from LDAP or HR systems. Security considerations include signing and encrypting Assertions, using HTTPS/TLS for transport, and implementing the Single Logout protocol to terminate sessions across all federated services simultaneously. Testing procedures involve browser developer tools and SAML decoders to inspect the raw XML, verify signatures, and confirm attribute propagation.

In conclusion, the authors demonstrate that a SAML 2.0‑based SSO framework effectively eliminates the need for users to manage multiple credentials, reduces administrative overhead for both the enterprise and external providers, and provides a robust, standards‑based security model. They suggest future work on integrating multi‑factor authentication, extending SAML to cloud‑native environments, and exploring interoperability with OpenID Connect.