Existing brokered authentication standards such as SAML Web Browser SSO or OpenID accommodate RESTful web services for browser driven use cases. However, what about RESTful service composition patterns where identities need to be propagated across nested service invocations, or any RESTful Web service client that is not browser based for that matter? How should brokered authentication for such RESTful service calls be handled?

An interesting example of a RESTful Security Token Service (STS) was described in March 2009 by Pablo Cibraro (aka ‘cibrax’). In this post, cibrax offers a mapping between WS-Trust actions and HTTP VERBs as well as a .net implementation sample. In this case, Request Security Token (RST) and Request Security Token Responses (RSTR) are passed as payloads without SOAP envelopes. My favorite part of cibrax’s example is that once the token has been received by the RESTful client, cibrax chooses the standard ‘Authorization’ HTTP header as a vehicle for the token when consuming the RESTful Web service – arguably more RESTful than an ugly form parameter.

This illustrates that not only token services and identity providers must adapt to enable SAML for RESTful Web services. Service providers and brokers must also accommodate the support of such patterns and the standardization of a binding would further the adoption of SAML for RESTful Web services.