In previous XML tips we've looked at (and around) the Security Assertion Markup Language, aka SAML. But in the wake of increasing adoptions and use—as for example, its adoption as a cornerstone of the US Federal E-Authentication Initiative—another look seems warranted and is bound to prove interesting.
As of March 2005, in fact, there are three versions of SAML available:
All of these standards are readily available through the OASIS Web site and through the CoverPages SAML page. For the purposes of this tip, however, we'll concentrate on SAML 1.1.
SAML 1.1 Assertions
As the name of this XML applications indicates, it's all about security assertions. In fact, SAML supports three types of security assertions, all of which developers who must manage distributed or cooperative applications can't help but appreciate:
SAML 1.1 Protocol
Within the SAML environment, the above-mentioned types of assertions are ferried within the SAML protocol, which follows a simple request-response structure. In this environment a SAML requester issues a SAML request message to a responder and the SAML responder replies with a SAML response message to the requester. These message structures are simple and relatively compact, where the headers identify the version of SAML in use, along with simple request and response IDs, as well as timestamps, and the payload contains one or more SAML statements (authentication, attribute or authorization decision statements, in other words).
SAML 1.1 defines a single binding to support message exchange. Known as the SAML SOAP binding, it requires that a compatible implementation must implement SAML over SOAP over HTTP (other transport mechanisms are allowed providing all protocol-independent aspects of the SAML SOAP binding are transparently preserved). The binding occurs on SOAP version 1.1, where a SAML requester wraps a SAML request message within the body of a SOAP mes
To continue reading for free, register below or login
To read more you must become a member of SearchSOA.com
sage, with a similar structure for replies from a SAML responder. The SOAP 1.1 specification also requires that if HTTP is used for transport, a SOAPAction HTTP header must be included in each HTTP request (this value may be something as simple as "SOAPAction: http://www.oasis-open.org/committees/security".
SAML also uses profiles to define the HTTP exchanges used to transfer security assertions from an identity provider to a service provider, where SAML 1.1 specifies two different types of browser-based single sign-on profiles:
Together these profiles support cross-domain single sign-on (SSO). SAML profiles start at an inter-site transfer service, managed by the identity provider. After visiting the inter-site transfer service, the principal is transferred to an assertion consumer service at the service provider, where the mechanism for transfer depends on the provider used (the browser/artifact type uses a redirect, the browser/POST type uses a POST request). For convenience each type of profile gets its own separate URL, where the one for the Browser/Artifact type is called an Artifact Receiver UTL and the Browser/POST type is called an Assertion Consumer URL. Whereas the Browser/Artifact type uses a "pull model" wherein the profile essentially passes an SSO assertion from the identity provider to the service provider by reference (a kind of back channel exchange in which the service provider pulls the assertion from the identity provider), the Browser/Post type uses a push model wherein the profile passes an SSO assertion by value and no back channel communication is needed (so the identity provider pushes the assertion to the service provider).
Either way, the contents of the request and response messages manage the dialog between identity and service providers and help developers offload the details of identity management and authentication from their own code. For most developers tasked with building safe, secure Web-based applications and services, this is a very good thing!
In a future tip, we'll tackle what's new and interesting with SAML 2.0 and cover its increases in capability and functionality.
About the author
Ed Tittel is a full-time writer and trainer whose interests include XML and development topics, along with IT Certification and information security topics. E-mail Ed at etittel@techtarget.com with comments, questions or suggested topics or tools for review.
