Analyse AD FS SAML Claims with Fiddler

In this post we want analyze the SAML assertion (Claims) from our AD FS server for several web applications.

Therefore we first need to configure Fiddler in order to capture successful the SAML assertion issued from the federation server.

Configure Fiddler

Configure the Fiddler SSL certificate
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/troubleshooting/ad-fs-tshoot-fiddler#configure-the-fiddler-ssl-certificate

Use the following procedure to setup Fiddler to decrypt SSL traffic.

1. Open Fiddler
2. At the top, under Tools, select Fiddler Options.
3. Click on the HTTPS tab.
4. Place a check in Decrypt HTTPS traffic and select from browsers only from the drop-down.
5. Place a check in Ignore server certificate errors.
6. Click OK.

Configure the AD FS server

Next in order for Fiddler to be able to act as a man-in-the-middle to the HTTPS session, we need to disable Extended Protection for Authentication on the AD FS server as follows.

Set-ADFSProperties -ExtendedProtectionTokenCheck:None

# Change to default back
Set-ADFSProperties –ExtendedProtectionTokenCheck Allow

# Change to Require
Set-ADFSProperties –ExtendedProtectionTokenCheck Require

For troubleshooting, you may wish to disable token encryption for the RP so you can see the SAML assertion in transit.
Set-AdfsRelyingPartyTrust -TargetName asp-auth -EncryptClaims $false

Source: https://technet2.github.io/Wiki/articles/3286.ad-fs-2-0-how-to-use-fiddler-web-debugger-to-analyze-a-ws-federation-passive-sign-in.html

Disable Extended Protection in ADFS 2.0 (for Office 365) to allow IE, Google Chrome and Firefox to Authenticate Using NTLM
https://www.agileit.com/news/disable-extended-protection-in-adfs-2-0-for-office-365-to-allow-ie-google-chrome-and-firefox-to-authenticate-using-ntlm/

For testing purpose you can also configure AD FS to send all claims to your web application with the template Send Claims using a Custom rule.

x:[]
=> issue(claim = x);

Now I will analyze the ASP.NET C# Web Application we created in the following post.

For this web application we created a relying party trusts and enabled the WS-Federation Passive protocol.

A deep dive to the WS-Federation protocol you will find in this great post from David Gregory below. I will also use some information from his post to explain details of the trace below.

ADFS Deep-Dive: Comparing WS-Fed, SAML, and OAuth
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/adfs-deep-dive-comparing-ws-fed-saml-and-oauth/ba-p/257584

Capturing the trace data from a client machine

In the actual version Capture Traffic is enabled by default at startup from fiddler. So in order to only capture the traffic from my web application with the AD FS claims, I will first disable Capture Traffic and delete all still captured traffic from fiddler.

Now to capture only the traffic from my web application, I will click on the Browse button and select my favorite browser. This will open the about:blank page, which is useful not to capture to much unneeded traffic in fiddler.

Next I will browse to my web application (relying party) and authenticate to the AD FS federation service. When you have signed-in successfully, disable Capture Traffic as show above.

Here we will see the frame id #44 the HTTP GET for our web application and the response header with 302 redirecting to the federation server.

As I am not authenticated, the web application redirects me to the AD FS server for authentication (figure below). It will also provides me in the response headers the URL from the federation server including the required parameters to sign-in using the WS-Fed protocol.

https://fs.braintesting.de/adfs/ls/?wtrealm=https://asp-auth.braintesting.net/&wctx=WsFedOwinState=p08VoECBl9nXUowC_Ok4eaBfhsKzM1zII_GCsKYxzE3ngQQ4AbW_6CezmD3FP6NzeltzjoKQ&wa=wsignin1.0

Wa=signin1.0: This tells the ADFS server to invoke a login for the user.
Wtrealm: This tells ADFS what application I was trying to get to. This has to match the identifier of one of the relying party trusts listed in ADFS.
Wctx: This is some session data that the application wants sent back to it after the user authenticates.
wct: This is the exact time I tried to gain access to the application.

If you see these parameters in the URL, you will be using the WS-Fed sign-in protocol.

