Core Security Patterns: Identity Management Standards and Technologies

This chapter is from the book

Core Security Patterns: Best Practices and Strategies for J2EE, Web Services, and Identity Management

Learn More Buy

This chapter is from the book

This chapter is from the book 

Core Security Patterns: Best Practices and Strategies for J2EE, Web Services, and Identity Management

Learn More Buy

Introduction to SAML

Security Assertion Markup Language (SAML) is derived from two previous security initiatives: Security Services Markup Language (S2ML) and Authorization Markup Language (AuthXML). SAML is an XML–based framework for exchanging security assertion information about subjects. Subjects are entities that have identity related information specific to a security domain. SAML plays a vital role in delivering standards-based infrastructure for enabling single sign-on without requiring the use of a single vendor’s security architecture. However, SAML does not provide the underlying user authentication mechanism.

The Motivation of SAML

SAML provides a standards-based approach to the enabling of SSO among heterogeneous applications and to the supporting of identity management. Before we had the SAML standard, developers had to enforce a centralized security infrastructure using proprietary security mechanisms for heterogeneous application systems. That solution was not cost-effective and created many interoperability issues among different vendor products. In the worst case, developers used client-side screen-scraping or a keystroke-recorder solution that could enable the user to sign on to different applications. These solutions store user credentials locally in either cleartext or a proprietary data format. This created interoperability issues and also opened up many security loopholes and risks for hackers on the client side. In addition, these solutions made it difficult to manage deployment and troubleshooting in multiple application integration scenarios.

Another proprietary approach is to encapsulate encrypted user credentials (also referred to as a security token) in the HTTP-POST header and pass the security token to different applications via a secure transport protocol such as SSL. Once a user authenticates with an SSO-enabled application, the client application uses the SSO security token in the HTTP-POST headers, which helps to redirect the user to the target resource or application to which it has privileged access. Each resource or application needs to build a proprietary agent to intercept the HTTP header for SSO security token. To many business corporations and their trading partners, the use of proprietary agents is intrusive to the infrastructure. Although this approach looks similar to many vendor-defined mechanisms, it provides the basis of the SAML specification for representing authentication and authorization credentials in a standard security-token format.

The Role of SAML in SSO

SAML provides an XML standards-based representation of security information that allows security information to be shared among application security domains over the network. Using HTTP-POST or SOAP message headers, SAML allows applications to participate in SSO scenarios. To support SSO, SAML introduces the notion of SAML Assertions, a part of XML messages that can be transferred between security providers and service providers. SAML Assertions contain statements that applications and service providers use to make authentication and authorization decisions.

In addition, SAML provides many benefits. These include the absence of duplication of security mechanisms and their associated directory information. SAML messages and their underlying XML-based interactions also ensure interoperability and the use of scalable remote authorization services to support multiple applications. SAML requires the user to enroll with at least one SAML-enabled security provider that will provide authentication services to the user. However, SAML does not define how authentication and authorization services should be implemented.

SAML is also designed to be used with other standards; the Liberty Alliance Project, the Shibboleth project, and the OASIS WS-Security standards have all adopted SAML as a technological underpinning to support identity management. A number of security vendors currently provide SAML-compliant security products. These vendors include Sun Microsystems, CA-Netegrity, RSA Security, Oracle-Oblix, Entrust, and so forth. OpenSAML [OpenSAML] and SourceID [SourceID] are open-source implementations. This is not an exhaustive list of SAML-compliant products. More examples of SAML-compliant products can be found at http://www.oasis-open.org/committees/download.php/11915/RSA2005-saml-interop-final.pdf.

SAML 1.0

SAML 1.0 was accepted as an OASIS standard in November 2002. It is endorsed by leading industry vendors for the support of single sign-on and interoperability among security infrastructures. SAML 1.0 addressed one key aspect of identity management: how identity information can be communicated from one domain to another.

SAML 1.1

OASIS released the SAML version 1.1 specification on September 2, 2003.

