When developing applications that make use of Windows Identity Foundation - WIF (Microsoft's technology to deal with claims-based security in your services) you can encounter exceptions that are not very precise/clear.
In this blog post I will show the difference between WCF tracing and WIF tracing based upon a sample application that is made to fail. The sample application consists of a client calling a service by first obtaining a security token from AD FS 2.0 and then asking the service to enumerate the claims present in the security token. The client will show the claims enumeration as received from the service.
When I run my application (both the host and the client) this is the result:
The window in the background is my ServiceHost, the window in the front is the client. When the client calls the service over transport security the presented claims are enumerated as expected, when doing the same over message security the communication fails.
We will try to find the root cause of the problem by looking into WCF and WIF tracing.
The first thing the seasoned .NET developer will think of is to go in the .config file of your service and enable WCF Tracing:
Let's have a look what helpful information we can find in the WCF tracelog and WCF message log after running the sample.
The trace log shows this exception:
The message log shows this SOAP fault:
Although we have some useful information, "Message security verification failed" and "Security token could not be authenticated" can have a lot of reasons. We are interested in more detailed information about what goes wrong in the communication between clients, AD FS 2.0 and the service.
To find more detailed information we can enable WIF Tracing. WIF tracing cannot be enabled by clicking 'enable' in the Service Configuration Editor tool like we did for WCF Trace. However the idea is similar.
We only need to add two things to our config file (can also be done via the Service Configuration Editor tool):
- A diagnostics source: Microsoft.IdentityModel
- A listener (shared or not)
The Xml representation looks like this:
<system.diagnostics>
<sources>
...
<source name="Microsoft.IdentityModel" switchValue="Verbose">
<listeners>
<add name="WIFListener" />
</listeners>
</source>
...
</sources>
<sharedListeners>
...
<add initializeData="c:\...\wif.svclog" type ="System.Diagnostics.XmlWriterTraceListener, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" name="WIFListener" />
</sharedListeners>
</system.diagnostics>
The Service Configuration Editor tool view looks like this:
That't all you need to do to enable WIF tracing.
Let's re-run the sample app with WIF tracing enabled and hit against the same exception...
After opening the WIF trace-file, I can see this information:
As you can see, WIF Tracing gives us a much clearer exception message:
"ID1038: The AudienceRestrictionCondition was not valid because the specified Audience is not present in AudienceUris.
Audience: 'http://localhost:8733/ClaimsEnumeratorService/'"
After checking the service config file, I can see that WIF is exaclty right :)
The audienceUri for my endpoint that uses message security is commented out.
Thanks to WIF tracing I can troubleshoot problems like this in a reasonable time, with only WCF tracing the exception details are just not enough to point you to the right direction.
Both WCF and WIF tracing are priceless for .NET developers...
Peter Borremans
232d7ed7-ca2c-419e-a6ed-9eb5961132ab|5|4.8