Sun Java System Access Manager 7.1 Federation and SAML Administration Guide

SAML Overview

SAML is an XML-based standard for communicating authentication, authorization and attribute information amongst online partners. It allows businesses to securely send assertions between partnered organizations regarding the identity and entitlements of a principal. The Organization for the Advancement of Structured Information Standards (OASIS) Security Services Technical Committee is in charge of defining, enhancing, and maintaining the SAML specifications. SAML standardizes queries for, and responses that contain, user authentication, entitlements, and attribute information in an XML format. This format can then be used by a relying party to request security information about a principal from a SAML authority. A SAML authority, sometimes called the asserting party, is a platform or application that can relay security information. The relying party (or assertion consumer or requesting party) is a partner site that receives the security information. The exchanged information deals with a subject’s authentication status, access authorization, and attribute information. A subject is an entity in a particular domain. A person identified by an email address is a subject, as might be a printer.


Note –

All parties in a SAML interaction need to form a trust relationship before they can share information about a subject’s identity. How this is accomplished is beyond the scope of this guide.


Comparison of SAML and Liberty Specifications

SAML was designed to address the issue of cross-domain single sign-on. The Liberty Alliance Project was formed to develop technical specifications that would solve business process problems. These issues include single sign-on, but also incorporate protocols for account linking and consent, among others. SAML, on the other hand, does not solve issues such as privacy, single logout, and federation termination.

The SAML 1.0 and 1.1 specifications and the Liberty Alliance Project specifications do not compete with one another. They are complementary. In fact, the Liberty Alliance Project specifications leverage profiles from the SAML specifications. The decision of whether to use SAML or the Liberty specifications depends on your goal. In general, SAML should suffice for single sign-on basics. The Liberty Alliance Project specifications can be used for more sophisticated functions and capabilities, such as global sign-out, attribute sharing, web services. The following table compares the benefits of the two.

Table 10–1 Comparison of the SAML and Liberty Alliance Project Specifications

SAML Uses 

Liberty Alliance Project Uses 

Cross-domain single sign-on 

Single sign-on only after user federation

No user federation 

User federation 

No privacy control, best for use within one company 

Built on top of SAML 

User identifier is sent in plain text 

User identifier is sent as a unique handle 


Note –

The Organization for the Advancement of Structured Information Standards (OASIS) drives the development of SAML. For information and specifications, see the OASIS Security Services (SAML) Technical Committee home page.


SAML Architecture in Access Manager

SAML security information is expressed in the form of an assertion about a subject. An assertion is a package of verified security information that supplies one or more statements concerning a subject’s authentication status, access authorization decisions, or identity attributes. Assertions are issued by the SAML authority, and received by partner sites defined by the authority as trusted. SAML authorities use different sources to configure the assertion information, including external data stores or assertions that have already been received and verified. The following figure illustrates how SAML interacts with the other components in Access Manager.


Note –

Although Federation (as described in Chapter 3, Federation) integrates aspects of the SAML specifications, its usage of SAML is independent of the SAML component as described in this chapter.


Figure 10–1 SAML Interaction in Access Manager

Graphic that illustrates SAML interaction within Access Manager

SAML allows Access Manager to work in the following ways:

Using the SAML Service

The SAML Service can be accessed using a web browser or the SAML API. An end user authenticates to Access Manager using a web browser and, once authorized to do so, attempts to access URLs on trusted partner sites. Developers, who have integrated the SAML API into their applications, are then able to exchange security information with Access Manager. For example, a Java application can use the SAML API to achieve single sign-on. After obtaining a SSOToken from Access Manager, the application can call the doWebArtifact() method of the SAMLClient class, which will send a SOAP request for authorization information to Access Manager and, if applicable, redirect the application to the destination site. For more information, see SAML API.