Single Sign-on Simplicity with SAML

May 9, 2002 -- Vacation time is near, so you go online to make your travel arrangements, typing in your user name and password to log onto your Internet service provider. Done. You enter another user name and password to book a plane flight on your favorite travel web site. Done. Remembering that you need a car when you arrive, you sign on yet again to a rental agency's system. Your hotel reservation requires another fresh authentication.

It's not just a matter of dealing with multiple vendors: Back from your vacation, you log in to your employer's virtual private network (VPN) with yet another user name and password. Then there's the HR system login to record your vacation time. And the finance system to approve an employee's travel expense report. And the payroll system to check your retirement account.

Fortunately, multiple sign-on for secure authentication and authorization is quickly becoming a thing of the past for service providers who adopt the Security Assertions Markup Language (SAML) specification.

In short, SAML enables open and interoperable designs for web-based single sign-on service functionality.

Rima Patel, a Sun Technology Evangelist, provided an overview of SAML applied to single sign-on capabilities at the 2002 JavaOne^SM Conference and in a follow-up interview. "Using SAML for single sign-on functionality allows users to authenticate themselves in one domain and use the resources in another domain without re-authenticating themselves," she said.

The user's authentication, authorization, profiles, and preferences are transmitted from an original source service provider to subsequent destination service providers selected by the user during the session.

Patel explained, "In many cases, the source and destination service providers will belong to the same 'federation.' For example, if you have signed on and been authenticated at the American Airlines domain and wish to rent a car, American Airlines will only share your sign-on information (and the associated password, profile, and preferences) with its contracted partners -- companies who enter agreements to protect secure shared information among themselves."

SAML: Headed for Standardization

"The idea of single sign-on services is not new, and versions have existed for several years," said Patel. "However, they are typically 'closed' solutions that don't offer broad interoperability. SAML, on the other hand, is a fully interoperable 'open' solution. There simply hasn't been a secure, interoperable standard for exchanging secure sign-on information, and SAML looks like it will be the first."

"In addition," says Patel, "SAML is targeted as a security services implementation to support Internet2 and has already been approved or adopted in principle by a host of security and service providers." A sample of those providers includes:

• Sun Microsystems (Sun^TM ONE Platform for Network Identity and iPlanet^TM Directory Server, Access Management Edition (DSAME))
• Entrust (GetAccess portal)
• Systinet (WASP Secure Identity)
• Securant (RSA Cleartrust)
• Entegrity (AssureAccess)
• Netegrity (AffiliateMinder)

The new SAML 1.0 specification is based on the merger of two formerly competing security efforts -- S2ML and AuthML. The SAML 1.0 specification set was released in February 2002, and the specification submission was provided to the Organization for the Advancement of Structured Information Standards (OASIS) http://www.oasis-open.org/ in March 2002 for standardization by the OASIS Security Services Technical Committee. (OASIS is a not-for-profit, global consortium that drives the development, convergence and adoption of e-business standards.)

The related Java^TM technology API standard for SAML is in review at the Java Community Process^SM (JCP^SM) program http://www.jcp.org/ as a Java Specification Request -- JSR-155.

What It Is

SAML is an XML framework for exchanging security information over the internet. SAML enables disparate security services systems to interoperate. It resides within a system's security mechanisms to enable exchange of identity and entitlement with other services.

"SAML does not define any new mechanisms or approaches to authentication or authorization," says Patel. "It does not, for instance, include requirements or specifications for the act of authentication or authorization." It does, however, define the structure of the documents that transport security information among services.

By visiting http://www.oasis-open.org/committees/security/, you will see that SAML is a set of specification documents that define its components:

• Assertions and request/response protocols
• Bindings (the SOAP-over-HTTP method of transporting SAML requests and responses)
• Profiles (for embedding and extracting SAML assertions in a framework or protocol)
• Security considerations while using SAML (highly recommended reading)
• Conformance guidelines and a test suite
• Use cases and requirements

A Code Example

Because the SAML standard is designed only for the exchange of secure sign-on information between a user, or "relying party," and multiple issuing parties, it allows issuing parties to use their own chosen methods of authentication for example, PKI, hash, or password.

Here, a sample SAML-compliant request is sent from a relying party requesting password authentication by the issuing party.

In response, the issuing authority asserts that the subject (S) was authenticated by means (M) at time (T).

Assertions and Authorities

"Assertions are at the very core of the SAML specification," says Patel. "An assertion is a declaration of a 'certain fact' about a subject, for example, a user or code." For example, that an individual was authenticated by a particular method at a specific time, or that an application has been granted a certain class of access to a resource under certain conditions.

A SAML-compliant service, called a Relying Party, sends SAML Requests to an Issuing Authority, which returns SAML Assertion Responses. All of the requests and responses are transmitted within a SOAP envelope via HTTP, though Patel notes, "Your own applications can define and exchange assertions using a variety of request/response protocols, but those extensions may limit interoperability."

For example, when a user signs into a SAML-compliant service, the service sends a "request for authentication assertion" to the issuing authority, stating that the user was authenticated by a particular method at a specific time. The issuing authority returns a "authentication assertion reference" that the service can pass to other sites so they can check the user's credentials.

Later, when the user visits another SAML-compliant site that requires authentication, the site uses the reference to request authentication assertion from the issuing authority, which returns an "authentication assertion," stating that the user was, in fact, authenticated by a particular method at a specific time.

Within the current specification, there are four types of assertions:

• Attribute assertions
• Authentication assertions
• Authorization assertions
• Subject assertions

"Assertions do not create a secure authentication," explains Patel. That is the responsibility of the security service. Rather, "assertions are coded statements generated about events, such as authentication, that have already occurred," as, when the user provided a correct user name and password, or when the security mechanism granted specific permissions.

Patel explained that assertions can only be generated and issued by a SAML "issuing authority." At present, there are two general types of issuing authorities.

The first type includes third-party security service providers, such as:

• Microsoft (through its Passport initiative)
• XNSORG http://www.xns.org/ (through its Web Identity platform)
• DotGNU http://www.dotgnu.org/ (through its Virtual Identity platform)

The second type consists of individual businesses, such as AOL, American Express, and VISA, which can serve as issuing authorities within private federations by leveraging the Liberty Alliance technologies http://www.projectliberty.org/.

"Using Liberty Alliance technologies, these issuing authorities can protect and 'own' their users while still sharing security information critical to access among many partners," adds Patel.

Independent of the type of authority, when a user creates a SAML request through a service sign-on, assertions are generated by the issuing authority and transmitted within a SOAP envelope via HTTP.

SAML Architecture