Printer Friendly

Security Assertion Markup Language: the key to federated security services. (Internet).

How many times have you heard the claim that a particular solution is the solution for global single sign-on? It seems the answer is proportional to your age; the older you are, the more times you've heard this claim. So, why should the newest contender, Security Assertion Markup Language (SAML) be any different? This article will explain why SAML, while not perfect, is probably the best technical solution for this very complex challenge.

SAML is a standard from the Organization for the Advancement of Structured Information Standards (OASIS). This article will:

* Explain the motivation behind SAML.

* Use a real-world example to show how organizations are planning to use SAML.

* Examine SAML assertions, as well as two specific SAML Web browser profiles.

* The article will conclude by describing the current status of SAML and by surveying other standards that use SAML.


The greatest value of a security infrastructure is in its integration with enterprise applications. Each year, organizations spend significant amounts of money, time and effort creating and maintaining their security infrastructures. Yet, integrating the security infrastructure with enterprise applications remains an elusive task.

In the last 15 years we have witnessed a slow but steady evolution of distributed security architectures. Interestingly enough, the overarching framework has not changed at all. if you consider the foundation of secure computing, you can view it in a framework that consists of three components (see Figure 1).

The "subject" is a human or a process that wants to receive some type of service. For instance, a Web browser user is a subject. An "authority" is a process that makes assertions about subjects. For example, a kerberos key distribution center (KDC) or a certificate authority (CA) makes authentication assertions about subjects. Finally, a "relying party" is the guardian of a resource (e.g. a file) that enforces security policies based on assertions from the authority. Of course, the relying party must trust the authority's assertions about the subject. For example, in a public key infrastructure (PKI), the relying party uses the certificate of the CA and the name constraints in that certificate to establish its trust. Typically, such a trust is established once and lasts for a relatively long time.

First-generation architectures targeted client/server systems. Standards such as the Distributed Computing Environment (DCE) provided a product-independent way for integrating security with enterprise applications. These architectures integrated security with applications via client side software and through standard application programming interfaces (APIs), such as the Generic Security Services API (GSS-API).

Second-generation architectures targeted Web-enabled applications using standard protocols, such as secure socket layer (SSL) and the surrounding PKI. A close examination of the first and second-generation architectures reveals that enterprise applications must inevitably be coupled with the security infrastructure; they can either be tightly coupled using API integration or closely coupled by means of standards such as X.509 certificates and certificate revocation lists. The problem with coupling applications with the security infrastructure is that it prevents smooth migration from one security infrastructure to another. This model also hampers the concurrent operation of multiple security infrastructures--for example, it is not easy to simultaneously enable an application to authenticate using a digital certificate and a password.

The current state of the art is to decouple the three components of the security framework. That is, the subject should be able to get an assertion from a variety of authorities and present these assertions to the relying party. As long as the relying party trusts the authority to make such assertions about that particular subject, then there is no need for any of the components to use the same products or even be under the administrative control of the same organization. How does SAML help realize this vision? The rest of this article elucidates the role of SAML in a distributed and federated security services architecture.

SAML Explained

Extensible Markup Language (XML) has achieved tremendous momentum in the marketplace as a single standard that everyone agrees on. Today, it forms the basis for integrating disparate applications and data sources. Whereas XML was once a language for describing data, it is now a universal language for describing both data and action. For instance, simple object access protocol (SOAP) specifies a set of request and reply actions in XML.

SAML consists of four interdependent specifications as described below (Note that SAML specifies core assertions and protocols in a single document. A separate document specifies profiles and protocol bindings.)

Assertions: Specifies XML elements and attributes for three types of assertion statements: authentication, authorization decision and attribute.

Profiles: Specifies interactions between involved parties and how each party uses SAML assertions and protocols.

Protocols: Specifies SAML request/response protocols for requesting and providing assertions.

Protocols bindings: Specifies the mapping of SAML request/response messages to standard communication protocols, such as SOAP/HTTP.

An Example

It is helpful to describe SAML specifications in the context of a real-world example. Consider a user named Tom with the email address Let's say Tom logs into his investment brokerage site's portal and enters a stock transaction. Moments later, he receives an encrypted email confirmation from the investment brokerage, packaged as an HTML attachment. The symmetric key to decrypt the email will only be released to Tom if he can successfully prove his authentic identity to the custodian of the key. Figure 2 demonstrates the flow.

We want a solution in which Tom logs into the portal once, completes his transaction and reads his encrypted confirmation email. In this example, Tom is the subject, the brokerage portal is the authentication authority, and the trading application and the key server are the relying parties. Let's examine how each SAML specification is used in this example.


Tom logs into the investment brokerage portal using whatever authentication method the brokerage firm prefers. He can enter his user ID and password, and this information can be transmitted to the portal via SSL. In any case, SAML does not specify the initial authentication method, and this is not an under-specification on the part of SAML. The intent is that the standard will support multiple existing and future authentication methods.

