Why you should broker RESTful Web services with SAML

RESTful Web services are gaining popularity in the enterprise community. For the new generation of Web 2.0 developers, REST (Representational State Transfer) represents a simpler alternative, a more lightweight approach than WS-*. Yet, although many RESTful services can operate without sophisticated security requirements, the ability to authenticate requesters may be required in some situations. That can be a challenge for RESTful Web services.

By extension, support for brokered authentication patterns with RESTful Web services is essential to their further adoption. Without the possibility of brokering authentication, RESTful Web services are confined to operating within identity silos. How should brokered authentication patterns be handled for such Web services?

RESTful Web services don’t have the benefit of rich security standards, and although many developers argue that existing mechanisms used on the Web today should suffice, it is common to see home-baked security mechanisms rolled out with these services. For example, think of identities passed as HTTP parameters, proprietary HTTP authorization schemes based on HMAC (hash-based message authentication code) as used by Amazon S3 or Windows Azure.

This is bad enough when developers coordinate the implementation of both the requester and the endpoint. Imagine what happens in the case of multi-party patterns involving brokered authentication in which a variety of authorities are at play. Home-baked security mechanisms are never a good option, and they are especially problematic for brokered authentication.

Brokered authentication patterns, where a trusted authority asserts the identity of a requester to a service provider, is the subject of two dominant standards: SAML (security assertion markup language) and OpenID. Although SAML and OpenID both provide the basis for brokered authentication, neither is a perfect match for RESTful Web services today.

OpenID is focused on Web applications (involving a browser), and SAML defines a number of different bindings supporting browser-driven transactions, as well as WS-Security bindings and WS-Trust, but no specific REST binding. Which of these two standards provides the better basis and better fit for REST?

OpenID is sometimes mentioned as a better fit for REST. Its supporters claim that it is simpler and more Web-focused. I believe however that SAML provides a better base for brokering authentication for RESTful Web-service patterns. This is especially the case where requesters are not browser-based, such as for rich clients and service composition patterns.

First of all, SAML is already supported by the enterprise and is already proven as a standard for Web-service interactions. The SAML standard is extensible. The numerous bindings, protocols and profiles are a testament to that aspect of SAML.

A number of great suggestions for a RESTful STS, such as REST-friendly gateways and policy enforcement points, have been proposed and are already supported by specialized enterprise infrastructure. Furthermore, the ability to attach and retrieve SAML assertions in ways that accommodate REST patterns, such as a SAML HTTP authorization scheme, are trivial to implement.

I do not agree with the argument that OpenID is simpler. If one looks at a sequence diagram for an OpenID-based authentication and a corresponding SAML Web browser SSO-based authentication, one clearly sees that the process is essentially the same.

So if the process is the same, what could be more complicated about SAML? Is it the format of the actual assertion and its parsing? Clearly SAML has a richer syntax, but the parsing of a SAML assertion is most often handled either by infrastructure or by implementing libraries as is the case for OpenID. A developer rarely handles the low-level parsing of the syntax of such assertions.

What left is there to support the claim that SAML is more complicated? Perhaps the richer family of SAML specifications requires more learning to get started than for OpenID. This richness, however, is what makes it possible for adapting SAML to new patterns, such as for RESTful Web-service interactions, in the first place.

Another advantage of SAML over OpenID is the strength of the security that is made possible. The Holder-of-Key and Sender-Vouches subject confirmation patterns defined by SAML enable stronger security where the trusted authority defines additional restrictions, thereby preventing the use of the assertion by any unauthorized party.

By contrast, OpenID only enables the equivalent of bearer-style confirmations; anybody with the ticket can impersonate the originally authenticated user. The concepts of Holder-of-Key and Sender-Vouches have a practical path to REST by combining SAML with SSL mutual authentication.

In the case of Holder-of-Key, for example, a RESTful Web service (or a policy enforcement point allowing access to it) would validate an incoming SAML assertion from a trusted issuer, and would then further validate that the requester presents the same client certificate as part of the SSL handshake as the one referred to by the SAML-issuing authority. This ensures that the assertion was not reused by some malicious requester. Using SSL also protects the client by allowing it to validate that it is sending its call to a trusted server (server authentication).

Again, we’re not talking about an interactive user accessing a Web resource using a browser here. Instead, this is about a rich client making a Web-service call. This requester may be an application, it may be another service (service composition pattern), etc. Although SSL mutual authentication is perceived as challenging to roll out for users, it is trivial for rich clients. This distinction is key to understanding the security needs for RESTful Web services in general and why OpenID is not a suitable option in this case.

The emergence of REST as an alternative to WS-* for implementing Web services does not eliminate the need for proper identity management. RESTful Web service developers, or the infrastructure governing their access, should not shy away from relying on SAML as a standard for implementing brokered authentication patterns. Although it would be useful to formalize such REST patterns in a dedicated profile, all the ingredients are there for implementing this today.

Francois Lascelles is technical director, Europe for Layer 7 Technologies, which sells SOA and cloud infrastructure.