I’ve spoken to a few people lately about how to implement a security model in a service oriented architecture. Some people are just putting all their services in the same security group and letting them access whatever they want. Others talk about using a central gateway that handles all the permissions. Still others are having each of their applications expose it’s own security settings (API Keys, OAuth, etc).

Obviously there’d be no point in me researching anything if I didn’t put it in a blog post (aka my brain in the cloud), so hopefully if you’re looking for a *very* brief overview of how you might do security in your service oriented architecture, this will provide a modicum of use.

Identity Management

Found a great article from Microsoft here that describes essentially what Identity Management *is* exactly. In a SOA context, identity management is how you handle the digital identity of different services in your system. It consists of an identifier, credentials, and a series of attributes. All of theses play into access management, what your service will allow the caller to do.

The caller sends credentials to the service. The service then authenticates those credentials, like entering in a password. Normally this is when the service calls out to an authentication service with the credentials. The authentication service will then determine what those credentials have been authorized to do based on the attributes of the identity being authorized, and report back to the service with the results.

I’m not going to bother taking a stab at this really. You should just read this CloudFoundry article on it.

Basically it’s a solution to Identity Management. You have a centralized server that’s handling authentication, and all the services are using that to determine the level of permissions other services have.

TLS/Certificate Based Security

This is a great short and sweet post that covers what certificate based security is. It doesn’t mention how you’d actually go about implementing it, but at least gives you the view from 35K ft of how it might work.

Essentially from what I’m gathering, you roll your own certificate authority and issue certificates to all of your clients and servers. So instead of going to Digicert for your public certificates, you actually have an internal server that both issues those certificates and allows your clients and servers to authenticate that the certificates they’re being handed are valid.

In the event that you used this for your internal services, you would need an API gateway to handle all of your public API calls. Which brings us to..

API Gateway Pattern

This is pretty common when you want to expose your API to the world. In all likelihood, people externally have different use cases and needs than you do, and therefore the API that’s exposed to them should be different. So you write this new API endpoint + associated security model (think API keys), expose it to the internet, and now your external API consumers only talk to this endpoint. The endpoint has authentication to talk to whoever it wants to, and the gateway handles what the client has permission to do (or you could have the auth server handle this, if you’re using that model).

Netflix has an interesting use case, where they’ve decided that all the different consumers of the system need their own API gateway. Most interesting is the comments where I found people from Spotify and other companies who have tried this and failed miserably. However Netflix has found success with it, so perhaps it’d work for your needs. They expand on the API optimization here.