Subsequent to successful authentication, the brokerage portal (i.e. the authentication authority) creates a SAML authentication assertion for Tom.

Once the authentication authority creates the assertion, it can either give that assertion to Tom (or more precisely, to Tom's browser), or hold on to the assertion and give Tom a handle to the assertion. SAML supports these two models in its Web browser profiles.

Browser POST Profile

In the browser POST profile, the authentication authority hands the SAML authentication assertion to the browser in the context of a SAML response. The SAML response must be digitally signed. It is prudent, though not required, for the SAML assertion in the response to also be digitally signed. SAML uses XML digital signature standards for signature production and verification. As a final step, Tom's browser sends the assertion to the trading application (the relying party), which enables him to enter his trade.

Subsequently, when Tom receives the encrypted confirmation email, the browser retrieves a fresh authentication assertion and presents it to the key server. The key server releases the decryption key and Tom reads his encrypted trade confirmation. Note that Tom does not need to log into the portal again in order to obtain the second assertion. This happens behind the scenes, without Tom being aware that any of this is happening.

Browser Artifact Profile

In the browser artifact profile the authentication authority holds on to the assertion and gives Tom's browser a unique handle to the assertion called an artifact. From Tom's point of view everything is exactly the same as in the case of browser POST profile. However, the relying parties (the trading application and the key server) must each present the unique artifact they received from the browser to the authentication authority and request the associated authentication assertion. SAML specifies this last interaction by its request/response protocol specification.


SAML assertions may be exchanged using a variety or protocols. However, SAML requestors may use the SAML request/response schema for requesting and providing SAML assertions. In the example of this article, the key server may request the authentication authority to provide the SAML assertion that corresponds to an artifact, which was presented to it by the browser.

Protocol Bindings

Finally, protocol bindings provide a way for encapsulating SAML request/reply messages within specific communication protocols. Though SAML envisions many protocol bindings, SAML 1.0 specifies a single binding: SOAP over HTTP. Thus, present implementations of SAML-compliant products use SOAP request and replies when they need to query an assertion authority or respond to a query.

The Big Picture

While we have used a relatively simple example to illustrate SAML, the underlying model is extremely powerful. For example, in our illustration the authentication authority (the portal) and the relying parties (trading application and key server) are all under the control of the same administrative authority (the investment brokerage firm). This need not be the case. For example, if the key server trusts the authentication authority at, then Tom needs not authenticate with the portal to read his trade confirmations. Tom's desktop authentication (perhaps to his active directory server) could be sufficient. This model makes the implementation of federated security services possible. That is, Tom is authenticated by one entity (his employer) and receives secure services from another entity (the brokerage trading application). In addition to authentication assertion statements, SAML also specifies the XML schema for authorization decision and attribute statements.

Where SAML Fits

SAML is not a stand-alone standard. It uses XML and non-XML standards, and other emerging standards reference and use SAML.

For example, SAML uses XML digital signatures for signing assertions, SOAP for communicating requests and responses, and SSL/TLS for securing some of its communications. The emerging Extensible Access Control Markup Language (XACML) as well as specifications from the Liberty Alliance explicitly call out SAML assertions in their specifications. Figure 3 illustrates the synergies between SAML and various other standards.

In July of 2002, a group of 12 vendors demonstrated the interoperability of their solutions through SAML 1.0. These vendors demonstrated a scenario that was similar to the example depicted in this article. The amount of time each vendor spent testing and ensuring interoperability with the other eleven vendors was surprisingly short. While the present SAML specification tends to address the Web single sign-on problem, the standard is rich enough to also address many other problems in distributed and federated security.

In November 2002, the OASIS member body, representing private companies, educational institutions and government agencies, approved SAML 1.0 as an OASIS Open Standard. This is the highest status given by OASIS to its specifications.

More information on SAML is available at a number of websites:

* Liberty Alliance:


* SAML: committees/security/

* XACML: committees/xacml/

Jahan Moreh is chief security architect at Sigaba (San Mateo, Calif.) and a senior member of the faculty at the University of California at Los Angeles
COPYRIGHT 2002 West World Productions, Inc.
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2002, Gale Group. All rights reserved. Gale Group is a Thomson Corporation Company.

Article Details
Printer friendly Cite/link Email Feedback
Author:Moreh, Jahan
Publication:Computer Technology Review
Geographic Code:1USA
Date:Dec 1, 2002
Previous Article:Business continuity: the sensible approach to ROI. (Business of Technology).
Next Article:Gigabit Ethernet and transport offload: transport offload engines help relieve TCP processing burden for Gigabit Ethernet. (Connectivity).

Related Articles
Free JSAML toolkit. (Software Tools).

Terms of use | Privacy policy | Copyright © 2022 Farlex, Inc. | Feedback | For webmasters |