How do I securely authenticate the calling assembly of a WCF service method?

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. T开发者_Python百科he 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.

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

You could get the callers Address:

 RemoteEndpointMessageProperty clientAddress = 
    OperationContext.Current.IncomingMessageProperties[RemoteEndpointMessageProperty.Name] 
as RemoteEndpointMessageProperty;
           string address = clientAddress.Address;