Service Security

At my current job we have been working at trying to get a good solution in place for web services. We have requirements that are not too unique:

Follow the Robustness Principle:

“be conservative in what you do, be liberal in what you accept from others”

We wanted to build an API which may be used internally, while also being used by vendors and partners in our B2B scenarios.

Our internal apps consist of both .NET and PHP, so we needed a solution which work across the board. The PHP guys wanted REST, but some customers and internal apps wanted to use SOAP.

We also wanted a flexible solution which would not require a lot of code duplication to get the job done.

What we finally settled on was WCF. In its latest incarnation, it supports REST and SOAP, while providing a very extensible framework which could be extended to meet our needs.

The biggest first hurdle we faced was authentication and security.

Security in the SOAP world can be a complicated mess of WS-* standards, certs, etc… I have gone down that road before, in the name of “standards compliance”, but it does require quite a bit of complicated configuration, coordination and testing, especially in the interop world.

So, WS-Security was out.

Also, in the magical world of REST, we don’t have a unified, standard way of doing security. Usually, it is left to the application hosting the services to provide some sort of cookie-based auth which the services also pick-up on. When users are logged into the web app, the cookies are in place and the services are able to validate authentication occurred.

But, in an A2A (Application to Application) integration scenario, this kind of solution does not play well. We sometimes don’t have a user context and in the cases we do have an actual user, we sometimes don’t need to know the identity of that user. So, 80% of the time we are fine with one app talking to another app using some kind of application or system credentials and the “user’s” credentials stop at the app’s boundaries.

I researched ways to provide authentication and authorization, such as looking at the methods used by Amazon, Google, Flickr, and MySpace, etc. Much of these services are very concerned about the end user and “federated” identity. In the case of Flickr, they need the end user to know when another site or service is attempting to view/change/delete that user’s photos. They want to ensure delegated authentication occurrs, ensuring that third-party sites are not storing their user’s credentials. We did not have that problem.

These services also use tokens and API keys with authentication services. The authentication service grants the user a temporary token, based on the API key and credentials presented. That token is then used to call the services that return data. We wanted a simpler, one-call approach where consumers would provide credentials along with their request message.

We settled on using the old stand-by: Basic Authentication with SSL.

We would use a custom implementation of basic authentication which would provide flexibility in the Authentication and authorization mechanisms. We require this flexibility because a service may be fronting a system using its own proprietary authentication scheme or the service may be able to utilize Active Directory security or LDAP.

The custom basic authentication mechanism had to be pluggable and extensible.

In a later post, I will explain how we implemented this authentication scheme.