Why you should broker RESTful Web services with SAML
By Francois Lascelles
April 28, 2010 —
(Page 1 of 3)
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.
Related Search Term(s): REST, SAML, security
Share this link: http://sdt.bz/34309