Contents

• Summary
• Bibliographic Information for SAML 2.0 Committee Drafts
• Related SAML Documents: WSS SAML Token Profile and XACML Profile for SAML
• SAML Introduction and Overview
• Principal References

Version 2.0 Committee Draft specifications for Security Assertion Markup Language (SAML) have been approved for public review by the OASIS Security Services Technical Committee.

SAML (Security Assertion Markup Language) "defines the syntax and processing semantics of assertions made about a subject by a system entity. In the course of making, or relying upon such assertions, SAML system entities may use other protocols to communicate either regarding an assertion itself, or the subject of an assertion. The specification defines both the structure of SAML assertions, and an associated set of protocols, in addition to the processing rules involved in managing a SAML system. SAML assertions and protocol messages are encoded in XML and use XML namespaces."

SAML assertions "are typically embedded in other structures for transport, such as HTTP POST requests or XML-encoded SOAP messages. The SAML bindings specification provides frameworks for the embedding and transport of SAML protocol messages. The SAML profiles specification provides a baseline set of profiles for the use of SAML assertions and protocols to accomplish specific use cases or achieve interoperability when using SAML features."

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 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, and SAML 1.1 followed in September 2003. SAML 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.

Public review of the SAML Version 2.0 Committee Draft documents begins on 2004-08-19 and ends 2004-09-19. Comments may be submitted to the TC using the online comment forms.

Bibliographic Information

• Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0. Edited by Scott Cantor (Internet2), John Kemp (Nokia), Rob Philpott (RSA Security), and Eve Maler (Sun Microsystems). Committee Draft 01. 18 August 2004. Document identifier: 'sstc-saml-core-2.0-cd-01'. 84 pages.

  "This specification defines the syntax and semantics for XML-encoded assertions about authentication, attributes, and authorization, and for the protocols that convey this information.

  "An assertion is a package of information that supplies one or more statements made by a SAML authority. SAML assertions are usually made about a subject, represented by the <Subject> element. However, the <Subject> element is optional, and other specifications and profiles may utilize the SAML assertion structure to make similar statements without specifying a subject, or possibly specifying the subject in an alternate way. This SAML specification defines three different kinds of assertion statements that can be created by a SAML authority. All SAML-defined statements are associated with a subject. The three kinds of statement defined in this specification are: (1) Authentication — the assertion subject was authenticated by a particular means at a particular time; (2) Attribute — the assertion subject is associated with the supplied attributes; (3) Authorization Decision — a request to allow the assertion subject to access the specified resource has been granted or denied..."

  "SAML protocol messages may be generated and exchanged using a variety of protocols. The SAML bindings specification describes specific means of transporting protocol messages using existing widely deployed transport protocols. The SAML profile specification describes a number of applications of the protocols defined in this section together with additional processing rules, restrictions, and requirements that facilitate interoperability... Specific SAML request and response messages derive from common types. The requester sends an element derived from RequestAbstractType to a SAML responder, and the responder generates an element adhering to or deriving from StatusResponseType... The protocols defined by SAML achieve the following actions: (1) Returning one or more requested assertions - includes a direct request of the desired assertions, as well as querying for assertions that meet particular criteria; (2) Performing authentication on request and returning the corresponding assertion; (3) Registering a name identifier or terminating a name registration on request; (4) Retrieving a protocol message that has been requested by means of an artifact; (5) Performing a near-simultaneous logout of a collection of related sessions ('single logout') on request; (6) Providing a name identifier mapping on request..."

• Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0. Edited by Scott Cantor (Internet2), Frederick Hirsch (Nokia), John Kemp (Nokia), Rob Philpott (RSA Security), and Eve Maler (Sun Microsystems). Committee Draft 01. 18 August 2004. Document identifier: 'sstc-saml-bindings-2.0-cd-01'. 42 pages.

  "Mappings of SAML request-response message exchanges onto standard messaging or communication protocols are called SAML protocol bindings (or just bindings). This specification defines protocol bindings for the use of SAML assertions and request-response messages in communications protocols and frameworks..."

• Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0. Edited by John Hughes (Entegrity Solutions), Scott Cantor (Internet2), Prateek Mishra (Netegrity), Frederick Hirsch (Nokia), Rob Philpott (RSA Security), Jeff Hodges (Sun Microsystems), and Eve Maler (Sun Microsystems). Committee Draft 01. 18 August 2004. Document identifier: 'sstc-saml-profiles-2.0-cd-01'. 62 pages.

  "This document specifies profiles that define the use of SAML assertions and request-response messages in communications protocols and frameworks, as well as profiles that define SAML attribute value syntax and naming conventions. A separate specification (Core) defines the SAML assertions and request-response protocol messages themselves, and another (Bindings) defines bindings of SAML protocol messages to underlying communications and messaging protocols... One type of SAML profile outlines a set of rules describing how to embed SAML assertions into and extract them from a framework or protocol. Such a profile describes how SAML assertions are embedded in or combined with other objects (for example, files of various types, or protocol data units of communication protocols) by an originating party, communicated from the originating party to a receiving party, and subsequently processed at the destination... For example, a SOAP profile of SAML describes how SAML assertions can be added to SOAP messages, how SOAP headers are affected by SAML assertions, and how SAML-related error states should be reflected in SOAP messages. Another type of SAML profile defines a set of constraints on the use of a general SAML protocol or assertion capability for a particular environment or context of use. Profiles of this nature may constrain optionality, require the use of specific SAML functionality (for example, attributes, conditions, or bindings), and in other respects define the processing rules to be followed by profile actors... Attribute profiles provide the definitions necessary to constrain SAML attribute expression when dealing with particular types of attribute information or when interacting with external systems or other open standards that require greater strictness. The intent of this specification is to specify a selected set of profiles of various kinds in sufficient detail to ensure that independently implemented products will interoperate..."

• Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0. Edited by Scott Cantor (Internet2), Jahan Moreh (Sigaba), Rob Philpott (RSA Security), and Eve Maler (Sun Microsystems). Committee Draft 01. 18 August 2004. Document identifier: 'sstc-saml-metadata-2.0-cd-01'. 37 pages.

  "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 Consumer, and Policy Decision Point."

• Authentication Context for the OASIS Security Assertion Markup Language (SAML) V2.0. Edited by John Kemp (Nokia), Rob Philpott (RSA Security), and Eve Maler (Sun Microsystems). Committee Draft 01. 18 August 2004. Document identifier: 'sstc-saml-authn-context-2.0-cd-01'. 77 pages. With XML schemas.

  "Authentication context is defined as the information, additional to the authentication assertion itself, that the service provider may require before it makes an entitlements decision with respect to an authentication assertion. Such context may include, but is not limited to, the actual authentication method used... If a service provider is to rely on the authentication of a Principal by an authentication authority (or more generally of another provider by an authentication authority), the service provider may require information additional to the assertion itself in order to assess the level of confidence they can place in that assertion. This specification defines an XML Schema for the creation of Authentication Context declarations — XML documents that allow the authentication authority to provide to the service provider this additional information. Additionally, this specification defines a number of Authentication Context classes; categories into which many Authentication Context declarations will fall, thereby simplifying their interpretation..."

• Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V2.0. Edited by Frederick Hirsch (Nokia), Rob Philpott (RSA Security), and Eve Maler (Sun Microsystems).Committee Draft 01. 18 August 2004. Document identifier: 'sstc-saml-sec-consider-2.0-cd-01'. 33 pages.

  "This non-normative document describes and analyzes the security and privacy properties of the OASIS Security Assertion Markup Language (SAML) defined in the core SAML specification and the SAML bindings and profiles specifications. The intent in this document is to provide information to architects, implementors, and reviewers of SAML-based systems about the following: (1) The privacy issues to be considered and how SAML architecture addresses these issues; (2) The threats, and thus security risks, to which a SAML-based system is subject; (3) The security risks the SAML architecture addresses, and how it does so; (4) The security risks it does not address; (5) Recommendations for countermeasures that mitigate those security risks..."

• Glossary for the OASIS Security Assertion Markup Language (SAML) V2.0. Edited by Rob Philpott (RSA Security), Jeff Hodges (Sun Microsystems), and Eve Maler (Sun Microsystems). Committee Draft 01. 18 August 2004. Document identifier: 'sstc-saml-glossary-2.0-cd-01'. 16 pages.

  "This [normative] specification defines terms used throughout the OASIS Security Assertion Markup Language (SAML) specifications and related documents... Some definitions are derived directly from external sources (referenced in an appendix), some definitions based on external sources have been substantively modified to fit the SAML context, and some are newly developed for SAML. The reader should refer to the external sources for definitions of terms not explicitly defined in this glossary. Some definitions have multiple senses provided: they are denoted by (a), (b), and so on. References to terms defined elsewhere in this glossary are italicized."

