Update 2004-08-19: See the news item "OASIS Security Services TC Releases Approved SAML 2.0 Committee Drafts for Review."

The OASIS Security Services Technical Committee (SSTC) has announced the release of a set of SAML Version 2.0 specifications in advance of TC ballot for approval at Committee Draft level. The Technical Committee is actively soliciting external input on these SAML working draft documents; public comment and implementor feedback is invited through August 2, 2004.

SAML provides a standard way to represent authentication, attribute, and authorization decision information in XML, and a series of web services-based request/response protocols for exchanging these statements. SAML v2.0 provides support for full federation and mapping of identifiers, session management, greater interoperability for attribute exchange, and other features.

The SAML Version 2.0 review distribution includes five working draft specifications and corresponding XML Schemas. Assertions and Protocols defines the syntax and semantics for XML-encoded assertions about authentication, attributes, and authorization, and for the protocols that convey this information. A Bindings specification defines protocol bindings for the use of SAML assertions and request-response messages in communications protocols and frameworks.

A SAML 2.0 Profiles draft defines profiles for the use of SAML assertions and request-response messages in communications protocols and frameworks, as well as attribute syntax for use in attribute statements. The Metadata document defines an extensible metadata format for SAML system entities, organized by roles that reflect SAML profiles. Such roles include that of Identity Provider, Service Provider, Affiliation, Attribute Authority, Attribute Requester, and Policy Decision Point. The Authentication Context specification defines a syntax for the definition of authentication context declarations and an initial list of authentication context classes for use with SAML.

The OASIS SSTC believes these five key SAML v2.0 specifications are feature-complete, but is prepared to revise the working drafts in response to comments. The SAML v2.0 specification set includes other documents that are non-normative or less crucial for initial implementation. These documents are publicly accessible and will be brought into the formal review process at a later date. Conformance, Security and Privacy Considerations, Baseline Identities and Attributes, SAML V1.x and Liberty ID-FF V1.2 Migration Paths, X.509 Attribute Sharing Profile, Glossary, Implementation Guidelines, Technical Overview, and Executive Overview are among these additional drafts.

The OASIS SAML Version 2.0 effort "addresses issues and enhancement requests that have arisen from experience with real-world SAML implementations and with standards architectures that use SAML, such as the OASIS WSS and XACML work. It adds support for features that were deferred from previous versions of SAML for schedule reasons, such as session support, the exchange of metadata to ensure more interoperable interactions, and collection of credentials. It seeks convergence on a unified technology approach for identity federation by integrating the specifications contributed by the Liberty Alliance."

SAML 1.0 became an OASIS standard in November 2002, and SAML version 1.1 followed in September 2003. The SAML standards "have seen significant success within industry and are now gaining momentum in financial services, higher education, government, and other verticals. SAML has been broadly implemented by all major Web access management vendors. SAML is also supported in major application server products, and SAML support is also common among Web services management and security vendors."

Bibliographic Information

• Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0. Edited by Scott Cantor (Internet2), John Kemp (Nokia), and Eve Maler (Sun Microsystems). Last-Call Working Draft [Pre Committee Draft] version 17. 13-July-2004. 83 pages. Document identifier: 'sstc-saml-core-2.0-draft-17'. "This specification defines the syntax and semantics for XML-encoded assertions about authentication, attributes, and authorization, and for the protocols that convey this information." See the associated Assertions schema and the Protocols schema.

  Contributors to the specification: Stephen Farrell (Baltimore Technologies), Irving Reid (Baltimore Technologies), Hal Lockhart (BEA Systems), David Orchard (BEA Systems), Krishna Sankar (Cisco Systems), John Hughes (Entegrity), Carlisle Adams (Entrust), Tim Moses (Entrust), Nigel Edwards (Hewlett-Packard), Joe Pato (Hewlett-Packard), Bob Blakley (IBM), Marlena Erdos (IBM), RL 'Bob' Morgan (Internet2), Marc Chanliau (Netegrity), Chris McLaren (Netegrity), Prateek Mishra (Netegrity, co-chair), Charles Knouse (Oblix), Simon Godik (Overxeer), John Linn (RSA Security), Rob Philpott (RSA Security, co-chair), Darren Platt (formerly of RSA Security), Jahan Moreh (Sigaba), Jeff Hodges (Sun Microsystems), and Phillip Hallam-Baker (VeriSign, former editor).

• Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0. Scott Cantor (Internet2), Frederick Hirsch (Nokia), and Eve Maler (Sun Microsystems). Last-Call Working Draft [Pre Committee Draft] version 16. 13-July-2004. 36 pages. Document identifier: 'sstc-saml-bindings-2.0-draft-16'. "This specification defines protocol bindings for the use of SAML assertions and request-response messages in communications protocols and frameworks."

  Contributors: Krishna Sankar (Cisco Systems), John Hughes (Entegrity Solutions), Tim Moses (Entrust), Evan Prodromou (former member), Irving Reid (Hewlett-Packard), Bob Blakley (IBM), Marlena Erdos (IBM), RL 'Bob' Morgan (Internet2), John Kemp (Nokia), Simon Godik (Overxeer), John Linn (RSA Security), Jahan Moreh (Sigaba), Chris Ferris (formerly of Sun Microsystems), and Jeff Hodges (Sun Microsystems).

• Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0. Edited by Frederick Hirsch (Nokia), Scott Cantor (Internet2), John Hughes (Entegrity), Prateek Mishra (Netegrity), and Eve Maler (Sun Microsystems). Last-Call Working Draft [Pre Committee Draft] version 15. 13-July-2004. 53 pages. Document identifier: 'sstc-saml-profiles-2.0-draft-15'. "This specification defines profiles for the use of SAML assertions and request-response messages in communications protocols and frameworks, as well as attribute syntax for use in attribute statements." See also the associated Enhanced Client Profile schema.

• Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0. Edited by Jahan Moreh (Sigaba), Scott Cantor (Internet2), and Eve Maler (Sun Microsystems). Last-Call Working Draft [Pre Committee Draft] version 08. 13-July-2004. 32 pages. Document identifier: 'sstc-saml-metadata-2.0-draft-08'. "SAML profiles require agreements between system entities regarding identifiers, binding support and endpoints, certificates and keys, and so forth. A metadata specification is useful for describing this information in a standardized way. This document defines an extensible metadata format for SAML system entities, organized by roles that reflect SAML profiles. Such roles include that of Identity Provider, Service Provider, Affiliation, Attribute Authority, Attribute Requester, and Policy Decision Point." See also the associated Metadata schema.

• Authentication Context for the OASIS Security Assertion Markup Language (SAML) V2.0. Edited by John Kemp (Nokia) and Eve Maler, with contributions from Paul Madsen (Entrust). Last-Call Working Draft [Pre Committee Draft] version 07. 13-July-2004. 74 pages. Document identifier: 'sstc-saml-authn-context-2.0-draft-07'. "This specification defines a syntax for the definition of authentication context declarations and an initial list of authentication context classes for use with SAML." See the associated XML schemas for: Internet Protocol; Kerberos; Password; Password[-ppt]; Secure Remote Password; Smart Card PKI; Smart Card; Previous Session.

SAML Overview

Introduction. "Both browser and Web Services transactions blur the boundaries that separate business partners by the flow of application data across them. So too must identity management mechanisms — identity must flow across these boundaries as well, accompanying the fundamental transaction data.

Traditional authentication systems have required enterprises to maintain a one-to-one mapping of identity within their business systems for their customers, suppliers, and partners. In this model of identity management, customer identity data must be registered and maintained within the enterprise's electronic authentication databases.

This model, with this relatively tight coupling of identity data between business partners, does not easily scale to support today's dynamic business relationships. To support today's distributed transactions, what is needed are standardized mechanisms and syntax for the communication of identity information between business partners in a secure manner. The Security Assertion Markup Language (SAML) defines just such a standard.

