Windows Identity Foundation (WIF) makes it very easy to build basic federated scenarios. The WIF SDK offers Visual Studio templates for building simple Security Token Services (STS) and Relying Party (RP) services. The SDK also has an excellent help file with information about customizing the basic scenarios.

However, being as new as it is, there isn’t much guidance yet for building your own STSs and RPs from scratch. Also, the deployment and securirty best practices information is difficult to find or non-existent.

Lately, I’ve been researching WIF and discovered that I have a specific scenario that isn’t covered in the guidance. It seems to me that this would be a common scenario, but I was unable to find many resources online that offered help. In fact, I only found one blog post that was useful in solving this problem. You may want to check it out before going through all of the steps in this post.

My scenario included a Claims Aware Relying Party WCF service that that exposed its endpoints over net.tcp bindings. The STS could be accessed through wsHttp endpoints.

I built this scenario but had a really difficult time updating the XML binding configurations for the RP and Client. This post includes my step by step notes for building the scenario described here. I’ve included the source code for download too, but it will NOT work on your computer because you will not have the same certificates or URIs. The steps and source code are provided for demonstration purposes and should not be used in production applications.

WIFSample.zip (99.74 kb)

How To: Implement Federated Security over TCP

The steps below are pasted directly from my OneNote notebook so I have to apologize for the quality – that said, they should be clear enough to follow along. This process creates a functional federated solution, but it is far from being production-ready. I’m sure that there is a more direct way to accomplish this, but I’ve found that this process is a reliable way to build the appropriate bindings for TCP Federation.

**Before you start, you should have installed the WIF SDK (be sure that you’re on a supported OS – Vista or higher) and that you have a good ~30 minutes to finish these steps.

Note: You can click any of these images for a larger version

1. Open Visual Studio 2008 as an Administrator (this is important because VS will need to create and install certificates in certmgr.msc)
   1. Create a new Blank Solution
   2. 
   3. In Solution Explorer: Right-click the WIFSample Solution
   4. Create your Relying Party Service (WCF Service Library)
   5. 
   6. Open the App.config, copy the base address for your RP service
   7. 
   8. In Solution Explorer: Right-click SampleRP project > Add STS Reference
   9. 
   10. 
   11. 
   12. 
   13. Right-click SampleRP project > Properties
       1. Choose the debug tab
       2. Remove /client:"WcfTestClient.exe" from the Command line arguments field – it will annoy you.
2. Create HttpClient Console Application
   1. 
   2. Right-click HttpClient project > Add Service Reference
   3. 
   4. Right-click solution > Set startup projects
      1. Set all projects to start with the STS starting first, RP second and Client last
      2. 
   1. Call the RP Service from your Console Application
   2. 
   3. Add a reference to System.IdentityModel & Microsoft.IdentityModel to the RP service project
   4. Update Service1's implementation to output the claims identity
   5. 
3. Test that the Http Bindings are correct
   1. 
4. Add netTcp Binding to RP
   1. Open RP's App.config
   2. 
   3. Add endpoints for net.tcp bindings
   4. 
   5. Add the netTcp customBinding (you may want to copy this from the source code.)
   6. 
   7. And the binding for the STS
   8. 
   9. Lastly add the net.tcp endpoint to the audienceUris
   10. 
5. Test that haven't broken your RP - Run the solution (note that you’re still using http endpoints on the RP)
   1. 
6. Lastly, let's add a TcpClient
   1. Right-click solution > Add New Project > Console Application
   2. 
   3. Right-click TcpClient project > Add Service Reference
   4. 
   5. Open TcpClient's app.config and comment the http endpoint
   6. 
   7. Implement the TcpClient
   8. 
   9. 
7. Success
8. 

Recently, I was troubleshooting a difficult to find bug in an ASP.NET website. The bug was clearly environmental since the website worked for many other customers.  We could only reproduce it on this particular customer’s server, so my diagnostic options were limited.

The Symptom
This application contains an ASP.NET DataGrid control that will redirect to a new page when a row is clicked. After some SQL and ASP.NET tracing, I determined that the server-side RowCommand event wasn’t firing.

The Cause
To enable selecting a row by clicking it, the original developer added some custom JavaScript that would invoke the Select row command on the datagrid when the row is clicked. ASP.NET uses dollar signs to delimit control namespaces so that controls can be uniquely named within the control hierarchy. When the HTML is rendered, ASP.NET replaces the delimiters with an underscore and uses that name for the element’s ID attribute. When forcing the post back, the original developer simply replaced the underscores with dollar signs so that ctl01_content_datagrid became ctl01$content$datagrid.

This works normally, however on this customer’s server clt01 was being named _ctl01, this broke the original developers assumption about names since the first underscore was actually part of the control name and not a delimiter. When the post back made it to the server, ASP.NET didn’t fire the server-side event because the names were wrong.

The Fix
The correct way to fix this would be to use the ClientScriptManager (via Page.ClientScript) to emit the correct __doPostPostBack(…) statement, but this particular application relies heavily on ASP.NET’s “normal” naming convention.  The quick and simple solution was to add the <xhtmlConformance mode=”Transitional” /> element to the web.config. Since Transitional is the default mode for this setting, I assume (but didn’t verify) that the mode was set somewhere deeper in the configuration stack such as a root-level web.config or machine.config.

Details for this setting are here –> http://msdn.microsoft.com/en-us/library/ms228268.aspx