How To Use Fiddler To Debug WS-Federation Issues
Fiddler is simply the best tool to debug federation issues. Optimal IdM has just released a White Paper on this which you can download on the left side of this page. In this blog we will cover how to use Fiddler to debug WS-Federation issues. The URI for a relying party or identity provider may be in the form of a URL (such as http://my.test.com) or a URN (urn:my.test.com). URIs (both URNs and URLs) are case sensitive when used for Federation. For URLs in the form of URIs, every “/” is part of the name as is the protocol. When used as a URI the URLs http://my.test.com, http://my.test.com/, https://my.test.com, and https://my.test.com/ would all be considered different URIs.
This often causes federation errors. After capturing the Fiddler trace look for HTTP Response codes with value 404. The response code is the second column from the left by default and a response code will typically be highlighted in red. If you see a 404 error, it is likely one of two reasons; 1) the URL is wrong and does not point to a valid location, or 2) the URL length exceeds that which the server can support. If you see a 404 error in the browser that does not show up in the Fiddler trace then that indicates the URL length exceeds the URL length limit of your browser. Browser URL length limits are vendor dependent.
The Basic Flow of WS-Federation
The basic flow of WS-Federation is:
- The user requests an access to a relying party
- The user is redirected to the Identity Provider (IdP) with a WS-Federation authentication request
- The user then authenticates at the IdP
- A WS-Federation authentication response is then posted to the relying party
If in the authentication request you get an error on the Identity Provider indicating that the relying party URI is not recognized, run a Fiddler trace reproducing the issue. Then look for a GET request to the IdP with the following URL parameters shown below. You can see the URL parameters by selecting the line in the request list and then going to the Inspectors -> Web Forms tab.
URL Parameters for WS-Fed Authentication
The URL parameters for the WS-Fed authentication request are:
- wa = wsignin1.0
- wtrealm = <relying party URI>
- wctx = <federation context>
- wct = <request time in UTC>
Make sure the value in the wtrealm URL parameter matches the value configured at the identity provider for the relying party. Also look at the raw URL which can be seen on the Inspectors -> Raw tab. Make sure the wtrealm URL parameter is properly URL encoded in the raw authentication request URL. The WS-Federation response is an HTTP POST request with the follow form data. You can see the form data by selecting the line in the request list and then going to the Inspectors -> Web Forms tab.
The Form Data for the WS-Fed Authentication Response Are:
- wa = wsignin1.0
- wresult = <WS-Fed response XML>
- wctx = <federation context> (should match the authentication request)
From the WS-Fed Response XML Validate the Following:
- Make sure the IdP URI matches the value configured on the relying party. This value can be found in the WS-Fed response XML Issuer element.
- Make sure the signing certificate matches the signing certificate configured on the relying party. The signing certificate can found in the WS-Fed response XML in the Certificate element under the Signature element.
- Make sure the assertion audience matches the relying party URI. The assertion audience can be found in the Audience element of the assertion.
- WS-Federation supports either SAML 1.1 or SAML2 assertions, make sure the type of the assertion matches what the relying party is expecting. For SAML 1.1 assertions the major and minor version attributes on the Assertion element will be set to 1. For SAML2 assertions the version attribute on the Assertion element will be set to 2.
How To Use Fiddler To Debug SAML 2.0 Federation Issues
In this part of this piece, we will cover how to use Fiddler to debug SAML 2.0 federation issues.
The Basic Flow of SAML 2.0
The basic flow of SAML 2.0 is:
- The user requests an access to a relying party
- The user is redirected to the Identity Provider (IdP) with a SAML 2.0 authentication request
- The user then authenticates at the IdP
- A SAML 2.0 authentication response is then posted to the relying party
While the basic flow is the same as WS-Federation, SAML 2.0 is much more complicated, because the authentication request is an XML document rather and URL parameters. Also, SAML 2.0 supports different methods of transporting the authentication request and response. These methods are called “Bindings”. The three most common bindings are POST, Redirect, and Artifact. The most common combination is for the authentication request to be passed using the Redirect Binding and the response is returned using the POST Binding. If you get an error on the authentication request to the IdP, capture a Fiddler trace reproducing the issue.
URL Parameters for SAML 2.0 Authentication
Then look for a GET request to the IdP with the following URL parameters shown below:
- SAMLRequest – encoded SAML 2.0 Authentication Request XML
- SigAlg – XML Digital Signature Algorithm (optional)
- Signature – XML Digital Signature (optional)
Unlike WS-Fedation, the SAML 2.0 authentication request is an XML document that is compressed and encoded. Fortunately, Fiddler can easily decode this for you and show you the XML document. Simply right click on the SAMLRequest value and select “Send to TextWizard.” That will bring up the Fiddler TextWizard window. If you don’t see XML make sure the Transform: drop down in the middle is set to “From DeflatedSAML”. 
Check the following:
- Make sure the request Issuer value matches the relying party URI configured in the IdP.
- Make sure the Destination attribute matches the IdP SSO endpoint.
The SAML 2.0 response is an HTTP POST request with the following form data. You can see the form data by selecting the line in the request list and then going to the Inspectors -> Web Forms tab.
The Form Data for the SAML 2.0 Authentication Response Are:
- SAMLResponse – encoded SAML 2.0 response
The SAML2Response is base64 encoded. Fiddler can easily decode this for you and show you the XML document. Simply right click on the SAMLResponse value and select “Send to TextWizard …” That will bring up the Fiddler TextWizard window. If you don’t see XML make sure the Transform: drop down in the middle is set to “From Base64”. 
From the SAML 2.0 Response XML Validate the Following:
- Make sure the IdP URI matches the value configured on the relying party. This value can be found in the SAML 2.0 response XML Issuer element.
- Make sure the signing certificate matches the signing certificate configured on the relying party. The signing certificate can found in the Response XML in the Certificate element under the Signature element.
- Make sure the assertion audience matches the relying party URI. The assertion audience can be found in the Audience element of the assertion.
How To Use Fiddler To Debug Oauth2 and OpenID Connect Federation Issues
Fiddler is simply the best tool to debug federation issues. Optimal IdM has just released a white paper on this which you can download from our website. Now we will cover how to use Fiddler to debug Oauth2 and OpenID Connect federation issues. OAuth2 and OpenID Connect define different grant types. Depending on the grant type the flow may consist of a mixture of web application and web service (REST) calls. The most commonly used grant is the Authorization Code grant. In this grant the user’s browser is used to make a web application authentication request after which an Authorization Code is returned to the web application.
The web application makes a REST call to the IdP to exchange the authorization code for an Access Token and JSON Web Token (Jwt). If in the Authorization Code grant request you get an error on the Identity Provider, run a Fiddler trace reproducing the issue. Then look for a GET request to the IdP with the following URL parameters shown below. You can see the URL parameters by selecting the line in the request list and then going to the Inspectors -> Web Forms tab.
The URL Parameters For the OAuth2\OpenID Connect Authentication Request Are:
- response_type = code
- client_id = <relying party URI>
- redirect_uri = <URL where the authorization code should be returned to>
- scope = <requested authorization>
- state = <federation context>
- nonce = <random value>
Check the following:
- Make sure the client_id value matches the relying party URI configured in the IdP.
- Make sure the redirect_uri value matches what is configured for the relying party in the IdP.
The REST call to exchange the Authorization Code for an Access Token and/or Jwt is performed by the relying party. To view this exchange you must run Fiddler on the server that is performing the REST call. After capturing the REST call with Fiddler, look for the REST call with the following URL parameters:
- code = Authorization Code
- client_id = <relying party URI>
- redirect_uri = <URL where the authorization code should be returned to>
- grant_tyoe = authorization_code
Check the following:
- Make sure the client_id value matches the relying party URI configured in the IdP.
- Make sure the redirect_uri value matches what is configured for the relying party in the IdP.
- Check that the Authorization Code had not be used before (they may only be used once).
- Check that the Authorization Code is not expired (they are typically short lived).
To learn more how Optimal IdM can help with your authorization and authentication issues, contact us today.
Can’t wait? Get Optimal IdM IAM Services Now
Contact Us Start Your Free Trial
