More Information section of this article for possible links.




Getting started

1. Download and install Fiddler Web Debugger on the client machine
2. Launch Fiddler from the Programs menu
3. Fiddler will automatically start capturing. We're not quite ready for that yet, so click File -> Capture Traffic to stop the capture.

Configure Fiddler to decrypt HTTPS traffic

1. Within Fiddler, click Tools -> Fiddler Options
2. Select the HTTPS tab
3. Check the checkbox to Decrypt HTTPS traffic
4. You will receive a few pop-ups that are required in order to install the Fiddler root certificate, which allows Fiddler to sit as a man-in-the-middle to your HTTPS session. Click Yes to these prompts.
5. Click OK to close Fiddler Options

Understanding the view of the Fiddler tool

• The left side of the vertical divider will show a sequential flow of the HTTP conversation.
• The right side of the vertical divider is where the data is viewed.
• I recommend splitting the left and right panes into a 50%/50% view so that you can work through both panes.
• The right pane is split by a horizontal divider, which separates the request from the response. Unlike a network trace where you typically get a frame for a request and another frame for a reponse, Fiddler provides one frame that contains both the request and the reponse.
• We will be interested in the Inspectors tab data, so go ahead and select Inspectors at the top of the right pane.
• You'll notice that we have sub-tabs under the Inspectors main tab, such as Headers, TextView, WebView, Auth, Raw, etc. We will be toggling through these sub-tabs as we work through our trace.

Configure AD FS 2.0 to allow Fiddler to act as a man-in-the-middle to the HTTPS session

If AD FS 2.0 is the claims provider (identity provider, meaning, you are authenticating to the AD FS 2.0 server) and is configured to utilize Windows authentication, we need to disable Extended Protection for Authentication on the AD FS 2.0 server in order for Fiddler to be able to act as a man-in-the-middle to the HTTPS session. Follow the steps in the following article to disable Extended Protection for Authentication: AD FS 2.0: Continuously Prompted for Credentials While Using Fiddler Web Debugger


Capture the WS-Federation sign-in data

We will be capturing the trace data from the client machine

1. Make sure that ALL web browser windows are completely closed
2. In Fiddler, click File -> Capture Traffic to start the capture
3. Click the Launch IE button in the ribbon bar near the top (this will take you to the about:blank page, which helps to keep the trace clean)
4. 
5. Browse to the relying party (RP) application and authenticate to the Federation Service
6. When you have finished signing in or reproducing your failure, in Fiddler, click File -> Capture Traffic to stop the trace

Analyze the captured WS-Federation sign-in data

• We browsed, first, to your RP application, so let's find that frame in the trace. In the example, my HTTP GET to the RP was in frame 2

• The URL is http://contosoweb1.contoso.com:8085/
• The action is a HTTP GET
• The response is a HTTP 302 (Redirect), and the Response -> Headers sub-tab Transport data shows us where we are being redirected to. In this case, we are redirected to the AD FS server whose URL is https://sso.contoso.com/adfs/ls/
• Notice we have query string parameters on the URL to the AD FS server: wa, wtrealm, etc. wa=wsignin1.0 shows us that our RP application has built a WS-Federation sign-in request for uas in frame 2

• The URL is http://contosoweb1.contoso.com:8085/
• The action is a HTTP GET
• The response is a HTTP 302 (Redirect), and the Response -> Headers sub-tab Transport data shows us where we are being redirected to. In this case, we are redirected to the AD FS server whose URL is https://sso.contoso.com/adfs/ls/
• Notice we have query string parameters on the URL to the AD FS sers, and sent this to the AD FS server's /adfs/ls/ endpoint. This is known as using the Redirect binding.
• The next frame of interest is where we first contact the AD FS server in frame 5

• This is a HTTP GET to the AD FS server's /adfs/ls/ endpoint accompanied by a WS-Federation sign-in request (wa=wsignin1.0)
• Notice that the client is presenting a browser cookie named MSISIPSelectionPersistent. This cookie is the persistent cookie which is written to the file system on the client that shows who should be the identity provider (IDP) for this client. If the client does not already have this cookie set, and there are multiple IDPs to choose from, AD FS will prompt the user to select an IDP through a process called Home Realm Discovery (HRD).
• The MSISIPSelectionPersistent cookie data is base64 encoded, so you can use your favorite base64 decoder to see the value of the identity provider. Fiddler has a base64 decoder built into its Decoders menu.
• This is what my MSISIPSelectionPersistent cookie data looks like: http://sso.contoso.com/adfs/services/trust (this is my Federation Service Identifier. This is a URI, not a URL!)
• This HTTP GET results in another HTTP 302 to the /adfs/ls/auth/integrated/ endpoint of AD FS 2.0. This shows me that the authentication type set for this Federation Server is Windows authentication. You can figure out which authentication type you are using by reading through this article: AD FS 2.0: How to Change the Local Authentication Type

 

