The Java Zone is brought to you in partnership with AppDynamics. Discover how AppDynamics steps in to upgrade your performance game and prevent your enterprise from these top 10 Java performance problems.
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
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.
The Java Zone is brought to you in partnership with AppDynamics. AppDynamics helps you gain the fundamentals behind application performance, and implement best practices so you can proactively analyze and act on performance problems as they arise, and more specifically with your Java applications. Start a Free Trial.
Published at DZone with permission of
, DZone MVB
Opinions expressed by DZone contributors are their own.