SAML
Encyclopedia
Security Assertion Markup Language (SAML) is an XML
-based open standard
for exchanging authentication
and authorization
data between security domains, that is, between an identity provider (a producer of assertions) and a service provider (a consumer of assertions). SAML is a product of the OASIS
Security Services Technical Committee.
The single most important problem that SAML is trying to solve is the Web Browser Single Sign-On (SSO
) problem, a problem also addressed by the OpenID
protocol. Single sign-on solutions are abundant at the intranet
level (using cookies
, for example) but extending these solutions beyond the intranet has been problematic and has led to the proliferation of non-interoperable proprietary technologies.
SAML assumes the principal (often a user) has enrolled with at least one identity provider. This identity provider is expected to provide local authentication services to the principal. However, SAML does not specify the implementation of these local services; indeed, SAML does not care how local authentication services are implemented (although individual service providers most certainly will).
Thus, a service provider relies on an identity provider to identify a principal. At the principal's request, the identity provider passes a SAML assertion to the service provider. On the basis of this assertion, the service provider makes an access control
decision.
Security Services Technical Committee (SSTC), which met for the first time in January 2001, was chartered "to define an XML framework for exchanging authentication and authorization information." To this end, the following intellectual property was contributed to the SSTC during the first two months of that year:
Building on this work, in November 2002 OASIS announced the Security Assertion Markup Language (SAML) V1.0 specification as an OASIS Standard.
Meanwhile, the Liberty Alliance
, a large consortium of companies and non-profit and government organizations, proposed an extension to the SAML standard called the Liberty Identity Federation Framework (ID-FF). Like its SAML predecessor, Liberty ID-FF proposed a standardized, cross-domain, web-based, single sign-on framework. In addition, Liberty described a circle of trust, where each participating domain is trusted to accurately document the processes used to identify a user, the type of authentication system used, and any policies associated with the resulting authentication credentials. Other members of the circle of trust may examine these policies to determine whether to trust such information.
While Liberty was developing ID-FF, the SSTC began work on a minor upgrade to the SAML standard. The resulting SAML V1.1 specification, ratified by the SSTC in September 2003, is widely implemented and deployed today. Then, in the same month, Liberty contributed ID-FF to OASIS, thereby sowing the seeds for the next major version of SAML. Thus in March 2005, SAML V2.0 was announced as an OASIS Standard. SAML V2.0 represents the convergence of Liberty ID-FF and other proprietary extensions, as well as early versions of SAML itself. Implementations and deployments of SAML V2.0 are in progress as of this writing (March-2007).
The Liberty Alliance contributed its Identity Federation Framework (ID-FF) to the OASIS SSTC in September 2003:
Extensible Markup Language (XML): Most SAML exchanges are expressed in a standardized dialect of XML
, which is the root for the name SAML (Security Assertion Markup Language).
XML Schema: SAML assertions and protocols are specified (in part) using XML Schema.
XML Signature: Both SAML 1.1
and SAML 2.0
use digital signatures (based on the XML Signature
standard) for authentication and message integrity.
XML Encryption: Using XML Encryption
, SAML 2.0
provides elements for encrypted name identifiers, encrypted attributes, and encrypted assertions (SAML 1.1 does not have encryption capabilities).
Hypertext Transfer Protocol (HTTP): SAML relies heavily on HTTP as its communications protocol.
SOAP: SAML specifies the use of SOAP, specifically SOAP 1.1.
A SAML binding determines how SAML requests and responses map onto standard messaging or communications protocols. An important (synchronous) binding is the SAML SOAP binding.
A SAML profile is a concrete manifestation of a defined use case using a particular combination of assertions, protocols and bindings.
<saml:Assertion ...>
...
</saml:Assertion>.
Loosely speaking, a relying party interprets an assertion as follows:
SAML assertions are usually transferred from identity providers to service providers. Assertions contain statements that service providers use to make access-control decisions. Three types of statements are provided by SAML:
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 authenticated principal (called the authentication context) may be disclosed in an authentication statement.
An attribute statement asserts that a subject is associated with certain attributes. An attribute is simply a name-value pair. Relying parties use attributes to make access-control decisions.
An authorization decision statement asserts that a subject is permitted to perform action A on resource R given evidence E. The expressiveness of authorization decision statements in SAML is intentionally limited. More-advanced use cases are encouraged to use XACML
instead.
The most important type of SAML protocol request is called a query. A service provider makes a query directly to an identity provider over a secure back channel. Thus query messages are typically bound to SOAP.
Corresponding to the three types of statements, there are three types of SAML queries:
Of these, the attribute query is perhaps most important (and still the object of much research). The result of an attribute query is a SAML response containing an assertion, which itself contains an attribute statement. See the SAML 2.0 topic for an example of attribute query/response.
Most of these protocols are completely new in SAML 2.0
.
This reorganization provides tremendous flexibility: taking just Web Browser SSO alone as an example, a service provider can choose from four bindings (HTTP Redirect, HTTP POST and two flavors of HTTP Artifact), while the identity provider has three binding options (HTTP POST plus two forms of HTTP Artifact), for a total of twelve (12) possible deployments of the SAML 2.0 Web Browser SSO Profile.
In SAML 1.1, all flows begin with a request at the identity provider for simplicity. Proprietary extensions to the basic IdP-initiated flow have been proposed (by Shibboleth
, e.g.).
Unlike previous versions, SAML 2.0 browser flows begin with a request at the service provider. This provides greater flexibility, but SP-initiated flows naturally give rise to the so-called Identity Provider Discovery problem, the focus of much research today.
In addition to Web Browser SSO, SAML 2.0 introduces numerous new profiles:
A number of these profiles are discussed in more detail in the SAML 2.0
topic.
1. Request the target resource at the SP (SAML 2.0 only)
The principal (via an HTTP user agent) requests a target resource at the service provider:
https://sp.example.com/myresource
The service provider performs a security check on behalf of the target resource. If a valid security context at the service provider already exists, skip steps 2–7.
2. Redirect to the SSO Service at the IdP (SAML 2.0 only)
The service provider determines the user's preferred identity provider (by unspecified means) and redirects the user agent to the SSO Service at the identity provider:
https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request
The value of the
encoding of a deflated
3. Request the SSO Service at the IdP (SAML 2.0 only)
The user agent issues a GET request to the SSO service at the identity provider where the value of the
4. Respond with an XHTML form
The SSO service validates the request and responds with a document containing an XHTML form:
The value of the
5. Request the Assertion Consumer Service at the SP
The user agent issues a POST request to the assertion consumer service at the service provider. The value of the
6. Redirect to the target resource
The assertion consumer service processes the response, creates a security context at the service provider and redirects the user agent to the target resource.
7. Request the target resource at the SP again
The user agent requests the target resource at the service provider (again):
https://sp.example.com/myresource
8. Respond with requested resource
Since a security context exists, the service provider returns the resource to the user agent.
Note: In SAML 1.1, the flow begins with a request to the identity provider's inter-site transfer service at step 3.
Alternatively, for increased security or privacy, messages may be passed by reference. For example, an identity provider may supply a reference to a SAML assertion (called an artifact) instead of transmitting the assertion directly through the user agent. Subsequently, the service provider requests the actual assertion via a back channel. Such a back-channel exchange is specified as a SOAP
message exchange (SAML over SOAP over HTTP). In general, any SAML exchange over a secure back channel is conducted as a SOAP message exchange.
On the back channel, SAML specifies the use of SOAP 1.1. The use of SOAP as a binding mechanism is optional, however. Any given SAML deployment will choose whatever bindings are appropriate.
Requirements are often phrased in terms of (mutual) authentication, integrity, and confidentiality, leaving the choice of security mechanism to implementers and deployers.
XML
Extensible Markup Language is a set of rules for encoding documents in machine-readable form. It is defined in the XML 1.0 Specification produced by the W3C, and several other related specifications, all gratis open standards....
-based open standard
Open standard
An open standard is a standard that is publicly available and has various rights to use associated with it, and may also have various properties of how it was designed . There is no single definition and interpretations vary with usage....
for exchanging authentication
Authentication
Authentication is the act of confirming the truth of an attribute of a datum or entity...
and authorization
Authorization
Authorization is the function of specifying access rights to resources, which is related to information security and computer security in general and to access control in particular. More formally, "to authorize" is to define access policy...
data between security domains, that is, between an identity provider (a producer of assertions) and a service provider (a consumer of assertions). SAML is a product of the OASIS
OASIS (organization)
The Organization for the Advancement of Structured Information Standards is a global consortium that drives the development, convergence and adoption of e-business and web service standards...
Security Services Technical Committee.
The single most important problem that SAML is trying to solve is the Web Browser Single Sign-On (SSO
Single sign-on
Single sign-on is a property of access control of multiple related, but independent software systems. With this property a user logs in once and gains access to all systems without being prompted to log in again at each of them...
) problem, a problem also addressed by the OpenID
OpenID
OpenID is an open standard that describes how users can be authenticated in a decentralized manner, eliminating the need for services to provide their own ad hoc systems and allowing users to consolidate their digital identities...
protocol. Single sign-on solutions are abundant at the intranet
Intranet
An intranet is a computer network that uses Internet Protocol technology to securely share any part of an organization's information or network operating system within that organization. The term is used in contrast to internet, a network between organizations, and instead refers to a network...
level (using cookies
HTTP cookie
A cookie, also known as an HTTP cookie, web cookie, or browser cookie, is used for an origin website to send state information to a user's browser and for the browser to return the state information to the origin site...
, for example) but extending these solutions beyond the intranet has been problematic and has led to the proliferation of non-interoperable proprietary technologies.
SAML assumes the principal (often a user) has enrolled with at least one identity provider. This identity provider is expected to provide local authentication services to the principal. However, SAML does not specify the implementation of these local services; indeed, SAML does not care how local authentication services are implemented (although individual service providers most certainly will).
Thus, a service provider relies on an identity provider to identify a principal. At the principal's request, the identity provider passes a SAML assertion to the service provider. On the basis of this assertion, the service provider makes an access control
Access control
Access control refers to exerting control over who can interact with a resource. Often but not always, this involves an authority, who does the controlling. The resource can be a given building, group of buildings, or computer-based information system...
decision.
History of SAML
The OASISOASIS (organization)
The Organization for the Advancement of Structured Information Standards is a global consortium that drives the development, convergence and adoption of e-business and web service standards...
Security Services Technical Committee (SSTC), which met for the first time in January 2001, was chartered "to define an XML framework for exchanging authentication and authorization information." To this end, the following intellectual property was contributed to the SSTC during the first two months of that year:
- Security Services Markup Language (S2ML) from Netegrity
- AuthXML from Securant
- XML Trust Assertion Service Specification (X-TASS) from VeriSign
- Information Technology Markup Language (ITML) from Jamcracker
Building on this work, in November 2002 OASIS announced the Security Assertion Markup Language (SAML) V1.0 specification as an OASIS Standard.
Meanwhile, the Liberty Alliance
Liberty Alliance
The Liberty Alliance was formed in September 2001 by approximately 30 organizations to establish open standards, guidelines and best practices for identity management...
, a large consortium of companies and non-profit and government organizations, proposed an extension to the SAML standard called the Liberty Identity Federation Framework (ID-FF). Like its SAML predecessor, Liberty ID-FF proposed a standardized, cross-domain, web-based, single sign-on framework. In addition, Liberty described a circle of trust, where each participating domain is trusted to accurately document the processes used to identify a user, the type of authentication system used, and any policies associated with the resulting authentication credentials. Other members of the circle of trust may examine these policies to determine whether to trust such information.
While Liberty was developing ID-FF, the SSTC began work on a minor upgrade to the SAML standard. The resulting SAML V1.1 specification, ratified by the SSTC in September 2003, is widely implemented and deployed today. Then, in the same month, Liberty contributed ID-FF to OASIS, thereby sowing the seeds for the next major version of SAML. Thus in March 2005, SAML V2.0 was announced as an OASIS Standard. SAML V2.0 represents the convergence of Liberty ID-FF and other proprietary extensions, as well as early versions of SAML itself. Implementations and deployments of SAML V2.0 are in progress as of this writing (March-2007).
Versions of SAML
SAML has undergone one minor and one major revision since V1.0.- SAML 1.0 was adopted as an OASIS Standard in November 2002
- SAML 1.1SAML 1.1Security Assertion Markup Language is an XML standard for exchanging authentication and authorization data between security domains. SAML is a product of the...
was ratified as an OASIS Standard in September 2003 - SAML 2.0SAML 2.0Security Assertion Markup Language 2.0 is a version of the SAML OASIS standard for exchanging authentication and authorization data between security domains. SAML 2.0 is an XML-based protocol that uses security tokens containing assertions to pass information about a principal between an...
became an OASIS Standard in March 2005
The Liberty Alliance contributed its Identity Federation Framework (ID-FF) to the OASIS SSTC in September 2003:
- ID-FF 1.1 was released in April 2003
- ID-FF 1.2 was finalized in November 2003
Differences between V1.1 and V1.0
Versions 1.0 and 1.1 of SAML are similar even though small differences exist.Differences between V2.0 and V1.1
The differences between SAML 2.0 and SAML 1.1 are substantial. Although the two standards address the same use case, SAML 2.0 is incompatible (on the wire) with its predecessor.Differences between V2.0 and ID-FF 1.2
Although ID-FF 1.2 was contributed to OASIS as the basis of SAML 2.0, there are some important differences between SAML 2.0 and ID-FF 1.2. In particular, the two specifications, despite their common roots, are incompatible (on the wire).SAML building blocks
SAML is built upon a number of existing standards:Extensible Markup Language (XML): Most SAML exchanges are expressed in a standardized dialect of XML
XML
Extensible Markup Language is a set of rules for encoding documents in machine-readable form. It is defined in the XML 1.0 Specification produced by the W3C, and several other related specifications, all gratis open standards....
, which is the root for the name SAML (Security Assertion Markup Language).
XML Schema: SAML assertions and protocols are specified (in part) using XML Schema.
XML Signature: Both SAML 1.1
SAML 1.1
Security Assertion Markup Language is an XML standard for exchanging authentication and authorization data between security domains. SAML is a product of the...
and SAML 2.0
SAML 2.0
Security Assertion Markup Language 2.0 is a version of the SAML OASIS standard for exchanging authentication and authorization data between security domains. SAML 2.0 is an XML-based protocol that uses security tokens containing assertions to pass information about a principal between an...
use digital signatures (based on the XML Signature
XML Signature
XML Signature defines an XML syntax for digital signatures and is defined in the W3C recommendation . Functionally, it has much in common with PKCS#7 but is more extensible and geared towards signing XML documents...
standard) for authentication and message integrity.
XML Encryption: Using XML Encryption
XML Encryption
XML Encryption, also known as XML-Enc, is a specification, governed by a W3C recommendation, that defines how to encrypt the contents of an XML element....
, SAML 2.0
SAML 2.0
Security Assertion Markup Language 2.0 is a version of the SAML OASIS standard for exchanging authentication and authorization data between security domains. SAML 2.0 is an XML-based protocol that uses security tokens containing assertions to pass information about a principal between an...
provides elements for encrypted name identifiers, encrypted attributes, and encrypted assertions (SAML 1.1 does not have encryption capabilities).
Hypertext Transfer Protocol (HTTP): SAML relies heavily on HTTP as its communications protocol.
SOAP: SAML specifies the use of SOAP, specifically SOAP 1.1.
The Anatomy of SAML
SAML defines XML-based assertions and protocols, bindings, and profiles. The term SAML Core refers to the general syntax and semantics of SAML assertions as well as the protocol used to request and transmit those assertions from one system entity to another. SAML protocol refers to what is transmitted, not how (the latter is determined by the choice of binding). So SAML Core defines "bare" SAML assertions along with SAML request and response elements.A SAML binding determines how SAML requests and responses map onto standard messaging or communications protocols. An important (synchronous) binding is the SAML SOAP binding.
A SAML profile is a concrete manifestation of a defined use case using a particular combination of assertions, protocols and bindings.
SAML Assertions
A SAML assertion contains a packet of security information:<saml:Assertion ...>
...
</saml:Assertion>.
Loosely speaking, a relying party interprets an assertion as follows:
Assertion A was issued at time t by issuer R regarding subject S provided conditions C are valid.
SAML assertions are usually transferred from identity providers to service providers. Assertions contain statements that service providers use to make access-control decisions. Three types of statements are provided by SAML:
- Authentication statements
- Attribute statements
- Authorization decision statements
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 authenticated principal (called the authentication context) may be disclosed in an authentication statement.
An attribute statement asserts that a subject is associated with certain attributes. An attribute is simply a name-value pair. Relying parties use attributes to make access-control decisions.
An authorization decision statement asserts that a subject is permitted to perform action A on resource R given evidence E. The expressiveness of authorization decision statements in SAML is intentionally limited. More-advanced use cases are encouraged to use XACML
XACML
XACML stands for eXtensible Access Control Markup Language. The standard defines a declarative access control policy language implemented in XML and a processing model describing how to evaluate authorization requests according to the rules defined in policies.As a published standard...
instead.
SAML protocols
A SAML protocol describes how certain SAML elements (including assertions) are packaged within SAML request and response elements, and gives the processing rules that SAML entities must follow when producing or consuming these elements. For the most part, a SAML protocol is a simple request-response protocol.The most important type of SAML protocol request is called a query. A service provider makes a query directly to an identity provider over a secure back channel. Thus query messages are typically bound to SOAP.
Corresponding to the three types of statements, there are three types of SAML queries:
- Authentication query
- Attribute query
- Authorization decision query
Of these, the attribute query is perhaps most important (and still the object of much research). The result of an attribute query is a SAML response containing an assertion, which itself contains an attribute statement. See the SAML 2.0 topic for an example of attribute query/response.
SAML 2.0 protocols
SAML 2.0 expands the notion of protocol considerably. The following protocols are described in detail in SAML 2.0 Core:- Assertion Query and Request Protocol
- Authentication Request Protocol
- Artifact Resolution Protocol
- Name Identifier Management Protocol
- Single Logout Protocol
- Name Identifier Mapping Protocol
Most of these protocols are completely new in SAML 2.0
SAML 2.0
Security Assertion Markup Language 2.0 is a version of the SAML OASIS standard for exchanging authentication and authorization data between security domains. SAML 2.0 is an XML-based protocol that uses security tokens containing assertions to pass information about a principal between an...
.
SAML bindings
A SAML binding is a mapping of a SAML protocol message onto standard messaging formats and/or communications protocols. For example, the SAML SOAP binding specifies how a SAML message is encapsulated in a SOAP envelope, which itself is bound to an HTTP message.SAML 1.1 bindings
SAML 1.1 specifies just one binding, the SAML SOAP Binding. In addition to SOAP, implicit in SAML 1.1 Web Browser SSO are the precursors of the HTTP POST Binding, the HTTP Redirect Binding, and the HTTP Artifact Binding. These are not defined explicitly, however, and are only used in conjunction with SAML 1.1 Web Browser SSO. The notion of binding is not fully developed until SAML 2.0.SAML 2.0 bindings
SAML 2.0 completely separates the binding concept from the underlying profile. In fact, there is a brand new binding specification in SAML 2.0 that defines the following standalone bindings:- SAML SOAP Binding (based on SOAP 1.1)
- Reverse SOAP (PAOS) Binding
- HTTP Redirect (GET) Binding
- HTTP POST Binding
- HTTP Artifact Binding
- SAML URI Binding
This reorganization provides tremendous flexibility: taking just Web Browser SSO alone as an example, a service provider can choose from four bindings (HTTP Redirect, HTTP POST and two flavors of HTTP Artifact), while the identity provider has three binding options (HTTP POST plus two forms of HTTP Artifact), for a total of twelve (12) possible deployments of the SAML 2.0 Web Browser SSO Profile.
SAML profiles
A SAML profile describes in detail how SAML assertions, protocols, and bindings combine to support a defined use case. The most important SAML profile is the Web Browser SSO Profile.SAML 1.1 profiles
SAML 1.1 specifies two profiles, the Browser/Artifact Profile and the Browser/POST Profile. The latter passes assertions by value whereas Browser/Artifact passes assertions by reference. As a consequence, Browser/Artifact requires a back-channel SAML exchange over SOAP.In SAML 1.1, all flows begin with a request at the identity provider for simplicity. Proprietary extensions to the basic IdP-initiated flow have been proposed (by Shibboleth
Shibboleth (Internet2)
Shibboleth is an Internet2 project that has created an architecture and open-source implementation for federated identity-based authentication and authorization infrastructure based on Security Assertion Markup Language . Federated identity allows for information about users in one security domain...
, e.g.).
SAML 2.0 profiles
The Web Browser SSO Profile has been completely refactored for SAML 2.0. Conceptually, SAML 1.1 Browser/Artifact and Browser/POST are special cases of SAML 2.0 Web Browser SSO. The latter is considerably more flexible than its SAML 1.1 counterpart due to the new "plug-and-play" binding design of V2.0.Unlike previous versions, SAML 2.0 browser flows begin with a request at the service provider. This provides greater flexibility, but SP-initiated flows naturally give rise to the so-called Identity Provider Discovery problem, the focus of much research today.
In addition to Web Browser SSO, SAML 2.0 introduces numerous new profiles:
- SSO Profiles
- Web Browser SSO Profile
- Enhanced Client or Proxy (ECP) Profile
- Identity Provider Discovery Profile
- Single Logout Profile
- Name Identifier Management Profile
- Artifact Resolution Profile
- Assertion Query/Request Profile
- Name Identifier Mapping Profile
- SAML Attribute Profiles
A number of these profiles are discussed in more detail in the SAML 2.0
SAML 2.0
Security Assertion Markup Language 2.0 is a version of the SAML OASIS standard for exchanging authentication and authorization data between security domains. SAML 2.0 is an XML-based protocol that uses security tokens containing assertions to pass information about a principal between an...
topic.
The SAML Use Case
The primary SAML use case is called Web Browser Single Sign-On (SSO). A user wielding a user agent (usually a web browser) requests a web resource protected by a SAML service provider. The service provider, wishing to know the identity of the requesting user, issues an authentication request to a SAML identity provider through the user agent. The resulting protocol flow is depicted in the following diagram.1. Request the target resource at the SP (SAML 2.0 only)
The principal (via an HTTP user agent) requests a target resource at the service provider:
The service provider performs a security check on behalf of the target resource. If a valid security context at the service provider already exists, skip steps 2–7.
2. Redirect to the SSO Service at the IdP (SAML 2.0 only)
The service provider determines the user's preferred identity provider (by unspecified means) and redirects the user agent to the SSO Service at the identity provider:
The value of the
SAMLRequest
parameter is the Base64Base64
Base64 is a group of similar encoding schemes that represent binary data in an ASCII string format by translating it into a radix-64 representation...
encoding of a deflated
element.3. Request the SSO Service at the IdP (SAML 2.0 only)
The user agent issues a GET request to the SSO service at the identity provider where the value of the
SAMLRequest
parameter is taken from the URL query string at step 2. The SSO service processes the AuthnRequest
and performs a security check. If the user does not have a valid security context, the identity provider identifies the user (details omitted).4. Respond with an XHTML form
The SSO service validates the request and responds with a document containing an XHTML form:
The value of the
SAMLResponse
parameter is the base64 encoding of a
element.5. Request the Assertion Consumer Service at the SP
The user agent issues a POST request to the assertion consumer service at the service provider. The value of the
SAMLResponse
parameter is taken from the XHTML form at step 4.6. Redirect to the target resource
The assertion consumer service processes the response, creates a security context at the service provider and redirects the user agent to the target resource.
7. Request the target resource at the SP again
The user agent requests the target resource at the service provider (again):
8. Respond with requested resource
Since a security context exists, the service provider returns the resource to the user agent.
Note: In SAML 1.1, the flow begins with a request to the identity provider's inter-site transfer service at step 3.
The use of SOAP
In the example flow above, all depicted exchanges are front-channel exchanges, that is, an HTTP user agent (browser) communicates with a SAML entity at each step. In particular, there are no back-channel exchanges or direct communications between the service provider and the identity provider. Front-channel exchanges lead to simple protocol flows where all messages are passed by value using a simple HTTP binding (GET or POST). Indeed, the flow outlined in the previous section is sometimes called the Lightweight Web Browser SSO Profile.Alternatively, for increased security or privacy, messages may be passed by reference. For example, an identity provider may supply a reference to a SAML assertion (called an artifact) instead of transmitting the assertion directly through the user agent. Subsequently, the service provider requests the actual assertion via a back channel. Such a back-channel exchange is specified as a SOAP
SOAP
SOAP, originally defined as Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks...
message exchange (SAML over SOAP over HTTP). In general, any SAML exchange over a secure back channel is conducted as a SOAP message exchange.
On the back channel, SAML specifies the use of SOAP 1.1. The use of SOAP as a binding mechanism is optional, however. Any given SAML deployment will choose whatever bindings are appropriate.
SAML security
The SAML specifications recommend, and in some cases mandate, a variety of security mechanisms:- SSL 3.0 or TLS 1.0 for transport-level security
- XML SignatureXML SignatureXML Signature defines an XML syntax for digital signatures and is defined in the W3C recommendation . Functionally, it has much in common with PKCS#7 but is more extensible and geared towards signing XML documents...
and XML EncryptionXML EncryptionXML Encryption, also known as XML-Enc, is a specification, governed by a W3C recommendation, that defines how to encrypt the contents of an XML element....
for message-level security
Requirements are often phrased in terms of (mutual) authentication, integrity, and confidentiality, leaving the choice of security mechanism to implementers and deployers.
Profiles of SAML
Aside from the SAML Web Browser SSO Profile, some important third-party profiles of SAML include:- OASISOasisIn geography, an oasis or cienega is an isolated area of vegetation in a desert, typically surrounding a spring or similar water source...
Web Services Security (WSS) Technical Committee - Liberty AllianceLiberty AllianceThe Liberty Alliance was formed in September 2001 by approximately 30 organizations to establish open standards, guidelines and best practices for identity management...
- OASISOasisIn geography, an oasis or cienega is an isolated area of vegetation in a desert, typically surrounding a spring or similar water source...
eXtensible Access Control Markup Language (XACML) Technical Committee
See also
- SAML 1.1SAML 1.1Security Assertion Markup Language is an XML standard for exchanging authentication and authorization data between security domains. SAML is a product of the...
- SAML 2.0SAML 2.0Security Assertion Markup Language 2.0 is a version of the SAML OASIS standard for exchanging authentication and authorization data between security domains. SAML 2.0 is an XML-based protocol that uses security tokens containing assertions to pass information about a principal between an...
- AuthenticationAuthenticationAuthentication is the act of confirming the truth of an attribute of a datum or entity...
- Single sign-on
- AuthorizationAuthorizationAuthorization is the function of specifying access rights to resources, which is related to information security and computer security in general and to access control in particular. More formally, "to authorize" is to define access policy...
- Federated identityFederated identityA federated identity in information technology is the means of linking a person's electronic identity and attributes, stored across multiple distinct identity management systems....
- ShibbolethShibboleth (Internet2)Shibboleth is an Internet2 project that has created an architecture and open-source implementation for federated identity-based authentication and authorization infrastructure based on Security Assertion Markup Language . Federated identity allows for information about users in one security domain...
- Athens access and identity managementAthens access and identity managementAthens is an Access and Identity Management service based in the United Kingdom that is supplied by Eduserv to provide single sign-on to protected resources combined with full user management capability...
- OpenIDOpenIDOpenID is an open standard that describes how users can be authenticated in a decentralized manner, eliminating the need for services to provide their own ad hoc systems and allowing users to consolidate their digital identities...
- Information CardInformation CardInformation Cards are personal digital identities that people can use online, and the key component of Identity metasystems. Visually, each Information 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...
s - WS-FederationWS-FederationWS-Federation is an Identity Federation specification, developed by BEA Systems, BMC Software, CA Inc., IBM, Layer 7 Technologies, Microsoft, Novell, Ping Identity, and VeriSign...
- OASISOASIS (organization)The Organization for the Advancement of Structured Information Standards is a global consortium that drives the development, convergence and adoption of e-business and web service standards...
- Light-Weight IdentityLight-Weight IdentityLID is a management system for online digital identities developed in part by . It was first published in early 2005, and is the original URL-based identity system, later followed by OpenID. LID uses URLs as a verification of the user's identity, and makes use of several open-source protocols...
External links
- Online Community for SAML OASIS Standard
- OASIS Security Services Technical Committee
- Cover Pages: Security Assertion Markup Language (SAML)
- Tutorial Video: Ten Things You Need To Know About SAML
- How to Study and Learn SAML
- Demystifying SAML
- First public SAML 2.0 identity provider
- Federated Identity: Single Sign-On Among Enterprises (SUN)
- Federated ID gains momentum
- SAML 101