• Frame 6 shows a HTTP GET to the /adfs/ls/auth/integrated/ endpoint of AD FS 2.0

• Selecting the Auth sub-tabs, you can see that the client is performing a GET to this endpoint, and the server is responding with a credential challenge in a HTTP 401. You can see on the Response -> Auth sub-tab that the server is offering an authentication header Negotiate and NTLM.
• Frame 7 shows that we are, again, performing a GET to the /adfs/ls/auth/integrated/ endpoint

• This results in a HTTP 200 (OK) which means that AD FS (IIS, really) has authenticated the user based on the credentials provided
• The Response -> Headers sub-tab is especially interesting here because we see AD FS 2.0 is setting 5 cookies back to the client.
• These cookies are used to fascilitate the single-sign-on process (SSO), and they are session cookies which means they are lost once the browser session has ended or the cookies are cleared in some other way such as invoking WS-Federation sign-out.
• MSISAuth and MSISAuth1 are the encrypted cookies used to validate the SAML assertion produced for the client. These are what we call the "authentication cookies", and you will see these cookies ONLY when AD FS 2.0 is the IDP. Without these, the client will not experience SSO when AD FS 2.0 is the IDP.
• MSISAuthenticated contains a base64-encoded timestamp value for when the client was authenticated. You will see this cookie set whether AD FS 2.0 is the IDP or not.
• MSISSignout is used to keep track of the IDP and all RPs visited for the SSO session. This cookie is utilized when a WS-Federation sign-out is invoked. You can see the contents of this cookie using a base64 decoder.
• MSISLoopDetectionCookie is used by the AD FS 2.0 infinite loop detection mechanism to stop clients who have ended up in an infinite redirection loop to the Federation Server. For example, if an RP is having an issue where it cannot consume the SAML assertion from AD FS, the RP may continuously redirect the client to the AD FS 2.0 server. When the redirect loop hits a certain threshold, AD FS 2.0 uses this cookie to detect that threshold being met, and will throw an exception which lands the user on the AD FS 2.0 error page rather than leaving them in the loop. The cookie data is a timestamp that is base64 encoded.

 

• Frame 11 is where we are POSTing the SAML assertion back to the RP

• AD FS 2.0 scripts a HTTP POST to cause the client to POST the SAML assertion to the RP. AD FS 2.0 will POST to the WS-Federation endpoint defined in the RP Trust. In this case, AD FS 2.0 is POSTing to https://contosoweb1.contoso.com:8085/
• The Request -> TextView will show you the WS-Federation response which is a RequestSecurityTokenResponse (RSTR). The SAML assertion is in this TextView area as well, and may be encrypted if token encryption is configured for the RP Trust. For troubleshooting, you may wish to disable token encryption for the RP so you can see the SAML assertion in transit.
  • PowerShell to disable token encryption for the RP:
    • Add-Pssnapin Microsoft.Adfs.Powershell
    • Set-AdfsRelyingPartyTrust -TargetName "yourRPname" -EncryptClaims $false
• The TextView data is URL-encoded, so passing this through a URL-decoder will make it easier to look through. Fiddler has a built-in URL-decoder under Encoder.
• The Response -> Headers sub-tab shows that the RP is setting two cookies to the client: FedAuth and FedAuth1. These are authentication cookies used to fascilitate SSO for a Windows Identity Foundation (WIF) RP. Your trace will likely look different at this point if your RP is not a WIF RP. We should expect to see some browser cookie(s) set by the RP so that SSO is achieved.
• The Response from the RP is a 302 redirect to the default.aspx page of the RP.
• Finally, in frame 12, the client performs a HTTP GET to the default.aspx page of the RP

• The Request -> Headers sub-tab shows the the client is presenting the FedAuth and FedAuth1 cookies to the RP so that the client can experience SSO to the default.aspx page.
• The response to the GET is a HTTP 200 (OK) which shows us that the FedAuth cookies were successful in allowing the client to access default.aspx
• The Response -> WebView tab can be used to view what the client saw in the browser upon the HTTP 200 (OK) to default.aspx.

More Information

This section is a work in progress.