What is SAML? The Security Assertions Markup Language (SAML), developed by the Security Services Technical Committee of the Organization for the Advancement of Structured Information Standards (OASIS), is an XML-based framework for communicating user authentication, entitlements and attribute information. As its name suggests, SAML will allow business entities to make assertions regarding the identity, attributes, and entitlements of a subject to other entities, which may be a partner company, another enterprise application, etc.

SAML is a flexible and extensible protocol designed to be used by other by other standards.The Liberty Alliance, the Internet2 Shibboleth project, and OASIS Web Services Security (WS-Security) have all adopted SAML as a technological underpinning to varying degrees.

SAML 1.0 became an OASIS standard in November 2002 (SAML 1.1 followed in September 2003) and has seen significant success within industry — gaining momentum in financial services, higher education, government, and other verticals. SAML has been broadly implemented by all major Web access management vendors. SAML is also supported in major application server products and SAML support is also common among Web services management and security vendors. SAML 2.0 builds on that success.

SAML Benefits

• Platform neutral: SAML abstracts the security framework away from particular vendor implementations and architectures
• Loose coupling of directories: SAML does not require user information to be maintained and synchronized between directores
• Improved online experience for end-users: SAML authentication assertions enables single sign-on by allowing users to authenticate at an identity provider and then access services/resources at service

SAML Applications. "How is SAML Being Applied? As befits a general framework for communicating security and identity information, SAML is being applied in a number of different manners, a number of which are presented here.

• Web SSO. In Web Single Single-On, a user authenticates to one web site and then, without additional authentication, is able to access some personalized or customized resources at another site. SAML enables Web SSO through the communication of an authentication assertion from the first site to the second which, if confident of the origin of the assertion, can choose to log in the user as if they had authenticated directly... A principal authenticates at the Identity provider and is subsequently appropriately recognized as (and given corresponding access/service) at the Service provider.

• Securing Web Services. SAML Assertions can be used as Security Tokens within SOAP Header blocks in order to carry security and identity information between actors in web service transactions. The SAML Token Profile of the OASIS WS-Security TC specifies how SAML assertions should be packaged into the WS-Security <Security> element in an interoperable manner. The Liberty Alliance's ID-Web Service Framework also uses SAML assertions as the base security token format for enabling security and privacy respecting access to identity-based web services.

• Attribute-based Authorization. Similar to the Web SSO scenario, the Attribute-based Authorization model has one web site communicating identity information about a principal to another web site in support of some transaction that principal is attempting to perform there. However, unlike the SSO scenario, the nature of the information is not an authentication assertion (i.e., that the principal authenticated at a certain time) but rather some other characteristic of the principal (e.g., their roles in a B2B scenario). The Attribute-based authorization model is important when the individuals particular identity is either not important or should not be shared (for privacy reasons)... [excerpted/adapted from the Executive Overview]

Why SAML?

Why is SAML required? There are four 'drivers' behind the creation of the SAML standard:

• Limitations of Browser cookies: Most existing Single-Sign On products use browser cookies to maintain state so that re-authentication is not required. Browser cookies are not transferred between DNS domains. So, if you obtain a cookie from www.abc.com, then that cookie will not be sent in any HTTP messages to www.xyz.com. This could even apply within an organization that has separate DNS domains. Therefore, to solve the Cross-Domain SSO (CDSSO) problem requires the application of different technology. All SSO products solve the CDSSO problem by different techniques.
• SSO Interoperability: How products implement SSO and CDSSO are completely proprietary. If you are an organization and you want to perform SSO across different DNS domains within the same organization or you want to perform CDSSO to trading partners, then you will have to use the same SSO product in all the domains.
• Web Services: Security within Web Services is still being defined. Most of the focus has been on how to provide confidentiality and authentication/integrity services on an end-to-end basis. The SAML standard provides the means by which authentication and authorization assertions can exchanged between communicating parties.
• Federation: The need to simplify identity management across organizational boundaries, allowing users to consolidate many local identities into a single (or at least a reduced set) Federated Identity..." [excerpted from the Security Assertion Markup Language (SAML) 2.0 Technical Overview, Working Draft 01 22-July-2004.]