SAML 1.1 is similar to SAML 1.0 but adds support for “network identity,” defined by Liberty Alliance specifications [Liberty]. SAML 1.1 support for Liberty Alliance specifications allows exchanging user authentication and authorization information securely between Web sites within an organization or between organizations over the Internet by Web account linking and role-based federation. SAML 1.1 also introduced guidelines for the use of digital certificates that allow signing of SAML assertions.

There are also changes in the digital signature guidelines, such as the recommended use of exclusive canonical transformation. For details about the differences, see the SAML 1.1 [SAML11Diff ]. The specification did not address all of the problems in the single sign-on or identity management domain. For example, it did not provide a standard authentication protocol that supports a variety of authentication devices and methods. Although SAML provides a flexible structure for encapsulating user credentials, there is still a problem in integrating with a Kerberos-based security infrastructure such as Microsoft Windows Kerberos. SAML 2.0 currently includes a work item “Kerberos SAML Profiles” that addresses the integration requirement. This subject is discussed in the next section.

SAML 2.0

SAML 2.0 specifications were approved by OASIS as a standard in March 2005. SAML 1.1 defined the protocols for single sign-on, delegated administration, and simple policy management. Liberty’s Identity Federation Framework (ID-FF) 1.2 was provided to the SAML committee, and SAML 2.0 was the result of converging previous SAML versions with Liberty ID-FF and with Shibboleth. SAML 2.0 fills in the gaps left in SAML 1.1 by including global sign-out, session management, and extension of identity federation framework for opt-in account linking across Web sites (used by Liberty).

Among the additions in SAML 2.0, there are several interesting items:

• Enhancement of SAML assertions and protocols in support of federated identity and global sign-out.
• Creation of new SAML attribute profiles, including the X.500/LDAP attribute and XACML. These attribute profiles simply the configuration and deployment of systems that exchange attribute data.
• Pseudonyms to provide a privacy-enabling “alias” for a global identifier to avoid collusion between service providers. SAML 2.0 uses an opaque pseudo-random identifier (with no discernible correspondence with meaning identifiers such as e-mail addresses) between service providers to represent principals.
• With the use of pseudonyms, SAML 2.0 defines how two service providers can establish and manage these pseudonyms for the principals they are working with.
• SAML meta-data specify how configuration and trust-related data can be more easily deployed in SAML systems. Identity providers and service providers often need to agree on data such as roles, identifiers, and supported profiles. SAML meta-data provides a structure for identifying the actors involved in the various profiles, such as single sign-on identity provider, attribute authority, and requester.
• Better support of mobile and active devices by adding more authentication contexts that accommodate new authentication requirements, such as including smart card-based PKI and Kerberos.
• Support of encryption for attribute statements, name identifiers, or entire assertion statements.
• Support for privacy using privacy policy and settings that service providers can obtain and use to express a principal’s consent to particular operations.
• Discovery of multiple identity providers, using a provider discovery profile that uses a cookie written in a common domain between the identity provider and service providers.
• Use of an Authentication Request protocol (<AuthnRequest>), which enables an interoperable “destination-site-first” scenario. In other words, the <_AuthnRequest> protocol allows a user to approach a service provider first and then be directed to log in at the identity provider if the service provider deems it to be necessary.
• Conformance requirements and interoperability details.

SAML 2.0 has some changes in the core specification as well. It has significant changes in scope, particularly with regard to extending the functionality and aligning itself with other related initiatives. Here are some examples of the functionalities:

• Support for global logout and time-out (session support)
• Discovery of SAML Web service through a WSDL file (meta-data exchange and protocol)
• Exchange of name identifier and pseudonyms between sites (identity federation, or federated name registration protocol)
• Multi-hop delegation and intermediaries (multi-participant transactional workflows)
• Liberty authentication context exchange and control (authentication context)
• Additional protocol binding for direct HTTP use (HTTP-based assertion referencing)
• Coordinating with IETF Simple Authentication and Security Layer effort (SASL support)
• Integrating and reconciling SAML 2.0 and XACML 2.0, including attribute usage, authorization decision requests and responses, and policy queries and responses.

