WIF as it exists today is optimized for web applications (passive/WS-Federation) and
SOAP based services (active/WS-Trust). While there is limited support for WCF WebServiceHost
based services (for standard credential types like Windows and Basic), there is no
ready to use plumbing for RESTful services that do authentication based on tokens.
This is not an oversight from the WIF team, but the REST services security world is
currently rapidly changing – and that’s by design. There are a number of intermediate solutions,
emerging protocols and token types,
as well as some already deprecated ones.
So it didn’t make sense to bake that into the core feature set of WIF.
But after all, the F in WIF stands for Foundation. So just like the WIF APIs integrate
tokens and claims into other hosts, this is also (easily) possible with RESTful services.
Here’s how.
HTTP Services and Authentication
Unlike SOAP services, in the REST world there is no (over) specified security framework
like WS-Security. Instead standard HTTP means are used to transmit credentials and
SSL is used to secure the transport and data in transit.
For most cases the HTTP Authorize header is used to transmit the security
token (this can be as simple as a username/password up to issued tokens of some sort).
The Authorize header consists of the actual credential (consider this opaque
from a transport perspective) as well as a scheme. The scheme is some string that
gives the service a hint what type of credential was used (e.g. Basic for
basic authentication credentials). HTTP also includes a way to advertise the right
credential type back to the client, for this the WWW-Authenticate response
header is used.
So for token based authentication, the service would simply need to read the incoming Authorization header,
extract the token, parse and validate it. After the token has been validated, you
also typically want some sort of client identity representation based on the incoming
token. This is regardless of how technology-wise the actual service was built. In
ASP.NET (MVC) you could use an HttpModule or an ActionFilter. In
(todays) WCF, you would use the ServiceAuthorizationManager infrastructure.
The nice thing about using WCF’ native extensibility points is that you get self-hosting
for free.
This is where WIF comes into play. WIF has ready to use infrastructure built-in that
just need to be plugged into the corresponding hosting environment:
Representation of identity based on claims. This is a very natural way of translating
a security token (and again I mean this in the widest sense – could be also a username/password)
into something our applications can work with.
Infrastructure to convert tokens into claims (called security token handler)
Claims transformation
Claims-based authorization
So much for the theory. In the next post I will show you how to implement that for
WCF – including full source code and samples.
(Wanna learn more about federation, WIF, claims, tokens etc.? Click here.)
