Abstract
As more and more systems are linked through Web services, portals, and integrated applications, the need for a standard that allows security information to be shared and exchanged becomes more and more apparent. Security Assertion Markup Language, or SAML, provides a robust, yet extensible set of data formats to communicate identity and authentication information in a variety of environments. Identity Federation, a key concept driving the need for and the definition of SAML, means using information from multiple, independently administered sources to implement security services such as authorization. Along with Single Sign-on (SSO), SAML is a requirement for modern networked environments.

Identity Federation
Before computers were routinely connected to networks, security services—like authentication and authorization implemented in stand-alone systems—were completely self-contained. Consequently, all the necessary code to perform authentication as well as keys, passwords, user information to make authorization decisions, and the authorization policies themselves were located on the system that used them. Even when systems were later connected to networks, very little changed initially. Each system was an island. Users were required to have an account on each system they wanted to access.

This approach had many obvious disadvantages. For one, it was inconvenient for users and administrators to set up multiple accounts, each with a password, groups, or other attributes. It also was time-consuming for administrators to change attributes because a user's responsibilities had changed or delete accounts when someone left the organization. If stronger methods of authentication became available, each system would have to be updated individually.

Single Sign-on
With the introduction of the World Wide Web, hosting a single Web site on several machines became common. But it is clearly unacceptable to force users to log in multiple times simply because different machines handled their various requests. Similarly, portals cannot require users to log in every time they access a different application. Single Sign-on (SSO), initially viewed as a sort of productivity-improving luxury, now has become a necessity, at least wherever users are expected to experience a single, integrated system.

In addition, with networks continually growing larger, it is neither possible nor desirable to collect all the information about a user in one place. Many different people and organizations hold various types of personal information associated with individuals—doctors maintain medical records, brokers know what stocks are owned, insurance agents hold policies, accountants keep financial and tax records, and so on. Constantly moving all this information to one spot would only make it more difficult to keep the data accurate and up-to-date. And at the same time, moving the information increases the chances of data being lost or stolen in transit.

Still, the many types of information must remain available throughout the network for user authentication and authorization. And that's the purpose of Identity Federation. It combines data on a single user from multiple sources, for purposes such as authorization. Since different organizations probably want to use different products to manage the identity data they have, standards are needed to move that data around the network—from where it is being held to where it will be used. Similarly, although many products provide Web Single Sign-on, standards make it possible to implement this across different products. This is where SAML comes in.

SAML Fundamentals
SAML standardizes the full range of functions associated with receiving, transmitting, and sharing security information to:

Provide XML formats for user security information and formats to request and transmit the information.
Define how these messages work with protocols such as SOAP.
Specify precise message exchanges for certain common use cases, such as Web SSO.
Support a number of privacy protection mechanisms, including the ability to determine users' attributes without revealing their identities.
Detail how to handle identity information in formats provided by widely used technologies, including Unix, Microsoft Windows, X.509, and LDAP, DCE, and XCML.
Formulate a metadata schema that allows participating systems to communicate the SAML options they support.
Moreover, SAML is specifically designed for flexibility. It is extensible to meet requirements not yet covered by the standard.

SAML Roles, Assertions, and Statements
A federated environment involves at least three roles.

Relying Party - makes use of the identity information; typically this is a Service Provider that decides what requests to allow
Asserting Party - provides the security information; SAML calls this the "Identity Provider"
Subject - the user associated with the Identity Information
In any environment, there will be many subjects and several Service Providers. There also may be multiple Identity Providers.

Basically, the Service Provider or the Relying Party needs to know three things:

The identity information
That the party making a request is the Subject
That the Identity Provider is trusted to provide this information
In SAML, an Assertion carries the information. The Assertion contains header information, the name of the Subject, and one or more Statements. The header contains the name of the Identity Provider and other information such as issue and expiration dates.

The two most important Statement types are:

