In Pursuit of the Penultimate Internet Security System
Feature

More than just a version change, SAML 2.0 covers new ground in authentication and authorization; here are some considerations for migrating from SAML 1.1 to SAML 2.0

Although Microsoft has continued to vacillate in its commitment to Security Assertion Markup Language (SAML), its federated identity platform recently passed its first SAML 2.0 Interoperability test. For those not watching, this move indicates that the serious players are now all-in to this security protocol. A product of the Organization for the Advancement of Structured Information Standards (OASIS) Security Services Technical Committee, SAML is an XML-based standard for exchanging authentication and authorization data between security domains. At a concept level, SAML defines how an opaque structure with no discernible identifiers can be used among providers to represent a security principal, a system entity whose identity can be authenticated. Liberty Alliance, the de facto authority on SAML usage and terminology, states that a principal is often synonymous with "natural person" or "user."

The single most important problem that SAML was created to solve is the Web browser single sign-on (SSO) problem. Although SAML 1.1 provided a protocol for multisite authentication using a Web browser, it did not provide a multisite logout capability by design. To some technologists, this was viewed as a shortcoming. Even so, SAML 2.0 provides a multisite logout capability discussed further in this article. At the time of this writing, though, SAML is probably used more for providing SOAP Web services authentication and authorization as a WS-Security token.

While a number of SAML 2.0 improvements are aimed at better integration consistency and component symmetry, there are some true functionality changes worthy of a major software release, as opposed to a version change.

RBAC and SAML
Although SAML is useful as a Web application authentication mechanism, the model becomes more powerful when you use the SAML assertion to drive your enterprise application's role-based access control (RBAC). An enterprise-wide RBAC architecture would require provisioning users with group membership when designing and configuring identity providers (IdPs) and service providers (SPs) to consumer the group attributes on the assertion.

For SAML 2.0, the terminology used to describe various SAML system entities has been changed to incorporate terminology from the Liberty Alliance. SAML 2.0 adopts the term "identity provider" as opposed to "authentication authority." A "service provider" is still typically a website providing services (or goods).

At the specification-level, when implementing RBAC, the assertion or token needs to include a "Groups" attribute, which is used for application access control and privileges management. In this way, the token not only authenticates the principal to the site, but the group(s) attribute can be used to personalize and authorize the user experience. For most portal applications, SAML assertion processing and configuration is accomplished using an administration console, not programmatically.

For the most part, authorization logic, in a software system, is designed, developed, and configured in the application and application server layer. It is the responsibility of the application programmer, who typically is neither concerned with security nor particularly adept at it. For that reason, RBAC is truly the perennial bane of even the most vigilant CTO, since it falls in a computing netherworld that encompasses both system and application layers, where technical responsibilities and component roles are very gray and somewhat indeterminate.

That is why it comes as no surprise that "improper access control" was ranked fifth in the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors List (cwe.mitre.org/top25/). These widespread and critical programming errors can lead to serious software vulnerabilities. They are often easy to find and easy to exploit, and they are dangerous because they frequently allow attackers to completely take over the software, steal data, or prevent the software from working at all.

The Top 25 Most Dangerous Programming Errors List identifies three high-level vulnerability categories:

    * Insecure interaction between components
    * Risky resource management
    * Porous defenses

The "porous defenses" category contains vulnerabilities that could be resolved or mitigated by adopting a modern SAML security infrastructure. This category includes the following vulnerabilities:

    * Improper access control (Rank 5)
    * Reliance on un-trusted inputs in a security decision (Rank 6)
    * Missing encryption of sensitive data (Rank 10)
    * Use of hard-coded credentials (Rank 11)
    * Missing authentication for critical function (Rank 19)
    * Incorrect permission assignment for critical resource (Rank 21)
    * Use of a broken or risky cryptographic algorithm (Rank 24)

Although the SAML framework and specification is clearly a product of OASIS and Internet2's Shibboleth, SAML 2.0 enhancement requests are in many ways the result of feedback from experience with numerous deployments of SAML 1.1 in the industry.

Today, many organizations are now in the SAML "zone of indecision" - wondering whether to stay with version 1.1 or move to 2.0. Essentially, the decision to move to SAML 2.0, for many organizations, will most likely be based on whether the new features are compelling enough to force the software organization to:

    * Upgrade access manager applications
    * Reengineer SP configurations and possible versions
    * Rework application logic

Differences Between SAML 2.0 and 1.1
Although there are quite a few differences between SAML 2.0 and SAML 1.1 with respect to nomenclature and functionality, the following represent improvements in the specification, based on their potential usefulness in real-world technology deployments.

Universal Logout and SSO - SAML 2.0 works to resolve some of the issues with multisite authentication using a Web browser: It includes a Single Logout protocol, which supports near-simultaneous logout of sessions of Web SSO participants. For SAML 1.1, this type of "universal logout" functionality must be engineered in conjunction with the IdP's inherent cookie management behavior. For example, after authenticating an achieved SSO to multiple SPs, the user could be automatically logged out of all of those SPs at the request of the IdP. The Authentication Statement element has been renamed AuthnStatement and supports the concept of a session in support of single logout and other session management requirements.

The Authentication Request protocol provides support for SP-initiated Web SSO exchanges. This protocol allows the SP to make requests to an IdP and potentially control various aspects of the user authentication at the IdP: the binding to be used to return the response message, the set of SAML attributes to be included in the resulting assertion, and so on. In the context of this request, the SP can also indicate the desire to dynamically establish a new federated identity for the user.