In addition to the SAML assertion, SAML 2.0 introduces the following new message protocols: artifact protocol, federated name registration protocol, federation termination protocol, single logout protocol, and name identifier mapping protocol. [SAML2Core] has a full description of these new messaging protocols, which are not discussed here.

One new message protocol of interest is the logout request (specified by the <LogoutRequest> tag), which supports global logout. This new support means that if a principal (a user or a system entity) logs out as a session participant, then the session authority will issue a logout request to all session participants. The reason for the global logout can be “urn:oasis:names:tc:SAML:2.0:logout:user” (user decides to terminate the session), or “urn:oasis:names:tc:SAML:2.0:logout:admin” (administrator wishes to terminate the session, for example, due to timeout). These and other attributes will be discussed in later sections.

SAML Profiles

The SAML specification defines a standard mechanism for representation of security information. This mechanism allows security information to be shared by multiple applications so that they are able to address single sign-on requirements. The notion of a SAML profile addresses these core interoperability requirements. The SAML profile allows the protocols and assertions to facilitate the use of SAML for a specific application purpose. A SAML profile defines a set of rules and guidelines for how to embed SAML assertions into, and extract them from, a protocol or other context of use. Using a SAML profile, business applications would be able to exchange security information in SAML messages seamlessly and to easily interoperate between SAML-enabled systems.

SAML 2.0 defines the following SAML profiles:

• Web browser SSO Profile: Single sign-on using standard browsers to multiple service providers. The Web browser SSO profile uses the SAML Authentication Request protocol, in conjunction with the HTTP Redirect, HTTP POST, and HTTP Artifact bindings. SAML 2.0 combines the previous two Web browser profiles from SAML 1.1 into one single profile.
• Enhanced Client and Proxy Profile: This profile defines the rules for a system entity to contact the appropriate identity provider, possibly in a context-dependent fashion. It uses the Reverse SOAP (PAOS) binding.
• Identity Provider Discovery Profile: This profile defines how a service provider discovers the identity provider used by the Principal.
• Single Logout Profile: This profile defines how to terminate the sessions managed by the session authority (or identity provider).
• Name Identifier Management Profile: This profile defines how to exchange a persistent identifier for a principal with the service providers and how to later modify changes in the format or value.
• Artifact Resolution Profile: SAML 2.0 defines an Artifact Resolution protocol to dereference a SAML artifact into a corresponding protocol message. The HTTP Artifact binding can then leverage this Artifact Resolution protocol in order to pass SAML protocol messages by reference.
• Assertion Query/Request Profile: This profile defines a protocol for requesting existing assertions by reference or by querying on the basis of a subject and additional statement-specific criteria.

In addition, the SAML profile also defines rules for mapping attributes expressed in SAML to another attribute representation system. This type of SAML profile is known as Attribute Profile. SAML 2.0 defines five different Attribute Profiles [SAML2Profiles].

• Basic Profile: This profile defines simple string-based SAML attribute names.
• X.500/LDAP Profile: This profile defines a common standardized convention for SAML attribute-naming using OIDs (Object Identifiers) expressed as URNs (Uniform Resource Names) and accompanied by using the type xsi:type.
• UUID Profile: This profile defines SAML attribute names as UUIDs (Universal Unique Identifiers) expressed as URNs.
• DCE PAC Profile: This profile defines how to represent DCE realm, principal, and primary group, local group, and foreign group membership information in SAML attributes.
• XACML Profile: This profile defines how to map SAML attributes cleanly to XACML attribute representations.

To support Web services and usage of SAML tokens in Web services communication, the OASIS WS-Security TC developed a SAML Token profile. The SAML Token profile defines the rules and guidelines for using SAML assertions in Web services communication. OASIS also ratified SAML Token profile 1.0 as an approved standard. Refer to Chapter 6, “Web Services Security–Standards and Technologies,” for information about the role of SAML token profiles and how to use them in WS-Security.