Continuing my prior post on working with the WIF samples, the WIF samples that come with the SDK, or the labs in the WIF training kit are great learning experiences. To better understand better what is going on under-the-covers, or to troubleshoot problems, using HTTP Watch is a great tool to see the passive WS-Federation traffic from the relying party side. HTTP Watch can capture requests/responses when both the STS and the Replying Party (RP) are hosted in the same localhost web site, something Fiddler cannot do.
HTTP Watch installs into Internet Explorer or Firefox, so it sees the traffic after SSL decryption. HTTP Watch is available as either a free download or a professional version. You will need the professional version to do anything useful. If you are lucky, your company may have a corporate license. (HINT: Microsoft has a corporate license. Employees can install from //productsweb.)
After opening the browser, launch HTTP Watch from the Tools menu:
HTTP Watch opens in the bottom of the browser window; however, you may find it easier to detach it into a separate window by clicking the detach icon in the top-right corner:
Next, click on the Record button on the top-left of the tool bar, and begin exercising the sample application. Here is a recording of logging into a protected page using WS-Federation (a passive STS scenario) with Windows Authentication. It is easy to see the sequence of steps (it took me 2 tries since I miss typed my password the first time, hence there are four 401 results). There are several tabs in the bottom pane allowing you analyze different aspects of the requests and responses. In this picture, the POST from the STS back to the relying party (RP) is selected. The bottom pane shows the POST data, which is the Request Security Response Token (RSRT) being sent from the STS back to the RP.
An interesting exercise is to cut the POST data from HTTP Watch and past it into an XML window in Visual Studio to see what a SAML token contains.
Which leads to this tip. If you want to retry an authentication scenario, there is no need to close the browser or recycle IIS. HTTP Watch will clear the session cookies (FedAuth and FedAuth1) by selecting Tools > Clear Session Cookies. This effectively makes the application forget the existing authentication session, triggering a new authentication redirection to the STS on the next page request.