Sun Java System Access Manager 7 2005Q4 Federation and SAML Administration Guide

SAML Overview

SAML is an open-standard protocol that defines user authentication, entitlements, and attribute information in XML documents. The Organization for the Advancement of Structured Information Standards (OASIS) drives the development of SAML 1.0 and 1.1, the versions supported in Access Manager 7 2005Q4.

Note –

For information and specifications, see the OASIS Security Services (SAML) Technical Committee web site.

The SAML documents can be used to exchange security information between an authority and a trusted partner site. The security information that is exchanged 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. A SAML authority, sometimes called the asserting party, is a platform or application that has been integrated with the SAML API, allowing it to relay security information. Trusted partner sites receive the security information and rely on its authenticity.

Note –

All domains 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 by vendors 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 lists the benefits of the two.

Table 9–1 Benefits of the SAML and the 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 –

SAML Version 2.0 has been integrated into the Liberty Alliance Project specifications. This version is planned for implementation in an upcoming release of Access Manager.

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 9–1 SAML Interaction in Access Manager

Graphic that illustrates SAML interaction within Access Manager

SAML allows Access Manager to work in the following ways:

Users can authenticate using Access Manager and access trusted partner sites without having to reauthenticate.

Note –
This single sign-on process is independent of the proprietary Access Manager process discussed in the Sun Java System Access Manager 7 2005Q4 Administration Guide.
Access Manager acts as a policy decision point, allowing external applications to access user authorization information for the purpose of granting or denying access to their resources. For example, employees of an organization can be allowed to order office supplies from suppliers if they are authorized to do so.
Access Manager acts as both an attribute authority (allowing trusted partner sites to query a subject’s attributes) and an authentication authority (allowing trusted partner sites to query a subject’s authentication information).
Two parties in different security domains can validate each other for the purpose of performing business transactions.
The SAML API can be used to build Authentication, Authorization Decision, and Attribute Assertions.
The SAML service permits an XML-based digital signature signing and verifying functionality to be plugged into it.

Using SAML

The SAML 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, accesses URLs from trusted partner sites. Developers integrate the API into their applications 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.