Authentication is often seen as a cheap and easy security solution but it is anything but. Authentication is a significant threat to re-use and it can cause a false sense of security that leaves services open to real threats. But when authentication is called for there are outstanding, well proven solutions that are almost certainly already in your data center – HTTP Digest and SSL. As I argue below, they are the right technologies for just about all your authentication needs.
The Hidden Costs of Authentication
Some of the cost of authentication is obvious, such as building and maintaining an authentication infrastructure or the threat from authentication systems as a single point of failure. But there is another, even more expensive cost; authentication is the enemy of re-use. When a service uses authentication anyone who wants to re-use that service has to figure out how to get added to the right access control list (ACL). And, people being people, the process of getting on the ACL will involve some kind of review and, of course, as time passes, that ACL process will just get more complicated. The danger of these processes is that they kill one of the most critical steps in the re-use process – just playing around. A developer who just wants to play with the service a bit and see if it might be useful won't ever get a chance because authentication will stop them at the front door. The end result will be that re-use will only happen when someone is ordered to do so and even then only if the need to re-use is so overwhelming that it's worth going through the pain of the approval process.
Even more fun, authentication can make security worse by acting as a placebo that lets developers tell themselves "I don't have to worry about detecting, mitigating and/or preventing 'bad things' because authentication will make sure that only 'good people' are allowed into the system." In reality however anything that a 'bad person' can do, a 'good person' can also do either by mistake or thanks to social engineering.
To make the situation even worse, at least 50% of security attacks are by the supposed 'good people'1, i.e. by your own employees. And if that's not enough, look around a typical office, how many computer terminals are left unlocked? Look at the rats nest of cables behind the computers, how many people would notice a gadget like this? Besides, who checks the CVS or other servers that the developers in the company use to write the services themselves? Sure, maybe the running service is protected three way from Sundays, but who is protecting the source code?
The conclusion I would have the reader draw isn't that authentication is useless, in the security business there is no perfection and layers of security is a good thing. But the only thing worse than no security (where you know you are exposed) is false security (where you don't worry because you think you're protected) and unfortunately authentication can often act as a false sense of security. So please, don't just assume that a service automatically needs authentication. Think about it. The goal should be to have the right kind of authentication which usually translates to the most minimal authentication possible.
Picking The Right SOA Authentication Technologies
In the vast majority of cases the best transport for SOA is HTTP and thankfully HTTP comes with an extremely well tested and widely supported authentication technology – HTTP Digest Authentication2. Digest is a great technology to use for SOA machine to machine communication. It is easy, free and uses the simplest of authentication techniques – name/password. It is also trivially easy to use with two factor authentication schemes. All in all, a very solid and simple first choice. HTTP Digest even supports mutual authentication so both the client and server can authenticate each other. When in doubt, go with what's proven, especially with security.
There are downsides to name/password authentication and they are well enough known that I won't belabor them here3. But I have to admit that I really haven't seen many situations that truly justified moving away from name/passwords. But if name/passwords just won't do it then the usual solution is PKI. I'm not as gaa gaa about PKI as many people. I think it was a fantastic solution to generic website authentication but for mutual authentication in service contexts I think it introduces some nastiness (especially around generating key pairs and sharing the results) and puts the business at risk of yet another single point of failure (the 'trusted' 3rd party screwing up). But if you absolutely must use PKI then luckily SSL is here to help. SSL of course is incredibly widely supported but what isn't widely known is that SSL supports mutual authentication so both sides of the communication can exchange certificates. Again, simple, well deployed, fully supported and most likely already on your box. It's all good.
An obvious argument against SSL in the case of PKI is end-to-end authentication. It turns out that the whole end-to-end argument is more smoke than substance but it's a big issue and I'll address it in its own article along with the issue of non-repudiation.
Conclusion
I hope the reader leaves this article with an understanding that authentication has real costs, costs that are often much higher than normally understood. This isn't to say that authentication shouldn't be used, but rather that developers need to take the time to understand what authentication really buys them and what it really costs. If and when authentication is called for the first choice should be HTTP Digest followed, as a distant second, by SSL.
1See Table 1 in CSI/FBI survey.
2HTTP digest uses MD5 hashes by default. Although this is configurable. While it is true that there are known attacks against MD5 my current limited understanding is that those attacks don't apply to digest's use of MD5 in the context of authentication. The attacks are about being able to create a source text which will generate a specific hash value. For example, if you see software with a widely published MD5 hash and you want to replace the real software with a fake one you could use the MD5 attack to generate your own program that will have the same MD5 hash as the original and fool everyone into thinking your copy is the 'real' thing. But in HTTP Digest MD5 is used to hide a shared secret. The only useful attack in this scenario is if you could reverse engineering the MD5 hash to get the original data and hence find the shared secret but hashes are lossy so at best you could generate an extraordinarily large series of values that could have been hashed into the resulting hash value. Still, I'm not a cryptography expert and your mileage will vary.
3From a service provider perspective name/passwords are a pain because you have to figure out how to authenticate the service consumer out of band and then figure out how to securely send them their name/password and then deal with updating the name/password occasionally. For a service consumer the pain is that you end up with multiple out of band authentication processes for each and every service you use not to mention having to keep track of a different name/password for all of those services as well as dealing with password renewals for multiple services. It is worth pointing out however that these problems are less of an issue for services than for people. Services can use insanely long and complex names/passwords so password renewal isn't a big deal. Furthermore the multiple name/password management problem is no big deal for a service, it's a machine, it will just stick them into a table.
Thanks for this authentication article, maybe it helps me in an early design phase, now when I have decided to implement “a nice little” SIP AAA protocol in a little VoIP conference prototype node. Let me know if there is more articles like this! It’s nice to read these while you try to find good RFC’s,,,yeah,,there is many of those!
Have an exellent day!
///Minna, one happy IT-woman from Finland =)
Actually if you go to the SOA Articles section of my website you will find numerous articles dealing with SOA in general and security in particular. You might also want to check out my articles on protocol design as much of that content is actually inspired by my experiences in the IETF writing RFCs. In any case, I’m glad you found this article useful.