Friday, September 24, 2010

Securing WCF REST services for smartphone clients

In one of the projects that I’m working on we have to define the security model for calling REST services (WCF) from smartphone apps (iPhone/iPad, Android). The security requirements are the following:

  • Both the clients and servers are owned by the same organization so it’s basically the smartphone calling “home”.
  • The data to be transferred is not sensitive, so we can safely skip confidentiality concerns.
  • The services are read-only so integrity is ruled out as well.
  • Even though data is not confidential, users need to be authenticated (so for example we can establish quotas per user).

As REST over HTTP is all about HTTP standards, let’s have a look at what standard methods we can use for authenticating our users

  • HTTP Basic: The username and password are sent in clear text over the wire, this is not really an option unless you want to use HTTPS as well. As there is no need for confidentiality in our scenario, we’d rather not take the overhead of HTTPS on the smartphone devices which in some cases may be using slow internet connections.
  • HTTP Digest: The request is signed with a secret shared between the client and the server (password) and a salt (challenge) obtained by the client in a previous request to the server. The shared secret is not sent over the wire (no need for HTTPS), but an extra request is needed to get the challenge from the server .
  • WSSE Username token: This is an OASIS standard used by the SOAP WS-Security. The ATOM 1.0 protocol design committee, not having the possibility to use HTTP Basic or HTTP Digest, went for this option for providing an authentication mechanism to the ATOM API. Like the Digest method,  it uses the shared secret to sign some parts of the message. More info here: http://www.xml.com/pub/a/2003/12/17/dive.html
  • OAuth 1.0: OAuth is an open standard for authorization delegation: You can authorize 3rd party sites to access, for example, your profile in Facebook or Twitter without having to hand out your credentials to those sites. In our case we don’t need credential delegation but OAuth defines another workflow, known as 2-legged authentication (as opposed to the 3-legged default one) which follows a similar approach of the HTTP Digest and WSSE: the request is signed and verified with the shared secret.

WCF implementation

IIS implements HTTP Basic and HTTP Digest but it's tightly coupled to the company Active Directory, so obviously this is not suitable for Internet scenarios. The WCF REST Starter kit defines some extensibility points that allow to implement custom authentication methods like it’s explained here for HTTP Basic:

http://weblogs.asp.net/cibrax/archive/2009/03/20/custom-basic-authentication-for-restful-services.aspx

I've implemented HTTP Digest and WSSE UsernameToken methods (along with the HTTP Basic sample) by following that same approach. The code is available in github under the name WcfRestAuth. If you don’t use git, you can get the source code here. Any feedback will be welcome!

For OAuth and WCF you can check DevDefined.OAuth

1 comment:

  1. Could you provide a tutorial for WCF REST data encryption ?

    ReplyDelete