• Conformance Requirements for the OASIS Security Assertion Markup Language (SAML) V2.0. Edited by Prateek Mishra (Netegrity), Rob Philpott (RSA Security), and Eve Maler (Sun Microsystems). Committee Draft 01. 18 August 2004. Document identifier: 'sstc-saml-conformance-2.0-cd-01'. 17 pages. Committee Draft 01. 18 August 2004. Document identifier: 'sstc-saml-conformance-2.0-cd-01'. 17 pages.

  "This normative specification provides the technical requirements for SAML V2.0 conformance and specifies the entire set of documents comprising SAML V2.0... SAML V2.0 defines a number of named profiles. Each profile (other than attribute profiles) describes details of selected SAML message flows and can also be viewed as indivisible functionality that could be implemented by a software component. Implementation of a profile involves use of a binding for each message exchange included in the profile. A binding can be viewed as a specific implementation technique for achieving a message exchange. Section 2 of this document enumerates all of the different profiles defined by Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0. For each profile, the relevant SAML V2.0 message flows are listed, and for each message flow the set of possible bindings is also described. The combination of profile, message exchange and a selected binding is termed a SAML V2.0 feature. Section 3 describes the conformance matrix for SAML V2.0. A number of different operational modes or roles are identified. The conformance matrix describes describes the feature set that must be implemented by each operational mode..."

Related SAML Documents

• XACML Profile for SAML 2.0. From the OASIS XACML TC, Working Draft 04. 19 August 2004. Document identifier: 'oasis-xacml-profile-saml-wd-04'. Edited by Anne Anderson (Sun Microsystems) and Hal Lockhart (BEA). "This specification defines a profile for the use of the OASIS Security Assertion Markup Language (SAML) Version 2.0 to carry XACML 2.0 policies, policy queries and responses, authorization decisions, and authorization decision queries and responses. It also describes the use of SAML 2.0 Attribute Assertions with XACML. Using XACML with SAML 2.0, XACML document instances can be protected using the SAML guidelines for use of digital signatures and can be transported using SAML bindings to transport mechanisms." [source PDF]

• Web Services Security: SAML Token Profile.. Approved as an OASIS WSS TC Committee Draft. Reference: Working Draft 15. Edited by Phillip Hallam-Baker (VeriSign), Chris Kaler (Microsoft), Ronald Monzillo (Sun), and Anthony Nadalin (IBM). July 19, 2004. 36 pages. The WSS SAML Token Profile approved as an OASIS Committee Draft in July 2004 describes how to use Security Assertion Markup Language (SAML) Version 1.1 assertions with the Web Services Security (WSS): SOAP Message Security specification. It defines how SAML assertions are carried in and referenced from <wsse:security> headers and describes how SAML assertions are used with XML Signature to bind the statements of the assertions (i.e., the claims) to a SOAP message.

• SAML Implementation Guidelines. Working Draft. Version 01. 27-August-2004. 40 pages. Document identifier: 'sstc-saml-implementation-guidelines-draft-01'. Edited by Charles Knouse. Contributors: Liberty Identity Federation Framework (ID-FF) Implementation Guideline contributors. "This [draft] non-normative specification provides guidelines for the implementation of applications using SAML assertions, protocol, bindings, and profiles... Although the SAML specifications provide a basis for interoperability between implementations, implementers and deployers will make choices for authentication methods, session management and other components of a SAML implementation. Some of these choices will be dictated by the environment within which a particular implementation may operate (for example, mobile network infrastructure, or an enterprise software environment)..." Based on the Liberty ID-FF Implementation Guidelines, with Liberty-to-SAML changes: Ch. 1: Introduction: expanded SAML Architecture discussion; Ch. 2: User Agent Considerations: expanded cookie discussion, added caching section; Ch. 3: Security Considerations: mostly rewritten, more tutorial in nature, incorporated MTI security models; Ch. 4: Authentication: mostly unchanged; Ch. 5: Replication Considerations: new; Ch. 6: Guidelines for Mobile Environments: mostly unchanged, LECP-->ECP. Some details need to be checked by someone more knowledgeable about mobile environments; Ch. 7: Privacy Principles: unchanged..." [source PDF]

• Registration of MIME media type application/samlassertion+xml. Edited by Jeff Hodges. August 21, 2004. This document defines a MIME media type 'application/samlassertion+xml' for use with the XML serialization of SAML (Security Assertion Markup Language) assertions. The SAML specification sets (SAML Version 1.0, SAML Version 1.1, SAML Version 2.0) are work products of the OASIS Security Services Technical Committee (SSTC). The SAML specifications define XML-based constructs with which one may make, and convey, security assertions. Using SAML, one can assert that an authentication event pertaining to some subject has occured and convey said assertion to a relying party, for example. SAML assertions, which are explicitly versioned, are defined by [the Core document in these specification sets]... MIME media type name: application, MIME subtype name: saml+xml... Applications which use this media type: Potentially any application implementing SAML, as well as those applications implementing specifications based on SAML, e.g., those available from the Liberty Alliance Project..." See: (1) the earlier IETF I-D; (2) the announcement for this material, proposed as an Appendix to the SAML Bindings specification; (3) IESG Approves a Request to Register MIME Media Type application/samlassertion+xml. [cache]

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 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.]