WCF Authorization with WindowsIdentity.GetCurrent()

Well, in a nutshell this doesn’t work. Our application has some role based security that depends on a AD role to run certain methods. One of the users was having no problems with the security model on the client side, but couldn’t access certain methods behind the WCF service. We wasted a few hours trying to figure out why our WCF service was not correctly recognizing this user’s role. With the help of some added logging we finally figured out that it wasn’t recognizing the user or the role.

Even though our web server is an internal server in the same domain as the client app, the Name property on our windows identity kept returning “NT AUTHORITY\NETWORK SERVICE”, regardless of the fact that we had set up the WCF binding to use Windows authentication. There are so many configuration options for WCF most of the debugging time was wasted trying to figure out what we had configured improperly, or what we needed to do to get the impersonation to work. I finally realized that configuration wasn’t the issue.

To correctly get the windows identity, or the user name and role, you need to either use the ServiceSecurityContext class or pull the name directly from the thread. This is somewhat obvious if you think about the whole security model and how WCF is doing the impersonation, but still it could throw you for a loop if you’re not used to using user security with WCF. It definately caused us a mile headache for a few hours. Solution below.

Web service bindings configuration:

<bindings>

  <wsHttpBinding>

    <binding name="secureBinding">

      <security mode="Message">

        <message clientCredentialType="Windows" />

      </security>

    </binding>

  </wsHttpBinding>

</bindings>

C# code:

WindowsIdentity sscIdentity= ServiceSecurityContext.Current.WindowsIdentity;

//OR

WindowsIdentity threadIdentity = (WindowsIdentity)Thread.CurrentPrincipal.Identity;

The breakpoint will not currently be hit. No symbols have been loaded ... CHECK YOUR PROCESSES!

Ok its been a while since i posted on this blog but i'm going to try and start doing better. It doesn't help that the web filter at my new job blocks the blogger.com site. By the time i get home my thoughts seem to dissipate as i take care of my 18 month old till bedtime. Anyway...

So today i got the infamous "The breakpoint will not currently be hit." message in my project. To be specific, the project I'm working on is an n-tier enterprise app containing some C# interop user controls that are gradually replacing the functionality in an older VB6 application. Basically when debugging i would run the VB6 application, attach the the VB6.exe process from visual studio 2008, and break in the user control as needed.

Well, two days ago i started getting the "No Symbols" error. I tried all the solutions that you will find when googling the problem: deleting bin directories, rebuilding the project, playing with configuration properties etc etc. Basically crossing my fingers and praying it would go away. But it didnt.

Research led me to discover the "Modules" window, which is available from the debug menu when debugging. This is where it gets interesting. The modules window, as you will find discussed in many blog posts and forums, shows if the debug symbols have been successfully loaded for your assemblies. It also allows you to load symbols manually and see what location items are being loaded from. The problem is, the dlls i was trying to break in weren't even in the modules window. How do i get them there??

What i came to realize (and this may be apparent to veteran programmers, but it wasn't to me) is that the Modules window shows all of the assemblies that are loaded into the processes that visual studio is attached to. I needed to see exactly what assemblies were loaded as i was running my project, so i downloaded the Process Explorer app from Technet (link below). This handy tool lets you select a running process and view all of the assemblies in that process. Sure enough i booted up VB6, ran the tool, and my project assemblies weren't there!

This is when the light came on in my dense skull. How could the VB6 run my interop controls if it hadn't loaded the assemblies?? It couldn't. Once i clicked on the form containing the controls, my project dlls showed up in the process explorer window. It wasn't loading the assemblies until they were needed. Once the process had the right dlls loaded, i could attach to VB6 from visual studio and set the breakpoints. (Important to note, if you have this similar issue you must detach and reattach the debugger for it grab the just loaded dlls.) Furthermore, once the assemblies are loaded the first time you can start and re-start the VB6 project and they will remail loaded.

You may notice a similar issue if you are running a web or WCF service locally while debugging. When i started working on the project i could set a break anywhere, but once i started having this issue, i had to manually go in and attach to the WCF service to set breaks in the bottom tiers. I've yet to figure out exactly what changed that started the whole "No Symbols" problem, and i probably won't pursue it at this point...i'm just happy to be able to finish my work.



http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx