Loading

Wednesday, February 3, 2010

RESTful STS

Secure Token Service (STS) typically have a SOAP endpoint with WS-Trust standard profiling the interactions. How about taking the complexity of SOAP away, and adding simplicity of REST interface to the STS? At the end of the day, STS is a token service that applications use to acquire tokens and should be accessible through different types of bindings - SOAP, REST, etc.

What would be the interaction pattern for such RESTful STS?
  1. Clients access RESTful STS using HTTP GET/POST method sending RequestSecurityToken (RST) as part of HTTP message.
  2. RESTful STS sends back the requested token as RequestSecurityTokenResponse (RSTR) in the HTTP response message.
  3. The STS endpoint could be secured similar to any HTTP resource using web access management products such as Oracle Access Manager (OAM) with username/password or certificate credentials.

RESTful STS can lead to wider adoption
Many languages/frameworks (such as Adobe Flex and Silverlight) doesn't support full capabilities of a SOAP stack. But, they support the basic HTTP interactions. Such frameworks could easily plug into a RESTful STS for their token needs.

Applicability of RESTful STS in the cloud
As cloud remains the innovation vehicle for 2010, I try to find applicability of any new concept into the cloud as well.
Today, Google, Amazon, Salesforce of the world provide RESTful APIs for all it's services. If they decide to broker trust using some sort of STS, then it makes perfect sense for them to provide RESTful STS with API keys and OpenId/OAUTH models to access it.