Best practice for storing cross domain web service access credentials?

6
votes

I'm working on an application that will connect to various remote servers using a Web Service to retrieve some status information about those ( Windows ) machines.

It works well within a single domain where we can just use Windows Authentication and ensure that the user calling the services has the correct credentials. However if we are working across domains that is not going to work- we're going to need to store a set of credentials for a user with the requisite rights on the application side.

Is there a standard way of storing credentials for these purposes, some kind of central password store in Windows or a handy built in library to provide this kind of functionality? If not, what is the best approach to keeping the passwords on the central machine safe and make sure the remote machine credentials are available when those services need to be called?

I would expect this application to mostly be installed on one of the Windows Server operating systems- 2003 or 2008 - if that makes any difference to what is available.

2
windowsweb-servicespasswordscredentials

2 Answers

4
votes

I suggest you have a look at "Windows Identity Foundation". It may be overkill for you, or the prerequisite may not match, but it's anyway worth reading as its very instructive in terms of claims based architecture with Microsoft technology.

The two principal white papers for developers are:

3
votes

I assume that this is not a question of Silverlight or Flash application, those would have some special things...

I have used authentication system by Federation of Finnish Financial Services (used by all major Finnish banks). It goes like this:

Both your client and server have a secret key (or 2 keys).

You can store it e.g. to a custom place in Windows registry (which is easy with .NET and you can control the registry access). Don't hard-code the key to code, because otherwise someone could use reflection to get it. Also a custom xml-file in a folder could be dangerous, if the platform is not secure enough.

Then, we have the request, let's say WebService REST Url and there is some id:

http://myserver/MyItems/15

Now, we need to use a timestamp and an one-way hash-algorithm. There are lot of available ones like md5, SHA1, SHA512, ... (also built-in to the Microsoft .NET library). We calculate a hash-value over the id and timestamp (and maybe some other parameters).

To simplify a bit, those algorithms work like modulo-algorithm: Let's say that my id is 11, secret key is 3, then modulo 11 % 3 = 2, now the hash would be 2, and if you know the id (11) and hash (2), you can't get the secret key.

The real request would be like this:

http://myserver/MyItems/15?timestamp=20110304171900&hash=89A234BA645FD56

The service will check the hash. If some hackers would have enough time, they could guess valid requests. But the service will also check if the timestamp is ok, like between 5min past and 5min future. So you can't adjust the request because it would modify the hash.

And of course one more thing is to use the SSL protocol. Otherwise your requests could be read from a random proxy server.

I would also recommend the Windows Identity Foundation, but this is another option.