views:

57

answers:

2

The current situation is as follows: We have an production .net 3.5 WCF service, used by several applications throughout the organization, over wsHttpBinding or netTcpBinding. User authentication is being done on the Transport level, using Windows integrated security. This service has a method Foo(string parameter), which can only be called by members of given AD groups. The string parameter is obligatory.

A new client application has come into play (.net 3.5, C# console app), which eliminates the necessity of the string parameter. However, only calls from this particular application should be allowed to omit the string parameter. The identity of the caller of the client application should still be known by the server because the AD group limitation still applies (ruling out impersonation on the client side).

I found a way to pass on the "evidence" of the calling (strong-named) assembly in the message headers, but this method is clearly not secure because the "evidence" can easily be spoofed. Also, CAS (code access security) seems like a possible solution, but I can't seem to figure out how to make use of CAS in this particular scenario.

Does anyone have a suggestion on how to solve this issue?

Edit: I found another thread on this subject; apparently the conclusion there is that it is simply impossible to implement in a secure fashion.

A: 

sounds to me like you need to pull the security out into a seperate service ... go down a more federated route this way you can implement a handshake form of encryption using public and private keys to generate a secure session token in both situations.

this way you cna still get both windows a=uthentication and a custom solution in play whilst retaining your attributes on methods for security (I am assuming that you are implementing it this way.)

sounds like a fair bit of work though - I had to do this from scratch and ran into some cross domain / delegation issues. But I am sure the idea is good.

howver you will end up with a nice solid claims based secuirty model

John Nicholas
I must say that the idea of a custom handshake protocol crossed my mind (not in great detail, but it did :-) ), but I discarded it because I thought it would entail too much work and more issues down the line... as confirmed by your answer.Nevertheless, if this is the only way; I guess I'll just have to go for it. Do you know any pages describing this kind of claims based security model, within the context of WCF services? I'm still not clear on how I can make sure the session securely authenticates my client application.
Tim
After sleeping on this idea, I can't help thinking that the separate service will face the same problem as my initial one: this service, too, will need to securely authenticate the calling assembly to provide a secure session key. Is this assumption correct or am I missing something?
Tim
I went on holiday. Well my assumption is that you have no trust in the assembly via its data. With asynchronous encryption you can rotate keys making the weakness in the key. By rotating the key on the server side you can make it so that even though the client is not 100% secure the attacker does not have enough time to capitalise on it. So the only way you can have some confidence is if you employ some kind of trusted handshaking. It's not perfect by a long way as the weakness would be in the key used by the client and initial communication. But the lack of confidence is by your definition.
John Nicholas
If you were able to re-release the assembly regularly then you create an uphill battle for the devious mind as you can update all the security - changing the aslgorithm, change the way the key is generated from the source data etc - generally make his life interesting.
John Nicholas
A: 

You could get the callers Address:

 RemoteEndpointMessageProperty clientAddress = 
    OperationContext.Current.IncomingMessageProperties[RemoteEndpointMessageProperty.Name] 
as RemoteEndpointMessageProperty;
           string address = clientAddress.Address;
CkH
Interesting fact, but the client application will need to be run from a large number of machines. The client address will certainly be useful for mentioning in the audits.
Tim