SCDJWS Study Guide: XML Security


Printer-friendly version Printer-friendly version | Send this 
article to a friend Mail this to a friend


Previous Next vertical dots separating previous/next from contents/index/pdf Contents

SAML

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 SOAP calls 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 exchange security information across disparate systems and services. In a typical SAML cycle, the relying party, which needs to authenticate a specific client request, sends a SAML-based SOAP request to its issuing authority. The authority responds with a SAML assertion, which affirms the relying party with the security information requested.

There are mainly three kinds of assertions in the SAML realm. Regardless of their type, all of SAML assertions include the following information:

  • 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:

  1. It defines syntax and semantics of XML-encoded assertion messages.
  2. It defines request and response protocols between requesting and asserting parties for exchanging security information.
  3. It defines rules for using assertions with standard transport and message frameworks. For example, it defines how SAML assertion messages can transport using SOAP over HTTP.

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 other domains without re-authenticating. In other words, a client can access multiple resources in different domains without re-authenticating himself every time. In the Web services world, these "resources" are nothing but services that are available from different applications in different domains across the network. However, SAML can be used in various configurations to support additional scenarios as well. Several profiles of SAML are currently being defined that support different styles of SSO and the securing of SOAP payloads.

Authentication Statement

The authentication statement says that a specific subject was authenticated by the issuing 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.

Attribute Statement

The attribute statement describes specific attributes of a subject as name-value pairs. (Example: Subject A has been associated with attributes B, C, and D; and with 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 request/response messages should be transported across the authorities and parties by providing mappings between SAML messages and standard communication protocols. SAML 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 different underlying communications and transport protocols; SAML currently defines one binding, to SOAP over HTTP.

For example, the way to map SAML with SOAP over HTTP protocols has been defined; this paves the way for exchanging SAML information across several Web services in a standard manner.

A profile describes how SAML assertions are embedded into and extracted out of standard frameworks and protocol. Web browser profiles for single sign-on and SOAP profiles for securing SOAP payloads are some of the profiles defined.

References

http://www.oasis-open.org/committees/download.php/6837/sstc-saml-tech-overview-1.1-cd.pdf
http://www.awprofessional.com/articles/article.asp?p=28286



Previous Next vertical dots separating previous/next from contents/index/pdf Contents

  |   |