Updated SAML Schema - The SAML schema extensibility mechanism has been updated: XML Schema Definition (XSD) element substitution has been blocked in favor of type extension. The "any" attribute wildcard has been added selectively to structures where it has been deemed valuable to add arbitrary attributes without having to create a schema extension, such as subject confirmation data and SAML attributes. This is a useful modification, since real-world implementations sometimes require transient, in-flight information that needs to be contained in an assertion, such as the login context of the incoming user. In effect, arbitrary XML attributes can now appear as attribute elements without a supporting extension schema.

On-The-Wire Specification - SAML 2.0 includes an on-the-wire representation, which will allow it to be used in conjunction with Financial Information eXchange (FIX) and other on-the-wire protocols. FIX Transport Independence provides a way for transport protocols, such as MQSeries, SOAP, and on-the-wire, to be used for FIX message transport instead of the traditional FIX over TCP.

Note that on-the-wire representations of SAML 2.0 assertions and protocol messages are incompatible with SAML 1 processors.

Encryption Support - SAML now supports the use of the W3C XML encryption recommendation to satisfy security requirements for several important SAML constructs. The signature element that allows for the digital signing of assertions and protocol messages has been positioned earlier in the content models. This refactoring allows for SP-bound exception-handling mechanisms to catch SAML messages that are improperly signed early in the parsing process, which should improve error-handling response time.

SAML 2.0 provides the ability to construct assertions that are more flexible and fungible with respect to organizational security requirements. New elements have been defined that can hold an encrypted SAML identifier. Additionally, an element has been defined that can hold an encrypted SAML assertion, and an attribute element has been defined that can hold an encrypted SAML attribute. Attribute statement elements can now hold both encrypted and unencrypted SAML attributes. SAML 2.0 permits attribute statements, name identifiers, or entire assertions to be encrypted.

Federation - "Security federation" describes scenarios in which no one group or organization manages all users and resources in a distributed environment. Instead, administrators in diverse domains must manage local security policies that support mutually beneficial transactions among their respective spheres of operation.

SAML 2.0 supports a NameID Management protocol that provides the ability to modify federated name identifiers or to terminate their use. The NameID Mapping protocol allows an SP that shares an identifier for a principal with an IdP to obtain a name identifier for the same principal in another format or one that is in another federated namespace. In effect, the user's context is shared between the IdP and another SP.

Profile Changes - The two original Web browser profiles (Browser/Artifact and Browser/POST) in SAML 1.1 have been consolidated into a single Web Browser SSO Profile. For basic SAML developers, this is a step forward, since the difference in these protocols was never readily discernible in practice. With a Browser/POST profile, a SAML assertion is included in the response that is sent to the SP. With a Browser/Artifact profile, a pointer to the SAML assertion is included in the query string of an HTTP 302 redirect to the SP. The SP in turn issues a direct SOAP/HTTP request back to the IdP, exchanging the artifact for the actual SAML assertion.

An Identity Provider Discovery Profile has been added that relies on the technique of creating common domain cookies. This protocol is reserved for organizations that need complex security infrastructures - deployments that have more than one IdP, for instance. SPs need a means to discover which IdPs a principal uses. The Identity Provider Discovery Profile relies on a cookie written in a common domain between IdPs and SPs. The Artifact Resolution Profile describes how the Artifact Resolution protocol is specifically used with SOAP over HTTP Binding to retrieve SAML protocol messages referred to by an artifact. The Name Identifier Mapping Profile describes how the Name Identifier Mapping protocol is specifically used with SOAP over HTTP Binding.

The Crystal Ball
Today, IT organizations from the federal government to Wall Street are strategically interested in moving to cloud computing and virtualization. This has created a tactical advantage for service-oriented architecture (SOA) technologies as the enabling cloud computing infrastructure. As a result, SAML, which can be used as a security token within Web applications, Web services, or on-the-wire applications, is now in position to become the de jure cloud computing security construct.

However, if we view the cloud computing stack as the forward engineering reference architecture, it appears that we are now approaching a zenith with respect to possible application layers. Faced with this daunting and, in some respects, bloated platform, any organization that is seriously concerned about application performance and robustness will try to find ways of reducing application layers. SAML 2.0's support of an on-the-wire representation for assertions and protocol messages is of particular interest here. The ability to build reliable applications, in the cloud or not, that do not rely on HTTP or TCP/IP yet are secure, based on accepted industry standards, is a potentially powerful solution. Essentially, the industry has built so much intelligence into the protocol that the underlying infrastructure becomes optional.

Most security mechanisms and security efforts within organizations are focused on preventing malicious activities, whether those threats are real or only perceived. This type of work is simply considered part of the cost of ownership for any application. Rarely is preemptive security viewed as a qualitative aspect or productivity-improving factor when accessing the value of a computer system. But consider that SAML, implemented properly, can improve the user's experience by providing seamless access to multiple sites and enhancing application personalization by taking advantage of authorization attributes included in the SAML assertion model. In a SOA environment, a SOAP message that includes a SAML 2.0 assertion can be annotated to provide information that service buses can use to route and transform incoming SOAP messages without modifications to the schema, further adding value to the functional capabilities of the enterprise-wide application.

To recommend SAML 2.0 over SAML 1.1 is not just a matter of keeping current with technology. SAML 2.0 provides a complete distributed SSO experience, whereas SAML 1.1 has some serious shortcomings. For some organizations, the move will require significant investment in access manager technologies (such as Tivoli Access Manager or Oracle Access Manager), as well as new SP versions. There are also open-source alternatives, such as OpenSAML and Ping Identity. Either way, a considerable intellectual investment is required for the uninitiated.

Nevertheless, for the recalcitrant adopter, it is important to remember that change is neither benign nor nefarious; it just is.

Frank Teti is a consultant at Data Intelligence and can be reached at frank.teti@di-llc.com.

Jun2010, Software Magazine