SCDJWS Study Guide: XML Security
Security Assertions Markup Language (SAML) is an XML-based framework for exchanging authentication and authorization data between security domains, that is, between an identity provider and a service provider. SAML enables sharing security and profile information across different segments involved in business (for example, customers, partners, and suppliers), regardless of their own enterprise security frameworks.
SAML is being defined by the OASIS (Organization for the Advancement of Structured Information) security services technical committee. The committee aims to outline a standard XML framework for exchanging authentication and authorization information.
The SAML 1.0 specification set, released in Feb 2002, covers
- Assertions: XML schema and definitions for exchanging security "assertions" across the services
- Request/response protocol: XML schema and definitions for request/response model of transmitting security information
- Bindings: specific
SOAPcalls over HTTP for transmitting SAML requests and responses
- Profiles: for implanting and extracting SAML assertions
- Security considerations: while using SAML
- Conformance guidelines
- A Test suite: use cases and requirements
In order to achieve single sign-on capability in Web services (which is what SAML is all about), the participating services should all be SAML-compliant.
All about Assertions
As the name suggests, the concept of assertions lies at the very root of SAML. An assertion is a package of information that supplies one or more statements made by a SAML authority. The authority that issues assertions is known as the issuing authority. Applications and services, which trust the issuing authority and make use of its services, are called relying parties.
SAML makes use of the assertions concept to
security information across disparate systems and services. In a
cycle, the relying party, which needs to authenticate a specific client
request, sends a SAML-based
There are mainly three kinds of assertions in the
realm. Regardless of their type, all of SAML assertions include the
- Issuing authority and its timestamp
- Assertion ID
- Subject (Name + Security domain)
- Terms and conditions against which the current assertion is valid (assertion validity timeframe, audience restriction, target restriction, and so on)
- Additional "advice" (information on how the assertion was made, and so on)
SAML defines three kinds of statements that can be carried within an assertion:
- Authentication Statement
- Attribute Statement
- Authorization Decision Statement
The security information for exchanging is expressed in the form of assertions about subjects, where a subject is an entity (either human or computer) that has an identity in some security domain. A typical example of a subject is a person, identified by his or her email address in a particular Internet DNS domain.
Assertions can convey information about authentication acts performed by subjects, attributes of subjects, and authorization decisions about whether subjects are allowed to access certain resources. Assertions are represented as XML constructs and have a nested structure, whereby a single assertion might contain several different internal statements about authentication, authorization, and attributes. Note that assertions containing authentication statements merely describe acts of authentication that happened previously.
As a framework, it deals with three things:
- It defines syntax and semantics of XML-encoded assertion messages.
- It defines request and response protocols between requesting and asserting parties for exchanging security information.
- It defines rules for using assertions
with standard transport and message frameworks. For example, it defines
how SAML assertion messages can transport using
One major design goal for SAML is Single Sign-On (SSO), the
ability of a user to authenticate in one domain and use resources in
domains without re-authenticating. In other words, a client can access
resources in different domains without re-authenticating himself every
the Web services world, these "resources" are nothing but services
that are available from different applications in different domains
network. However, SAML can be used in various configurations to support
additional scenarios as well. Several profiles of SAML are currently
defined that support different styles of SSO and the securing of
statement says that a specific subject was authenticated by the
authority at a given time.
(Example: Subject A has been authenticated by means of methodology B at time C.)
One interesting fact is that the SAML authentication assertion merely informs you about an act of authentication that took place at a given time! It does not define any specific requirements or specifications for the actual authentication methodologies deployed (such as username-password checks, and so on). As of SAML 1.0, password exchange, challenge-response, and so on are not within the scope of SAML.
statement describes specific attributes of a subject as name-value
(Example: Subject A has been associated with attributes B, C, and D;
values E, F, and H at the time of this assertion.)
Authorization Decision Statement
The authorization decision statement says whether a given subject has been granted specific permissions to access a particular resource. (Example: Can subject A with evidence B be permitted to access resource C with privilege D at this time E?)
SAML does have the flexibility to extend this assertion framework and include custom-defined assertions based on the business need. But this comes at the cost of non-conformance to common and accepted standards.
If the issuing authority is hosted in a different domain, then the assertions can be digitally signed in order to ensure the authenticity of assertions.
SAML In Action
Let's look at the famous Producer—Consumer model of SAML interactions between the issuing authority and the relying party.
The cycle is as follows: The end user credentials are collected from the system entity by a credential collector and passed on to the relevant SAML issuing authorities. The authorities issue appropriate assertions, based on the policies that bind them. The assertions are then assembled into an SAML token.
Not all client requests need to go through all of these authorities, and the coordination among different authorities is not mandatory.
During the actual application request to access a specific resource, the system entity has to append the corresponding SAML token issued by the authorities. The policy enforcement point intercepts the request, and submits the SAML token to relevant SAML authority to decide whether the request can succeed or not.
SAML authorities can use various sources of information, such as external policy stores and assertions that were received as input in requests, in creating their responses. Thus, while clients always consume assertions, SAML authorities can be both producers and consumers of assertions.
SAML—Protocol Bindings and Profiles
Bindings define the standard way that SAML
messages should be transported across the authorities and parties by
mappings between SAML messages and standard communication protocols.
defines a protocol by which clients can request assertions from SAML
authorities and get a response from them. This protocol, consisting of
XML-based request and response message formats, can be bound to many
underlying communications and transport protocols; SAML currently
For example, the way to map SAML with
A profile describes how SAML assertions are
and extracted out of standard frameworks and protocol. Web browser
single sign-on and