Passing HttpContext.Current.User.Identity to WCF

Question

Looking for a little advice (or maybe even a direct answer).

I have an MVC3 website. I also have a set of WCF services running (for now everything is on the same box).

What I'm trying to do is authenticate the client (that part is working fine), then pass that authenticated user on to various WCF calls.

At the moment I've hooked up the Application_AuthenticateRequest() method in Global.Asax, which boils down to creating a new GenericIdentity & GenericPrincipal, then assigning that principal to HttpContext.Current.User:

...
GenericIdentity identity = new GenericIdentity(userName);
GenericPrincipal principal = new GenericPrincipal(identity, null);
HttpContext.Current.User = principal;
...

And that part seems to be working fine as well.

But when I hit my service, I have completely lost the user that I set. The values are empty or false.

The one main thing I've noticed is that on the Client side, the HttpContext.Current.User.Identity object is of type {System.Web.Security.FormsIdentity}, but in the service it's of type {System.Security.Principal.WindowsIdentity}.

Based on some of what I've read, it sounds like simply modifying my web.config so it contains aspNetCompatibilityEnabled="true" may be enough to make this work properly. But that's not what I'm seeing. So either I'm not understanding everything (a very good possibility) or I've got something screwed up (another good possibility).

So my question. Is this even possible, and if so - thoughts on what I'm missing? I notice a few others have posted something similar but have never quite received a definite answer (see here and here).

Any suggestions are very much appreciated.

Answer 1

I can't really answer directly to your question but hopefully will help you find the definite answer.

You have 2 service layers, and seems your requirement is to share Authentication identity among all layers.

So, in principle, you'd need (at least) the same Authentication mechanisms or algorithms or techniques to achieve this. But at this point you are not using the same (and you noticed when you saw a FormsIdentity and a WindowsIdentity there).

Facts:

• You will need the same Authentication mechanism.
• Whatever mechanism you use, needs to support that 3rd hop you want to make (meaning you can use a user's identity with a 3rd service without actually having the credentials to re-authenticate).

Problems:

• If you continue to use Forms authentication, then you'll need to reauthenticate with your WCF service (and of course provide Identity credentials, this may help). This I find hard to do unless you keep the password the User used to authenticate him/herself which is generally a bad idea.
• If you continue to use Windows Authentication for you site, then you'll have a problem if the user is logging in from the Intranet. Funny thing with Kerberos (Active Directory uses Kerberos) is that it let's the user access remote resources without reauthenticating... but this User Identity Token is only good for 1 hop. While your WCF and MVC services are on the same server, it'll work but if you eventually take your WCF service away... that's a 3rd box boundary... a 3rd hop, and the Kerberos ticket will not be good enough.

So... being unaware of your requirements, I would first suggest you:

• Forget about Authentication on your WCF layer
• Make your WCF service access private (work your Networking skills... firewalls et al). I'd start by having WCF run on a separate IIS Web Site that doesn't listen to port 80 (or 443) and make sure Firewall blocks access to your new WCF port from IPs outside your LAN (or even better, outside your white list (localhost for now)).
• Specify the user identity as a parameter of every WCF call. Or if you are feeling wild, explore ways of specifying a user identity thru SOAP headers (if your WCF uses SOAP). A custom header should do just fine as well. You will trust then your Web Site to correctly challenge and authenticate users before granting them access to your WCF services.

I've seen this running many times by now. Not having authentication on a private service is a good performance deal, but you need to take precautions cause in general, most of the IT attacks come from the internal LAN.