views:

232

answers:

1

I have 2 applications; one is a ASP.NET 3.5 Ajax Application (Client) and the other is a WCF Web Application (BackEnd).

The applications are deployed in a separate Windows Server 2008 over IIS 7. The backend application has the net.tcp and http bindings enabled; some services are exposed under the netTcpBinding and other services are exposed under basicHttpBinding; the bindings not have configured any security.

The Client application use FormsAuthentication for authenticate users. All of the services under netTcpBinding are consumed in the client application. In the backend I need to know which user calls the service to make some audit task. Is this possible?

+2  A: 

If you don't actually want to implement security over the backend services and just want to be able to audit the user identity (meaning you actually TRUST who is sending you that identity information), you could consider passing the identity information through a custom header with each request.

To do this you can create a custom IClientMessageInspector which adds the header by pulling the information from the current ASP.NET context via something like HttpContext.Current.User.Name inside of its BeforeSendRequest implementation. To attach the IClientMessageInspector to your client proxies you can just create an IEndpointBehavior which you then add to the endpoint via config (check the documentation for IClientMessageInspector for sample code).

Here's what your BeginSendRequest implementation might look like:

public void BeginSendRequest(ref System.ServiceModel.Channels.Message request, IClientChannel channel)
{
   string currentContextUserName = HttpContext.Current.User.Identity.Name;

   MessageHeader userNameHeader = MessageHeader.CreateHeader("Username", "urn:my-custom-namespace", currentContextUserName);

   request.Headers.Add(userNameHeader);
}

On the server side you could consider generic auditing by implementing an IDispatchMessageInspector and doing the auditing in there. Either that or you could just retrieve the header "manually" within methods that might want to use it via the OperationContext::IncomingMessageHeaders property.

Drew Marsh