In part 1 the focus was on the initial setup of an AD FS lab/test Environment on Windows Server 2012, using Powershell 3.0 scripts. In this post, part 2, we'll continue by introducing an application that will rely on claims being issued by this federation server. The federation server is going to play the role of an IdP STS within the Contoso domain, so that we can enable internal Web SSO. The final claims-based solution will be tied together in part 3 in this series.

For the purpose of illustration, we need to connect an RP with the STS. When I say “connect”, in this particular example, I mean to have the IWA authentication process externalized from the RP to the IdP STS.  Under the hood, this will be done by utilizing WIF, now a first-class citizen in .NET framework 4.5,  and which abstracts away the WS-Federation specification.

Just to make it a bit more challenging, the RP, which in this case will be a simple ASP.NET MVC 4 web application, will be hosted in IIS 8 on another VM within the same domain. The VM is also going to be a Windows 8 dev box.
I used Client Hyper-V on my physical machine with Windows 8 Pro to bring the virtualization part together. There are plenty of tutorials on this subject out there. These blog posts by Jeff Hicks helped me along the way. 
The goal is also to make use of Powershell 3.0 as much as possible.

We still have plenty of things to walk through until we have a working claims-based solution, so let's get started. But just to summarize what we have so for:
- A VM with a fresh install of Windows Server 2012, and with the machine, named ContosoServer, configured as a DC for the domain contoso.com.
- An AD FS farm currently with only one federation server, fs.contoso.com
- A service account, SVC-ADFS, which the AD FS windows service runs under.
- The AD FS configuration stored locally in two SQL Server 2012 databases.
- Three self-signed certificates; one for service communications, another for token-decryption and the third for token-signing.

Note: As already mentioned in the first part, this slimlined setup might be convenient for a small lab or PoC, but is not by any means to be concidered best practice for production scenarios.      
    
Prerequisities for the new VM machine which will host the RP application:
Windows 8 pro installed
Computer renamed to ContosoClient
Added as a computer in the domain contoso.com
IIS 8
Powershell 3.0 ISE
Visual Studio 2012
Identity and Access Tool

Step 1: Create DNS recourse records, host (A), for fs.contoso.com and rp.contoso.com: In order to translate the domain and host names to IP addresses (forward resolution), we need to create A records in the DNS. Run the following powershell cmdlets on the ContosoServer and verify that they where indeed created.

001
002
003
004
Add-DnsServerResourceRecordA -IPv4Address [The IP address to ContosoServer] -Name "fs" -ZoneName contoso.com 
Add-DnsServerResourceRecordA -IPv4Address [The IP address to ContosoClient] -Name "rp" -ZoneName contoso.com
#Verify
Get-DnsServerResourceRecord -ZoneName contoso.com | Where-Object {$_.RecordType -eq "A"}

 

Step 2: Create self-signed SSL certificate for rp.contoso.com. Run this on ContosoClient:

001
New-SelfSignedCertificate -DnsName rp.contoso.com -CertStoreLocation Cert:\LocalMachine\My

Make note of the thumbprint!


Step 3: Assign the SSL certificate to Default Web Site: Run this in Powershell 3.0 ISE on ContosoClient:

001
002
003
004
005
#Run this if https for the default web site has not been enabled already
New-WebBinding -Name "Default Web Site" -IP "*" -Port 443 -Protocol https 

cd iis:
get-item cert:\LocalMachine\MY\[the thumbprint from above] | new-item  0.0.0.0!443


Step 4: Download and modify the ASP.NET MVC 4 sample:

Let's imagine a web application that relies on the following three claims being issued by the STS. The STS will gather the claims from its attribute store Active Directory.
- The user's name, for greeting the user (corresponding LDAP attribute: [Display Name])
- A role, used for access control decisions (for simplicity this will mapped to the LDAP attribute [Department]
- An email address [-->LDAP: EmailAddresses] for personalization of the site and sending out newsletters by mail

4.1 To save some time and effort, let's download the ClaimsAwareMvcApplication from the WIF Code Sample Index. Be sure to read through the description about the sample.
4.2 Open up Visual Studio 2012 with administrator rights and open the solution from within the IDE.
4.3 Open up the Project properties window and change to the "Web" tab.    
4.4 Select "Use local IIS Web server" and unselect "Use IIS Express"    
4.5 Change the "Project Url" to https://localhost/mvcapplication and click Create Virtual Directory.    
4.6 Now select the "Use Custom Web Server" and enter https://rp.contoso.com/mvcapplication into the textbox. This way we don't get a warning in IE when we run the application from within the IDE as the SSL certificate's common name will be the same (rp.contoso.com).    
4.7 Save these settings and close the properties window.

Now let's pause here a bit and consider the fact that we are using self-signed SSL certificates in this lab. What we need to do in order to successfully establish the trust between the RP and the STS, is to install the SSL cert that we configured on ContosoServer into the Trusted Root Certification Authorities store on ContosoClient. See Export a server certificate and Import a server certificate for examples on how to do this.

Step 5: Establish the trust relationship (on the RP side)

5.1 Write-click on the project node in the Solution Explorer window and select "Identity and Access...". If you can't find it, install the Identity and Access Tool, then retry.    
5.2 Select "Use a business identity provider (e.g. ADFS2)"
5.3 Enter the path to the STS: https://fs.contoso.com/federationmetadata/2007-06/federationmetadata.xml      
5.4 Enter the realm for the RP: https://rp.contoso.com/mvcapplication/
5.5 Select the Configuration tab. Enter https://rp.contoso.com/mvcapplication/ into the realm and audience text boxes, and select the "Generate a controller". Press Ok to save and Close.
5.6 If you see a popup window that is displayed saying "Conflicting code...", select the "Use the existing authentication code" alternative and save by clicking Ok. Ignore the warning.     

Also I needed to do the following changes, some of them probably because we started out from an already configured claims-aware application:

5.9 Open Web.Config and verify that only https://rp.contoso.com/mvcapplication/ is present under the AudienceUris tag, also check that trustedIssuers only have one trusted issuer: http://fs.contoso.com/adfs/services/trust. Save and Close.      
5.10 Update the FederationMetadata.xml file. Select "Show all files" in the Solution Explorer window, open the FederationMetadata.xml file (under FederationMetadata/2007-06) and remove any EndpointReference that doesn't have the address https://rp.contoso.com/mvcapplication/.
5.11 Save and close the file. Rebuild solution.

Great, you made it this far! In part 3, we'll tie the whole claims-based solution together and make this lab scenario work by performing the necessary changes to the AD FS configuration and the RP.