Tuesday, September 14, 2010

SAML's Rise





The Secure Assertion Markup Language (SAML) is a federated XML framework for the exchange of security and identity information across domains. "As its name suggests, SAML allows business entities to make assertions regarding the identity, attributes, and entitlements of a subject (an entity that is often a human user) to other entities, such as a partner company or another enterprise application."


The IETF Journal has a good orientation article on SAML  ("It's the F Word") , excerpted below.

"As relationships among enterprises, service providers, and users became more interdependent, the challenge of obtaining lookup permissions from outside of an organization grew. In this new world, in order for a service in organization A to be able to accept users from organization B, the service in organization A needs permission to look up users in organization B’s directory. Even if the number of organization A’s and services is small, the problem of controlling access to organization B’s directories quickly becomes unmanageable.

Initially the solutions seemed to focus on Web applications (for the most part, they still do, though that is starting to change). Toward the end of the 1990s, the need to manage centralized authentication for Web applications drove the development of the so-called enterprise Web single sign-on solutions.

Out of those solutions a number of open-source and commercial options evolved, many of which relied on the management of HTTP cookies. Those solutions were also intraorganizational in nature and, as the need to connect Web SSO (single sign-on) products across organizational boundaries grew, there arose a need for a standardized protocol for communication authentication information between applications.

In January 2001, the OASIS Security Services Technical Committee (SSTC) convened to begin work on what became SAML (security assertion markup language), a technology that has become one of the cornerstones of federated authentication.

SAML can support several use-cases but the most commonly deployed pattern is called Browser Web SSO. This particular profile of SAML involves three actors: the user, the identity provider, and the service provider. SAML uses XML-based messages and relies on public key cryptography (although not necessarily on public key infrastructure [X.509] or PKIX) to sign and encrypt those messages. In a typical authentication flow the user presents credentials to the identity provider (IdP), thereby proving her identity to the IdP. The IdP then gives the user a SAML message called an assertion, digitally signed with the key of the IdP and optionally encrypted with the key of the service provider. The assertion can be thought of as a sealed envelope containing a statement to the effect that the user has successfully authenticated herself as well as the properties of the user the IdP wants to make known to the service provider. If the service provider trusts the public key of the IdP, the service provider is able to consume the assertion. The assertion often contains an identifier of the user and-more important-additional attributes associated with the user, relieving the service provider from having to conduct additional lookups in directories.

In the SAML federation model, identity information-identifiers and additional attributes-is pushed from the IdP to the SP. Conversely, enterprise authentication operates according to a pull model. This might seem a small difference but it fundamentally changes the way applications (service providers) consume identities.

At this point, the astute reader will undoubtedly ask: “But what about key management?” Indeed, key management is the core of the matter. Some federations still rely on traditional PKIX-style hierarchical PKI for key management. Others, including many large-scale SAML federations, rely on an alternative key-management method. In this method, collections of keys are collectively signed, resulting in an object that behaves like a combination of a PKI certificate and CRL (certificate revocation list). Incidentally, this bag-of-keys model has been considered by the KARP (Keying and Authentication for Routing Protocols) working group as the basis for routing protocol key management (albeit in that case using symmetric keys).

Common to all approaches to key management is a federation that consists of those identity providers and service providers that share trust in a set of keys. Such a trust framework is called a ring of trust. The deployment of OpenID typically relies on a single global ring of trust that encompasses all OpenID IdPs, and SPs. In fact, it is entirely possible that the success of OpenID is due in large part to the absence of a requirement on key management. Conversely, SAML federations often do require key-and-trust management, which constitutes a major part of the work involved in running a SAML federation."

Eve Maler prepared the following overview charts on SAML components:



2 comments:

Anonymous said...

Really excellent intro to SAML! My colleagues at Ping Identity couldn't have said it better. I'll pass it on to them via our internal newsletter. Thanks! TooTallSid

Anonymous said...

very helpful!!!