The above sign-in process to the federation server, you can see in frame id #49, where the credentials (username and password) will be send through a HTTP POST to the federation server.

Authentication protocol: Forms-based.

HTTP POST with the credentials from the login form to the federation server

The next frame id #50 will show the response from the federation server after sending the authentication data with the HTTP POST in frame id #49.

The response will include a SAML 1.1 token issued from the federation server after the authentication, which we have to send through a HTTP POST back to the web application for authentication and authorization against.

When the WS-Fed sign-in protocol is used, AD FS will always issue a SAML 1.1 token back to your browser:

Don’t be confused that WS-Federation issues SAML 1.1 token. The WS-Federation and SAML 2.0 protocol uses both the SAML format for their tokens.

SAML tokens are XML-based assertions which passes information about a principal (usually an end user) between a SAML authority, named an Identity Provider, and a SAML consumer, named a Service Provider.

In frame id #51 the client is posting the SAML assertion with a HTTP POST to the web application.

If you mark the URL encoded SAML assertion in the TextView tab, you can send it with a right click to the TextWizard in order to decode it.

The TextView data is URL encoded, so select URLDecode to see the SAML assertion.

HTML URL Encoding Reference
https://www.w3schools.com/tags/ref_urlencode.ASP

URL encoding converts characters into a format that can be transmitted over the Internet.
URLs can only be sent over the Internet using the ASCII character-set.
Since URLs often contain characters outside the ASCII set, the URL has to be converted into a valid ASCII format.
URL encoding replaces unsafe ASCII characters with a “%” followed by two hexadecimal digits.
URLs cannot contain spaces. URL encoding normally replaces a space with a plus (+) sign or with %20.

Here you can see the two configured incoming LDAP Attributes from the Active Directory with the Display Name and the User Principal Name and outgoing as Claims from the type Name and UPN.

Fiddler comes with a set of very useful tools that will help developers to quickly do some encoding and decoding functions. It is buried under the Text Wizard. You can launch it by pressing CTRL + E. You will have options such as HTMLEncode, HTMLDecode, URLEncode and URLDecode.

Just type the text in the upper text box; it will be converted according to the option selected in real time.

Source: https://www.devx.com/DevX/tip-encode-and-decode-html-with-fiddler.html

Claims Issuance Policy for the web application on the resource partner AD FS server.

Finally the web application has authenticated and authorized the user.

All these HTTP GET and POST, browser redirects and cookies shows, that here WS-Federation with the passive requester profile is used from AD FS.

WS-Federation Passive Requestor Profile
https://en.wikipedia.org/wiki/WS-Federation_Passive_Requestor_Profile
Passive Clients (Browser )

WS-Federation Active Requestor Profile
https://en.wikipedia.org/wiki/WS-Federation_Active_Requestor_Profile
Smart Active Clients (SOAP)

Active, Passive and Passive-Aggressive
https://www.cloudidentity.com/blog/2008/06/05/active-passive-and-passive-aggressive/

A great post about passive authentification you will find below.

Passive Federation Basics
https://docs.microsoft.com/en-us/archive/msdn-magazine/2010/august/federated-identity-passive-authentication-for-asp-net-with-wif#passive-federation-basics

Passive federation scenarios are based on the WS-Federation specification. This describes how to request security tokens and how to publish and acquire federation metadata documents, which makes establishing trust relationships easy. WS-Federation also describes single sign-on and sign-out procedures and other federation implementation concepts.

While WS-Federation discusses many details about federation, there are sections devoted to browser-based federation that rely on HTTP GET and POST, browser redirects and cookies to accomplish the goal.

Some aspects of passive federation messaging are based closely on the WS-Trust specification. For example, passive federation employs a browser-compatible form of Request Security Token (RST) and RST Response (RSTR) when a security token is requested of an STS. In the passive federation scenario, I’ll call the RST a sign-in request message and the RSTR a sign-in response message. The WS-Trust specification focuses on SOAP-based (active) federation, such as between Windows clients and WCF services.

Simple Passive Federation Scenario

