Share via

Exploring AD FS on Windows Server 2012, Part 3

  • Article

 

In part two, we downloaded a sample ASP.NET MVC 4 application to be used as an internal RP and established a trust relationship with the federation server which in this lab plays the role of an IdP STS. In this post we will make the final changes to the AD FS configuration and the RP so that it will retrieve the claims that it relies on, when authenticated users request the application.

Let's continue from where we left off in part two.

Step 1: Run the application from within the IDE or point a IE browser to https://rp.contoso.com/mvcapplication/. The Admin page requires the user to be authenticated.

1.1 On the first page click on the Admin link and then the Login button.    
1.2 You should now be prompted to log on with a domain user. (Create a domain user account in the AD, if you haven't done so already. Don't forget to set Display name, Department, and Email address for the user).
1.3 The browser should display an error stating that fs.contoso.com is unreachable.
This is expected behavior as we haven't yet set up the relying party trust on the IdP STS side. Verify this issue by opening up the event viewer on ContosoServer and look for an error under Application and Services log --> AD FS --> Admin, saying something like "The requested relying party trust 'https://rp.contoso.com/mvcapplication/' is unspecified or unsupported".

Step 2: Create a Relying Party Trust in AD FS: Over at ContosoServer, there are two ways to accomplish this. Either we do it manually with the Add Relying Party Trust wizard in the AD FS Management UI or by using the Powershell cmdlet Add-ADFSRelyingPartyTrust, as I am showing here:

001 Add-ADFSRelyingPartyTrust -Name rp.contoso.com -MetadataUrl https://rp.contoso.com/mvcapplication/federationmetadata/2007-06/federationmetadata.xml MonitoringEnabled $true -AutoUpdateEnabled $true

If you get an error saying: "The underlying Connection was closed: Could not establish trust relationship for the SSL/TLS secure channel." you need to install the SSL cert that we configured on ContosoClient into the Trusted Root Certification Authorities store on ContosoServer.
If it still fails, check that Static Content is enabled on ContosoClient: Add Remove Programs --> Turn Windows Features on or off --> Internet Information Services --> World Wide Web Services --> Common HTTP Features --> Static Content

Another way of generating the Relying Party Trust is to use the -MetadataFile parameter and point to the FederationMetadata.xml file on disk on ContosoClient, such as \\ContosoClient\[Shared_folder]\MvcApplication\FederationMetadata\2007-06\FederationMetadata.xml. The problem with this approach is that the Relying Party Trust can't be automatically updated by monitoring any changes in the RP's federation metadata.

If you try to log on again, it still won't work. In the event log on ContosoServer you would see an access denied exception. We explicitly need to permit users to access the RP.

Step 3: Create a Claims rule set (issuance authorization rule) and assign it to the relying party: The same goes with this one. You can either do this manually or use AD FS cmdlets. In this case New-ADFSClaimRuleSet and Set-ADFSRelyingPartyTrust.

001 002 $claimRuleSet = New-ADFSClaimRuleSet -ClaimRule ' => issue(Type = "https://schemas.microsoft.com/authorization/claims/permit", Value = "true");' Set-ADFSRelyingPartyTrust -TargetName rp.contoso.com -IssuanceAuthorizationRules $claimRuleSet.ClaimRulesString

By applying the above rule to the Relying Party Trust we permit all users to access our RP application.

The expected behavior when trying to log on now is that the authentication process will succeed, but the security token will not contain the claims that the RP relies on.

Step 4: Transform the LDAP attributes that the relying party requires from Active Directory into claims. We need to transform the user account attributes that we retrieve from the attribute store Active Directory. Run these two cmdlets in Powershell ISE 3.0 on ContosoServer to add a new claims rule set (issuance transform rule) relying party trust configuration.

001 002 $claimRuleSet = New-ADFSClaimRuleSet -ClaimRule 'c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/name", "https://schemas.microsoft.com/ws/2008/06/identity/claims/role"), query = ";mail,displayName,department;{0}", param = c.Value);' Set-ADFSRelyingPartyTrust -TargetName rp.contoso.com -IssuanceTransformRules $claimRuleSet.ClaimRulesString

Step 5: Update the RP application on ContosoClient: Modify the AdminController.cs, AccountModel.cs and the Index.cshtml (under Views-->Admin) so that the retrieved claims are displayed. One way of authorizing access to protected resources within the RP is to derive from ClaimsAuthorizationManager and override the CheckAccess method where we would and write our access control rules, not shown here. This customized class can then be added to the processing pipeline before the requests ever reach the RP internal logic, either declaratively or programmatically as described on the ClaimsAuthorizationManager page.

Ok, now finally when we run the application we should be able to reach the Admin page!

This concludes this series on how to set up an internal claims-based solution lab with ADFS on Windows Server 2012 with a claims-aware ASP.NET MVC 4.0 application as the RP. The purpose of these blog posts is just to illustrate one specific lab(!) scenario and we merely scratched the surface of the claims-based identity problem domain.