Authentication Statements - report that the Subject was authenticated using a particular method at a specific time and place. SAML defines the details of more than 20 different authentication methods. Authentication statements support SSO, where the Identity Provider performs the login on behalf of the Service Provider.
Attribute Statements - contain properties associated with the Subject. Groups and Roles are typical attributes, but financial data or any other property could be carried in an Attribute Statement.
An Assertion can carry both types of Statements. It is possible to define additional Statement types. In fact, [URL=http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml]XACML[/URL] has defined a statement for carrying Policies and another for communicating the results of an authorization decision.

One of the strengths of SAML is its flexibility. The Identity Provider can digitally sign the Assertion, but it has the option to use other methods, such as SSL, to ensure the integrity of the information. The Assertion can contain an element called the Subject Confirmation, which the Service Provider uses to determine if the information in the Assertion refers to the party making the current request. Once again SAML allows the Service Provider to use a variety of means for this purpose.

Bindings and Profiles
Although SAML Assertions travel from an Identity Provider to a Service Provider, they can do so through a number of possible paths. The Service Provider can obtain them directly via a dedicated channel. Another possibility is that the requesting Subject can carry the Assertions and present them to the Service Provider. A third option is to relay the Assertions through another node. And in a Web services environment, the SOAP header can carry them.

SAML defines a set of request and response messages in XML that can be used by a Service Provider to obtain Assertions directly. The requests specify what the Service Provider wants—for example, "all the attributes of John Smith". The responses return one or more Assertions that match the request. To allow different products to interoperate, it is also necessary to specify how the network protocols will carry the requests and responses.

The SAML SOAP Binding specifies how to carry them in the body of a SOAP message. The PAOS Binding is designed for devices like cell phones that cannot accept a request from the network, but can send one. It runs SOAP over HTTP backward, with the message carried in the HTTP response. The Browser POST and Artifact Profiles are designed around the operations of a standard Web browser. In the POST Profile, the SAML Response is carried in an invisible field in a form that is POSTed via the browser. In the Artifact Profile, an arbitrary bit string called an Artifact is passed to the Service Provider, which uses it to request the corresponding Assertion over a dedicated back channel.

SAML provides a number of other mechanisms useful for supporting a federated identity environment. One protocol allows a Service Provider to determine where to direct a particular client request to from several possible Identity Providers. Another protocol allows two identity providers to associate the accounts that they each possess for the same user. For example, one may know the user as John Smith and the other as Jonathan K. Smith. (Normally, for privacy reasons, this requires the user's permission.)

It is also possible to use a privacy-protecting, temporary identifier to avoid revealing the long-term identity of Subjects. Continuing our example, one Identity Provider would know that Assertions containing Subject ABC123 refer to John Smith, and the other would associate ABC123 with Jonathan K. Smith, but neither would see the account name that the other uses. On the next day a completely different Subject would be used to prevent a third party from detecting a pattern of usage.

SAML specifies a lightweight logout protocol to inform all Service Providers and Identity Providers that a user has signed off. This is intended primarily as a convenience to clean up resources, rather than as a mechanism to guarantee a user is logged off the system. A variety of other useful SAML features include the ability to:

Encrypt all or just sensitive parts of Assertions.
Specify the intended consumer of an Assertion.
The SAML Standard also includes detailed conformance criteria for various feature combinations and a document discussing Security and Privacy considerations.

Conclusion
SAML provides a useful set of mechanisms to implement Federated Identity Management in a large-scale environment. It provides good interoperability by specifying many of the most common scenarios in great detail. It also is extensible to meet unique requirements and future needs.

Additional Reading
[URL=http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security]SAML[/URL] - SAML home page at OASIS
[URL=http://www.projectliberty.org/]Project Liberty[/URL] - Liberty Alliance Project
[URL=http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml]XACML[/URL] - XACML home page at OASIS
[URL=http://dev2dev.bea.com/pub/au/3299]Harold Lockhart[/URL] is a principal engineering technologist in the Standards and Architecture Group at BEA. An internationally known author and speaker, he has been an active contributor in the OASIS Web Services Security and SAML technical committees.