Let’s first look at the theory behind this “binding.”
The SAML and OAuth2 protocol flow ^
For the SAML and OAuth2 protocols, a federation trust needs to be built between a claims-aware application and the Identity Provider. This allows the application to redirect authentication to its resources (1 in the image below) to the correct authentication provider (2). Colleagues would then authenticate to the SAML-based Security Token Service (STS) (3), which is our Active Directory Federation Services server (ADFS). The STS would then authenticate to the on-premises Active Directory environment (DC1) (4 and 5).
When authentication succeeds, the STS would transform the Kerberos-based token to a SAML- or OAuth2-based ticket for the specific web application and pass it on to the device (6). This ticket is then presented to the web application (7), which verifies that the ticket is, indeed, issued by the STS and is valid. The colleague is then granted appropriate access.
This process is depicted below:
SAML and OAuth2 flow
Although configuring a website as a claims-enabled website seems like a pretty overwhelming ordeal, it’s the last clicks you’ll perform throughout this step-by-step guide. In fact, what you’ll see is that it is pretty straightforward and that our demo setup actually makes it harder than it is in any real-life scenario you might encounter with AD FS.
So, let’s get to it!
Step 15: Configure IIS and trust from the webserver ^
In order for the claims app to digest claims, we need to set up a trust between the AD FS server and the webserver. Log on as an administrator on the WebServer server and perform these steps:
- Navigate to C:\Program Files (x86)\Windows Identity Foundation SDK\v3.5\.
- Double-click fedutil.exe to run the Federation Utility Wizard.
- For the Application configuration location, browse to the web.config file in C:\Intetpub\ClaimApp. For the Application URI, specify https://www.demo.4sysops.com/claimapp. Click Next > when done.
- On the Security Token Service window, select Use an existing STS. Use https://adfs.demo.4sysops.com/federationmetadata/2007-06/federationmetadata.xmlas the STS WS-Federation metadata document location.
- Select Test location… When you get a load of gibberish in Internet Explorer, you’ll know it works. 😉 Close Internet Explorer.
- Click Next > four times.
- On the Summaryscreen, select the option to Schedule a task to perform daily WS-Federation metadata updates. Click Finish.
- Click OK when the Federation Utility Wizard is done configuring.
Now, all we need is some work in the Internet Information Services (IIS) Manager. We’re going to create a binding and configure the .NET app pool:
- From Server Manager, in the grey top bar, select Tools and then click Internet Information Services (IIS) Manager.
- In the left pane, click the server’s name to expand it.
- Click Cancel in the pop-up window that asks if you want to get started with Microsoft Web Platform to stay connected with latest Web Platform Components.
- In the left pane, also expand Sites, and then select the Default Web Site.
- In the right Actions pane, follow the Bindings… hyperlink.
- Add… a binding.
- In the Add Site Binding window, select https as the Type.
- Select the webserver.demo.4sysops.com SSL certificate.
- Click OK.
- Click Close to close the Site Bindings window.
- In the left pane, select Application Pools.
- On the main window, select the DefaultAppPool.
- In the right pane, click the Basic Settings… hyperlink.
- Select .NET CLR Version v2.0…. for the .NET CLR version:. Click OK.
- In the right pane, click the Advanced Settings… hyperlink.
- On the Advanced Settings window, scroll down a tad.
- Change the value for Load User Profile from False to True.
- Click OK to close the Advanced Settings window.
- In the left pane, right-click Default Web Site and select Add Application… from the context menu.
- Specify claimapp as the Alias: and C:\inetpub\claimapp as the Physical path:.
- Click OK when done.
- Close the IIS Manager.
- Log off.
Step 16: Configure IIS and trust from the AD FS server ^
Now, let’s complete the federation magic from the side of the AD FS server:
- Log on to server ADFS.
- In Server Manager, from the grey top bar, select Tools and then click AD FS Management.
- In the left pane of AD FS, select Trust relationships.
- In the Actions pane on the right, follow the Add Relying Party Trust… hyperlink.
- Click Start on the Welcome to the Add Replying Party Trust Wizard window.
- On the Select DataSource window, accept the default selection Import data about the relying party published online or on a local network. Specify https://www.demo.4sysops.com/claimapp/federationmetadata/2007-06/federationmetadata.xml as the Federation metadata address (host name or URL):. Click Next >.
- Specify ClaimApp as the Display name: and click Next > four times.
- Click Close to finish the wizard.
Since we want our ClaimApp to show all claims that are supported by our AD FS server, we’ll want to create a special kind of claims transformation rule.
- Click Add Rule….Note:
If you’re not prompted to create a rule, have inadvertently closed the pop-up window, or made a typo below, you can open it again by selecting the ClaimApp Relying Party Trust. To do so, select Relying Party Trusts in the left pane and then follow the Edit Claim Rules… hyperlink from the Actions pane. Then, on the Issuance Transform Rules tab on the Edit Claims Rules for ClaimApp window, click the Add Rule… button or Edit Rule… button.
- Select Send Claims using a custom role… at the bottom of the drop-down list.
- Give the claims transformation rule a meaningful name, like All Claims. Then, define a Custom rule:
- Click Finish.
- Close AD FS Management.
- Log off.
After looking at the SAML and OAuth2 federation protocol flows, we’ve created the trusts between our claims-aware web application and the Active Directory Federation Services server (ADFS).
In my next post, I will show you how to configure the Web Application Proxy for our BYOD lab.