SAML1.1 was ratified as an OASIS standard in September 2003. The critical aspects of SAML1.1 are covered in detail in the official documents SAMLCore[1] and SAMLBind.[2] If you are new to SAML, you should probably read the introductory SAML topic first, and then the SAMLOverview[3] document from OASIS.
Prior to SAML1.1, SAML1.0 was adopted as an OASIS standard in November 2002. SAML has undergone one minor (V1.1) and one major revision (V2.0) since V1.0, which itself is a relatively simple protocol. SAML1.0 is of more than historical interest, however, since the US Federal E-Authentication Initiative has adopted SAML1.0 as its core technology.
Versions1.0 and 1.1 of SAML are similar. See SAMLDiff[4] for specific differences between the two standards. This article concentrates on SAML1.1 since it is an important standard upon which many other standards and implementations depend.
Warning: Implementers and deployers should note well that all code examples in this article are non-normative and for illustration purposes only. Consult the OASIS SAML specifications for normative requirements.
SAML 1.1 Assertions
SAML assertions contain statements that service providers use to make access control decisions. For instance, authentication statements assert to the service provider that the principal did indeed authenticate with the identity provider at a particular time using a particular method of authentication. Other information about the principal may be disclosed in an authentication statement. In the authentication statement below, for example, the e-mail address of the principal is asserted to the service provider:
An e-mail address (as in the above example) will suffice in a large number of situations. In some cases, however, additional information is needed before a service provider can make an access control decision. As an example, suppose that students are allowed to access scholarships data. An attribute statement can indicate whether or not the principal has an affiliation of "student", which the service provider uses to allow or deny access (resp.) to the scholarships application:
Attributes are often obtained from an LDAP directory, so consistent representations of attributes across security domains is crucial.
In the above example showing how a student might obtain access to a scholarships application, the service provider is functioning as both a policy enforcement point and a policy decision point. In some situations, it may be preferable to associate the policy decision point with the identity provider. In this case, the service provider passes a URI to the identity provider who asserts an authorization decision statement that dictates whether or not the principal should be allowed access to the secured resource at the given URI.
The three statement types are not mutually exclusive. For example, both authentication statements and attribute statements may be included in a single assertion (as shown above). This precludes the need to make subsequent round trips between the service provider and identity provider.
SAML 1.1 Protocols
A SAML protocol is a simple request-response protocol. A SAML requester sends a SAML Request element to a responder:
<samlp:Requestxmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"MajorVersion="1"MinorVersion="1"RequestID="aaf23196-1773-2113-474a-fe114412ab72"IssueInstant="2006-07-17T22:26:40Z"><!-- insert other SAML elements here --></samlp:Request>
Similarly, a SAML responder returns a SAML Response element to the requester:
<samlp:Responsexmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"MajorVersion="1"MinorVersion="1"ResponseID="b07b804c-7c29-ea16-7300-4f3d6f7928ac"InResponseTo="aaf23196-1773-2113-474a-fe114412ab72"IssueInstant="2006-07-17T22:26:41Z"><!-- insert other SAML elements here, including assertions --></samlp:Response>
The bindings and profiles needed to affect this message exchange are detailed in the following sections.
SAML 1.1 Bindings
SAML1.1 formally defines just one protocol binding, the SAML SOAP binding. A compatible SAML1.1 implementation must implement SAML over SOAP over HTTP (a synchronous protocol binding). Other transport mechanisms besides HTTP are permitted, provided the protocol-independent aspects of the SAML SOAP binding are observed (see section3.1.2 of SAMLBind[2]).
The SAML1.1 SOAP binding is built on top of version1.1 of SOAP (the numbering is purely coincidental). A SAML requester wraps a SAML Request element within the body of a SOAP message. Similarly, a SAML responder returns a SAML Response element within the body of a returned SOAP message. If there is an error, the responder returns a SOAP fault code instead.
Any SAML markup must be included in the SOAP body. SAML1.1 does not define any SAML-specific SOAP headers. A requester is free to insert any SOAP headers it wishes (although none are required).
Recall that in SOAP1.1, a SOAPAction HTTP header must be included with each HTTP request (although its value may be empty). A SAML requester may give the following value to the SOAPAction header:
A SAML responder must not depend on this value, however.
A secure connection is not required for SAML requests and responses, but in those situations where message integrity and confidentiality are required, HTTP over SSL3.0 or TLS1.0 with a server-side certificate is required.
A SAML responder may return a "403 Forbidden" response when it refuses to respond to a SAML requester. A responder must return a "500 Internal Server Error" response in the event of a SOAP error (a SOAP fault element must be included as well). Otherwise, a "200 OK" response is returned, even in the presence of a SAML processing error. Such a response will include a SAML Status element in the SOAP body.
SAML 1.1 Profiles
In general, profiles describe the use cases and message exchanges required to ultimately transfer assertions from an identity provider to a service provider. SAML1.1 specifies two Web Browser SSO Profiles:
Browser/POST Profile
Browser/Artifact Profile
The Browser/POST Profile relies on a "push" operation that passes an SSO assertion by value through the browser using HTTP POST. We say that the identity provider "pushes" the assertion to the service provider.
The Browser/Artifact Profile employs a "pull" mechanism. The profile essentially passes an SSO assertion from the identity provider to the service provider by reference (through the browser using HTTP Redirect), which is subsequently dereferenced via a back-channel exchange (i.e., the service provider "pulls" the assertion from the identity provider using SAML over SOAP over HTTP).
These profiles support cross-domain single sign-on (SSO). The specification does not define any additional profiles. In particular, SAML1.1 does not support a profile to secure a web service message nor does it support a single logout profile.
Both SAML1.1 profiles begin at the inter-site transfer service, which is managed by the identity provider. How the principal arrives at the transfer service in the first place is not dictated by the specification. See sections4.1 and 4.2 of SAMLOverview[3] for possible scenarios. In practice, a client accessing a secured resource at a service provider will be redirected to the inter-site transfer service at the identity provider, but the precise sequence of steps needed to accomplish this is not outlined by SAML1.1. (See section4.3 of SAMLOverview[3] for some rough ideas along these lines.) This scenario is thoroughly addressed in SAML2.0.
After visiting the inter-site transfer service, the principal is transferred to the assertion consumer service at the service provider. Exactly how the principal is transferred from the inter-site transfer service to the assertion consumer service depends on the profile used. In the case of the Browser/Artifact Profile, a redirect is used; in the case of the Browser/POST Profile, the client issues a POST request (with or without user intervention).
To expedite processing by the assertion consumer service, two separate URLs are specified:
Assertion Consumer URL (Browser/POST Profile)
Artifact Receiver URL (Browser/Artifact Profile)
These and other endpoint locations may be recorded in metadata files. Exactly how the identity provider obtains a trusted metadata file, or otherwise determines the trusted endpoint locations of a particular service provider, is out of scope with respect to SAML1.1.
Note that a conforming SAML1.1 identity provider must provide an inter-site transfer service. Similarly, a SAML1.1 service provider must provide an assertion consumer service.
Browser/POST Profile
The SAML1.1 Browser/POST profile specifies the following four (4) steps. The terminology used in the original specification has been modified slightly to conform to that of the SAML2.0 specification.
The message flow begins with a request directed at the IdP.
Request the Inter-site Transfer Service at the IdP
The principal (via an HTTP user agent) requests the Inter-site Transfer Service at the identity provider:
where target is the desired resource at the service provider, say, https://sp.example.com/home. In other words, the following GET request is issued by the user agent over SSL/TLS:
where the TARGET parameter has been preserved from step1. The value of the SAMLResponse parameter is the base64 encoding of a SAML Response element such as the following:
The SAML Response must be digitally signed by the identity provider.
Important: It is assumed that the principal has already established a security context at the identity provider, otherwise the Inter-site Transfer Service would be unable to provide an authentication statement in the SAML Response element.
Request the Assertion Consumer Service at the SP
The user agent requests the Assertion Consumer Service at the service provider:
This assumes of course that the page contains a single FORM element (forms[0]).
Respond to the principal's request
The Assertion Consumer Service consumes the SAML Response element, creates a security context at the service provider and redirects the user agent to the target resource.
Browser/Artifact Profile
The SAML1.1 Browser/Artifact profile specifies the following six (6) steps. The terminology used in the original specification has been modified slightly to conform to that of the SAML2.0 specification.
The message flow begins with a request directed at the IdP.
Request the Inter-site Transfer Service at the IdP
The principal (via an HTTP user agent) requests the Inter-site Transfer Service at the identity provider:
where target is the desired resource at the service provider, say, https://sp.example.com/home. In other words, the following GET request is issued by the user agent over SSL/TLS:
where artifact is a reference to an assertion the identity provider is willing to provide upon request.
Important: It is assumed that the principal has already established a security context at the identity provider, otherwise the Inter-site Transfer Service would be unable to provide an authentication statement.
Request the Assertion Consumer Service at the SP
The user agent requests the Assertion Consumer Service at the service provider:
Request the Artifact Resolution Service at the IdP
The Assertion Consumer Service at the service provider begins a back-channel exchange with the Artifact Resolution Service at the identity provider. A SAML SOAP message is bound to an HTTP POST request:
In this case, the authentication statement includes a NameIdentifier containing the principal's e-mail address.
Respond to the principal's request
The Assertion Consumer Service parses the SAML Response element, creates a security context at the service provider and redirects the user agent to the target resource.
SOAP is a messaging protocol specification for exchanging structured information in the implementation of web services in computer networks. Its purpose is to provide extensibility, neutrality, verbosity and independence. It uses XML Information Set for its message format, and relies on application layer protocols, most often Hypertext Transfer Protocol (HTTP), although some legacy systems communicate over Simple Mail Transfer Protocol (SMTP), for message negotiation and transmission.
Web Services Security is an extension to SOAP to apply security to Web services. It is a member of the Web service specifications and was published by OASIS.
Single sign-on (SSO) is an authentication scheme that allows a user to log in with a single ID and password to any of several related, yet independent, software systems.
Identity management (IdM), also known as identity and access management, is a framework of policies and technologies for ensuring that the proper people in an enterprise have the appropriate access to technology resources. IdM systems fall under the overarching umbrellas of IT security and data management. Identity and access management systems not only identify, authenticate, and authorize individuals who will be utilizing IT resources, but also the hardware and applications employees need to access. Identity and access management solutions have become more prevalent and critical in recent years as regulatory compliance requirements have become increasingly more rigorous and complex.
Security Assertion Markup Language is an open standard for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. SAML is an XML-based markup language for security assertions. SAML is also:
Shibboleth is a single sign-on log-in system for computer networks and the Internet. It allows people to sign in using just one identity to various systems run by federations of different organizations or institutions. The federations are often universities or public service organizations.
OpenID is an open standard and decentralized authentication protocol. Promoted by the non-profit OpenID Foundation, it allows users to be authenticated by co-operating sites using a third-party service, eliminating the need for webmasters to provide their own ad hoc login systems, and allowing users to log into multiple unrelated websites without having to have a separate identity and password for each. Users create accounts by selecting an OpenID identity provider and then use those accounts to sign onto any website that accepts OpenID authentication. Several large organizations either issue or accept OpenIDs on their websites, according to the OpenID Foundation.
XACML stands for "eXtensible Access Control Markup Language". The standard defines a declarative fine-grained, attribute-based access control policy language, an architecture, and a processing model describing how to evaluate access requests according to the rules defined in policies.
Yadis is a communications protocol for discovery of services such as OpenID, OAuth, and XDI connected to a Yadis ID. While intended to discover digital identity services, Yadis is not restricted to those. Other services can easily be included.
Security Assertion Markup Language 2.0 (SAML 2.0) is a version of the SAML standard for exchanging authentication and authorization identities between security domains. SAML 2.0 is an XML-based protocol that uses security tokens containing assertions to pass information about a principal between a SAML authority, named an Identity Provider, and a SAML consumer, named a Service Provider. SAML 2.0 enables web-based, cross-domain single sign-on (SSO), which helps reduce the administrative overhead of distributing multiple authentication tokens to the user.
WS-SecurityPolicy is a web services specification, created by IBM and 12 co-authors, that has become an OASIS standard as of version 1.2. It extends the fundamental security protocols specified by the WS-Security, WS-Trust and WS-SecureConversation by offering mechanisms to represent the capabilities and requirements of web services as policies. Security policy assertions are based on the WS-Policy framework.
Information cards are personal digital identities that people can use online, and the key component of an identity metasystem. Visually, each i-card has a card-shaped picture and a card name associated with it that enable people to organize their digital identities and to easily select one they want to use for any given interaction. The information card metaphor is implemented by identity selectors like Windows CardSpace, DigitalMe or Higgins Identity Selector.
XML documents typically refer to external entities, for example the public and/or system ID for the Document Type Definition. These external relationships are expressed using URIs, typically as URLs.
An identity provider is a system entity that creates, maintains, and manages identity information for principals and also provides authentication services to relying applications within a federation or distributed network.
An Extensible Resource Identifier is a scheme and resolution protocol for abstract identifiers compatible with Uniform Resource Identifiers and Internationalized Resource Identifiers, developed by the XRI Technical Committee at OASIS. The goal of XRI was a standard syntax and discovery format for abstract, structured identifiers that are domain-, location-, application-, and transport-independent, so they can be shared across any number of domains, directories, and interaction protocols.
Security Assertion Markup Language (SAML) is a set of specifications that encompasses the XML-format for security tokens containing assertions to pass information about a user and protocols and profiles to implement authentication and authorization scenarios. This article has a focus on software and services in the category of identity management infrastructure, which enable building Web-SSO solutions using the SAML protocol in an interoperable fashion. Software and services that are only SAML-enabled do not go here.
The SAML metadata standard belongs to the family of XML-based standards known as the Security Assertion Markup Language (SAML) published by OASIS in 2005. A SAML metadata document describes a SAML deployment such as a SAML identity provider or a SAML service provider. Deployments share metadata to establish a baseline of trust and interoperability.
A SAML identity provider is a system entity that issues authentication assertions in conjunction with a single sign-on (SSO) profile of the Security Assertion Markup Language (SAML).
A SAML service provider is a system entity that receives and accepts authentication assertions in conjunction with a single sign-on (SSO) profile of the Security Assertion Markup Language (SAML).
This page is based on this Wikipedia article Text is available under the CC BY-SA 4.0 license; additional terms may apply. Images, videos and audio are available under their respective licenses.