Users authenticate to their domain and are granted access to a Web application according to their roles. The participants in this authentication scheme include the user (the subject), a Web browser (the requester), an ASP.NET application (the relying party or RP), an IdP responsible for authenticating the users within its domain and an STS belonging to the user’s domain (IP-STS). A sequence of browser redirects ensures that the user is authenticated at her domain prior to accessing the RP.

Source: https://docs.microsoft.com/en-us/archive/msdn-magazine/2010/august/federated-identity-passive-authentication-for-asp-net-with-wif#passive-federation-basics

Capturing the trace data from a client machine from a Partner Trust (Claims Provider Trusts)

Now I want to capture the same as previously but this time in an AD FS Partner Trust scenario. In the following post I set up an AD FS Federation Trust between two organizations (exactly between my lab and production environment).

I also have published the previously used ASP.NET web application in my production environment. In the following trace I will browse to this application from a computer and account which is homed in the lab environment with the Account Partner AD FS server.

The Claim Issuance Policy from the relying party trusts configuration on the account partner AD FS server for the AD FS resource partner (production env.), looks like this.

The following LDAP Attributes and corresponding Claim Types are configured as follows.
Display Name -> Name
User-Principal-Name -> UPN

The Claim Issuance Policy on the resource partner for the Claims Provider Trust with my lab environment braintesting.de, in contrast looks like this.

There are two Pass Through or Filter an Incoming Claim rules, one with the Name claim type and one with UPN claim type.

So I will browse from a client in the lab environment braintesting.de to the web application in the production environment as follows.

First I will get a 301 Moved Permanently which tells me to use HTTPS as configured in the URL Rewrite Module with an action type from redirect as shown in the following post.

As the web application is configured for WS-Federation, I will get redirected to the AD FS server from the production environment.

As on the AD FS server from the production environment (resource partner), the Claims Provider Trusts with the lab environment braintesting.de is configured, I will get asked what account provider I want to use.

As I am browse from the lab environment braintesting.de, I need to select the fs.braintesting.de account provider, my AD FS server in the lab environment (account partner).

Active Directory is the production environments AD FS server itself.

In this case I will get another time redirected, but this time to the AD FS server from my lab environment braintesting.de, where I have to authenticate myself.

Here I will enter the credentials (UPN + password) from John Doe which is an user in the lab environment (account partner).

After he successfully authenticated against the federation server from the lab environment, the federation server from the lab environment will issue the SAML assertion in the response header to the client which also includes an HTTP POST back to the production federation server.

So therefore the client will send this HTTP POST with the SAML assertion back to the production federation server.

The production federation server itself validates the SAML assertion from the lab federation server (account partner) and will issue on his part a SAML assertion for the web application to the client which he should send with a further HTTP POST to the application in order to authenticate and authorize against.

Finally after the HTTP POST with the SAML assertion from the client to the web application, it will get redirected and authenticated to the web application.

In the following post at the end you will also see a few details about analyzing the OpenID Connect protocol (build on top of Oauth, supports authentication as Oauth is an authorization protocol) from AD FS.

More about the different protocols AD FS supports, you will find in my following post.

Links

AD FS Troubleshooting – Fiddler – WS-Federation
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/troubleshooting/ad-fs-tshoot-fiddler-ws-fed

How to Use Fiddler Web Debugger to Analyze a WS-Federation Passive Sign-In
https://social.technet.microsoft.com/wiki/contents/articles/3286.ad-fs-2-0-how-to-use-fiddler-web-debugger-to-analyze-a-ws-federation-passive-sign-in.aspx

How To Use Fiddler To Debug WS-Federation Issues
https://optimalidm.com/resources/blog/troubleshooting-federation-with-fiddler/

ADFS Deep-Dive: Comparing WS-Fed, SAML, and OAuth
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/adfs-deep-dive-comparing-ws-fed-saml-and-oauth/ba-p/257584

Configure the Fiddler SSL certificate
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/troubleshooting/ad-fs-tshoot-fiddler#configure-the-fiddler-ssl-certificate

Security Assertion Markup Language (SAML)
https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language