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.
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.
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 |
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 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.
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.
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.
This single sign-on process is independent of the proprietary Access Manager process discussed in the Sun Java System Access Manager 7.1 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.
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.