Secure your REST-based WCF service with WIF, part 1

 

In this particular scenario we have a REST API built on WCF and ASP.NET which exposes resources owned by some imaginary users, and we want to make their resources accessible to third-party applications (clients) in a secure way. That is, we want to allow our users to grant authorization to clients requesting access to their resources without handing over their username and password to the third-party. In that sense this could be seen as a simplified implementation of a .NET OAuth Resource Server.
Each and every request that the API receives must contain a valid SAML token. The token is expected to be found in the request’s authorization header and it must be signed by an OAuth Authorization Server which our service has a trust relationship with.

The focus in this initial post is on how to extend the request pipeline with a custom HTTP module that will hand over the SAML token to Windows Identity Foundation (WIF) to do its authentication and authorization logic.

The Visual Studio wizards that come with the WIF SDK makes the job easy when it comes to enabling claims-based identity for ASP.NET web applications as well as SOAP-based WCF services. However at the time of this writing, the SDK has no wizard that enables WIF on the kind of REST API that we are building here. We will get around this though by implementing our own WIF-enabling module. Below I will describe how to do this while showing important parts of a possible code implementation.

The HTTP module that we are going to create has mainly three roles. The first is to extract the SAML token from the authorization header. Secondly it will hand the token over to WIF that validates it according to the WIF configuration inside the web.config. Finally the module will attach the IClaimsPrincipal that it gets back from WIF to the current HTTP user.

Let’s see how we can accomplish all this:

First we need to create a class that implements System.Web.IHttpModule, let’s call it WifEnablingModule:


In its Init method we hook up to the following HttpApplication events:

The code in OnAuthenticateRequest goes as:

ContainsAuthorizationHeader() is an extension method on the Request object:

    whereas SendUnauthorizedResponse() is an extension method on HttpContext:

The last line above will immediately raise the EndRequest event:

 

The most interesting bits though is found in AuthenticateRequest:

In  AuthenticateRequest above we first extract the SAML token from the authorization header with the help of the following extension method:

We then check to see if the security token handler that we have configured in the WIF section of web.config can read the token, and given that it can, we tell it to validate the token.

Now we can create a new IClaimsPrincipal object and assigns it to the current HTTPContext user.

Finally we want to enable the HTTP module by adding it to the module collection in web.config:

We also need to register routes for our secured services in the global.asax.cs.

Summary: The focus in this post has been on how to secure a REST API, acting as a simple OAuth Resource Server, and built on WCF and ASP.NET by implementing a custom HTTP module and there by adding some custom code into the request pipeline where we extract a SAML token and hand it over to WIF to do its token authentication.

In part two we’ll talke a look on how to initialize the WIF configuration programmatically and also how to configure the WIF pipeline in the web.config file.

This Post Has 5 Comments

  1. Hi Stefan – in AuthenticateRequest(), ServiceConfiguration looks like it needs to be instantiated. Could I just create a new instance like so…

    ServiceConfiguration config = new ServiceConfiguration();

    or is it looking for a specific WIF config?

    Thanks for your help!

  2. nevermind… needed to read Part II to get the full picture.

    Thanks again!

  3. tu wea mas incompleta!!!!!!!
    vale hongo CTM!!!!

Leave a Reply

Close Menu