How to Implement Security Around Web Services Within a Company

A topic has come up recently regarding Web Service Security. Not necessarily the bits in WSE 3.0 that you may be thinking of, but more about securing the services within a company.

For instance. We have been discussing the possibility of making certain functions available to the entire company through one or more web service endpoints. The issue comes down to who can access the web services. I see them being accessed in three different ways:

1. By a website. This website may or may not be impersonating the user accessing the site, so calls to the web service may be made as a real user, the IIS service account, or another service account that we may be impersonating for other reasons
2. By a batch program. Also running on a server, but usually running as a service account
3. By a windows application on the user's desktop, in which case the user's credentials will be used

Now, in theory we could leave the web services open for anyone. Ignorance is bliss, right? But the issue is, if an attacker gains access to our network and discovers the web services, he would have carte blanche to intellectual property. So open is no good.

We could lock them down using some el开发者_Go百科aborate home-brewed scheme for checking IP Addresses, usernames, etc. But that seems like it would be an administrative nightmare.

Any thoughts? We are tossing around a couple of ideas, but I wanted to see if anyone may have solved this type of problem already.

Thanks

---

At my company, we use X509 certs with encrypted signiture. This grants the greatest security to your service. To restrict access to your service, you can allow only the public certs of your clients. This of course means that your clients would also have to have their own certs. If your clients don't have their own certs, you can create your own using OpenSSL. I have used this app myself and created legitimate certs that can be used for encryption or handshake purposes. Also, I believe you can create custom policies for each of your clients and restrict access to your service functions by using a policy attribute on each function (may be lying but I think I have stumbled across this somewhere). Hope this helps.

---

If you are considering opening endpoints for internal use that's one thing, but how many likely internal customers will you have?

If the endpoints are going to drive Excel spreadsheets or BI data cubes that need dynamic data and can be used by a wide variety of people then you will need to consider security carefully. Perhaps you could publish a daily generated API key to a prominent page on the company intranet - so that internal users of the data would have a small inconvenience if they wanted to use the endpoints, but it doesn't become a nasty maintenance job for IT.

If the endpoints will be consumed by a handful of bespoke applications then I would suggest tightly coupling the security within the apps themselves (hard-coded in a config file and then encrypted). In this way the access can be widely used but not widely known.

Obviously only allow GETs (and make sure GETs are not POSTs or PUTs in disguise) and document every endpoint for senior management signoff. If senior management is happy with the risks of allowing access to the data then its really only a debate of how you lock it down.