views:

84

answers:

2

I have a web service that is outward-facing, however I need to generate a verification system to ensure that a request came from a valid client.

Let's say the original web service is defined as follows:

[OperationContract]
public void Service.RequestMethod (string clientId, int reqNumber,
    string reqText)
{
    // do stuff with the parameters
}

I want to make sure that the request actually came from the client specified by the clientId parameter.

My current plan is to add another parameter to the method signature, giving a checksum of sorts.

[OperationContract]
public void Service.RequestMethod (string clientId, int reqNumber,
    string reqText, string reqChecksum)
{
    // verify reqChecksum, then
    // do stuff with the parameters
}

I need a function that verifies that the checksum was calculated by the approved client. It should be calculated on the reqNumber and reqText parameters as well as a client-specific "password" known by both client and server.

In effect, it should be:

private bool VerifyChecksum(int reqNumber, string reqText,
    string clientPassword, string reqChecksum)
{
    // hash reqNumber, reqTxt, and clientPassword
    // ensure it matches reqChecksum
}

Does anyone have any suggestions for this hashing function or the model as a whole?

It needs to be message-specific, client-specific, and hard to guess (high entropy).

+1  A: 

You're probably looking for some kind of MAC. Something like MD5 for the hash. The whole idea of MD5 is that you apply it to "some" data and get a value. As long as the "some data" part is not known to everyone, it's almost impossible to reproduce the value.

krosenvold
I suspected it'd be called something specific. Thanks.
Damovisa
+1  A: 

Why not use one of the standard web services authentication methods? You'll have a choice of well-known and widely implemented solutions and won't muddy up your interface by trying to pass both parameters and authentication information.

You might still have an authorization problem if an authenticated client can pass more than one 'clientId', but again there are plenty of known solutions to this and it's entirely on your side. E.g., you could go as far as an ACL implementation that lists all acceptable (userId, clientId, methodname) combinations and forbids everything else.

bgiles
It's a good suggestion, but using existing authentication methods could be difficult. There's the possibility of methods being called in many ways (SOAP, REST, Remoting) from various locations. Freely accessible as long as you know the "password" is the aim...
Damovisa