WCF 4.0 REST username password authentication

Question

I have been struggling with username/password authentication/authorization in a WCF 4.0 RESTfull service using the ASP.Net membership/role providers.

Having spent two days trying to find something that most people agree on, I gave up. A lot of confusion seems to be because there is little information specifically for WCF 4.0.

Could someone be kind enough to

1. Give an authoritative view on whether WCF 4.0 + REST is a good idea to begin with?
2. Outline the generally accepted steps to do this (or links).
3. Provide a reasonably complete sample of code needed to complete this.

Edit: Bounty for anyone who can provide a complete sample(or even just a link to a complete sample) with username/password Authentication and Authorization for a RESTfull WCF 4.0 service using the WCF service application template in VS 2010.

Answer 1

I think that the answer to your question depends on the purpose of your service and the type of applications that are going to consume it.

If you have an existing ASP .Net application and you want to expose part of its functionality as a RESTfull service which you would be able to consume client side using AJAX, then WCF might not be the best option. In this particular case you already have an authentication user inside the web application and you want that authentication to get propagated during the AJAX calls. Implementing this is actually quite simple.

ASP .Net Forms authentication is based on authentication cookies which are generated and passed to the browser after a successful login. Each call made from the browser to any URL on the same domain as your application will also contain the authentication cookie. In ASP .Net MVC you can simply implement your service methods as Controller actions which require authorization and everything will happen for you behind the scenes.

In classic ASP .Net you can use PageMethods to implement your service methods and again the cookie will be sent and validated behind scenes for you (examples of PageMethods here and here).

On the other hand, if your service is going to be consumed outside the browser (for example from desktop or mobile applications), then WCF might indeed be the right tool for implementing the service. However, ASP .Net forms authentication is not the best choice for implementing security. The main purpose of REST services is simplicity so that clients can easily be implemented on every platform and the cookie based mechanism of ASP .Net forms authentication is not the most straight forward.

One protocol, specifically build for user authentication in the context of web services, is OAuth. It's second version is still in draft (find the specs here), but most probably this is the version you will want to use, since it is much simpler than OAuth 1.0. Facebook has already implemented its API Authentication over OAuth 2.0 (details here) and you might want to check their implementation for inspiration.

Besides user authentication, OAuth also ensures consuming application (service client) authentication and also makes sure that the user will never enter its credentials directly inside the client application. If that is a bit too much that what you actually need, you might create a custom implementation inspired from OAuth 2.0.

First of all you will need to expose your service over HTTPS so that all the communication between the service and client is encrypted. Second you will need to create a login method in the service like the following:

string Login(string user, string password);

On a successful login, the above method will return an authentication token. The authentication token will then be used and validated on all the other methods. For example:

Employee[] GetAllEmployees(string authToken)
{
  // verify token here

  // return data if user authenticated by token
}

In the above architecture, the authToken has the same role as the authentication cookie in ASP .Net forms authentication, but it is passed as a simple parameter. You will be responsible to implement the algorithm of generating the tokens (they must be long enough and unique, with an algorithm like here) and also storing and validating them.