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:
- SAML 1.0, adopted as an OASIS standard in November, 2002 (this is the version that the e-authentication initiative has adopted)
- SAML 1.1, formalized as an OASIS standard in September, 2003 (this is the version around which most existing implementations are built)
- SAML 2.0 became an OASIS standard in March 2005
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:
- Authentication statements: These assert to a service provider that a security principal has authenticated with an identity provider at a specific identified time using a specific identified method of authentication. Other information about a principal may also be included in such a statement, such as the principal's e-mail address.
- Attribute statements: These provide information about security principals to indicate whether or not they possess specific attribute values, which service providers will often use to grant or deny access to specific information or resources. Thus, for example, if a principal has an affiliated attribute value of "employee," that principal may then be allowed to access employee-only records or information about benefits, retirement plans and so forth.
- Authorization decision statements: These indicate whether or not a principal should be allowed or denied access to a secured resource associated with some specific uniform resource identifier (URI). This permits a Web server to delegate such decision making to security servers, often to the same server that provides identity management and authentication services.
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 message, 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:
- Browser/artifact Profile
- Browser/POST Profile
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.
