Ways to protect a Web Service

I'm having a hot discussion with a fellow at work about different ways to protect a Web Service and we're of course having different opinions about this. If you look at the Web Service method or end-point as a resource available on a network and you want to protect that resourse from being called by someone who isn't allowed - how should you do it?

My friend works for a LARGE company that has a web access management product and he is a product specialist, and this product is pretty good at protecting URL sources. So, he naturally suggests that we use this product and put an access layer in front of all our Web Services. Each Web Service proxy/client must then add a special HTTP header or encrypted cookie that this access management agent looks for before it's allowed to access the service method. Each Web Service method has a unique URL or URI so we just configure it as a protected resource in the access management catalogue and put it's agent (which is a ISAPI filter) on each Web Service server. We don't want to protect the resource with basic authentication because we prefer not to store uid and pw on the machine. Each end user will be using a web browser and also be authenticated through this product, so each user will have a unique and encrypted cookie which can be used to protect each Web Service as well.

This will probably work pretty fine, and you get rid of access management stuff from the Web Service implementation. But I don't like this solution, for several reasons, but mainly: 

1. I personally believe that each service should be autonomous and take care of it's own user authentication. In this case I would send the user id as an encrypted token in a SOAP header or implement WS-Security, and do user authentication in a SOAP filter or similar so that Web Service method implementors didn't have to worry about it. Keep out of band data away from message implementation. Besides, isn't this what WS-Security is all about?

2. I don't like to have HTTP headers or cookies added to the SOAP message. Doesn't that make you transport protocol dependant? What if the services were moved to the back end of MQ or something similar in the future?

What do you think? Do you see any other reasons to use or not use an access management layer in front of and separated from the Web Service?

If you know about any good resources on the Net (papers, talks, web cast etc.) that brings this matter up, please write a comment about it. Pat Helland talks much about autonomous services and fiefdoms, and how they should take care of everything themselves, but I've not read or heard much about protecting access to Web Services.


  • Using WS-Security (and, possibly, WS-SecureConversation) is definitely the way to go.

    I would strongly recommend the Web Services Enhancements (WSE) for your implementation. Among its *many* features, WSE is transfer/transport-agnostic and supports [custom] policy assertions for enforcement/validation. Note: This includes wse:Role for authorization purposes.

  • I agree that WSE sounds like a good way to go for the .NET Web Services. We will also have Web Services implemented in Java and I'll look for a SOAP toolkit for Java that has WS-S support.

    I was not familiar with wse:Role for authorization. Thanks!

Comments have been disabled for this content.