I have been asked on several occasions to compare and contrast ADFS with other Microsoft “Single Sign On” (SSO) technologies, such as Forefront UAG. While these are two very different architectures, they both can provide the same end-user experience, namely logging in once and accessing application after application. Not to go too deep into the comparison, here is the elevator pitch of the two technologies:
Active Directory Federation Services (ADFS)
Forefront Unified Access Gateway (UAG)
The real goal of this blog is to discuss how to make ADFS version 1.1 and Forefront UAG work together and get the SSO benefits of both!
Because of the flexibility of deployments in ADFS, there are many ways it can be deployed. Therefore, I will only address one deployment option in this blog, namely publishing the ADFS-A (also known as the Identity Provider – IdP) with an SSO experience with Forefront UAG (or IAG). It is important to note that this configuration is based on ADFS 1.1, which is part of Windows Server 2008 and Windows Server 2008 R2. This has not been tested or certified with ADFS 2.0.
Before we get too far into terms and acronyms, let me define a few here to level set everyone’s understanding:
ADFS-A
Refers to the Account or Identity side of a Federation relationship. In the example relationship of the MSDN site, which requires a login with your windows live ID, Windows Live is the Account or Identity Provider.
ADFS-R
Refers to the Resource or Service side of a Federation relationship. In the example relationship of the MSDN site, which requires a login with your windows live ID, MSDN is the Resource or Service Provider.
IdP (Identity Provider)
Refers to the ADFS-A or Identity/Account Provider.
SP (Service Provider)
Refers to the ADFS-R or Resource/Service Provider.
ADFS Proxy
A Proxy only solution, used to expose ADFS in the DMZ without requiring domain membership, which the ADFS server does require. ADFS Proxy uses a single port and communicates all content over SSL (HTTPS).
ADLDS
Active Directory Lightweight Directory Services, a lighter weight form of AD which basically provides LDAP only services and does not provide: Group Policies, Kerberos, or NTLM services.
SAML
Security Assertion Markup Language. This is an XML based language for communicating identities and information about the identities, called “claims”.
Cookie Domain
This is the domain name of the website or host. For example, “.microsoft.com” would be the single cookie domain for: http://msdn.microsoft.com and http://www.microsoft.com.
Consider the following typical (and generic) scenario (figure 1 below).
This may look like a lot of redirections but remember that once this is setup it happens in mere seconds or milliseconds, so the user does not see the complexity required to facilitate federation.
With Forefront UAG, we can replace the ADFS Proxy and provide a seamless secure user experience, eliminating redundant login prompts when used in conjunction with Forefront UAG. This architecture can be used with external federated partners or internal (inside your network) federated application servers. It is also worth mentioning that Forefront UAG can provide secure published access to the Application (Web Server), but that is not the focus of this blog (look here for other options on ADFS integration into Forefront UAG: http://technet.microsoft.com/en-us/library/dd857388.aspx).
It is not the goal of this document to go any deeper into the ADFS architecture or to discuss how to setup ADFS. Both of these are discussed on TechNet or on the internet using a Bing search (http://www.bing.com).
If users are accessing application published by Forefront UAG and ADFS, without integration they will be asked for multiple logins. One of the great features of Forefront UAG or ADFS is the SSO, or single login experience. TechNet does a great job discussing each technology by itself, but this blog discusses how to make them work together and get the benefits of both. Assume the following:
With Forefront UAG and ADFS integration, users will not be prompted at step 4 for credentials. The following diagram shows this integration (figure 2).
In this scenario (figure2), we can see the SSO in action.
Consider the following Forefront UAG and ADFS integrated scenario (figure 2).
This may look like a lot more redirections, but remember that once this is setup it happens in mere seconds or milliseconds and the user has a true “Single Sign On” experience.
The configuration is pretty simple. There are a few requirements:
The setup of Forefront UAG to publish ADFS is pretty straightforward. I will walk through it step by step here.
Step 1. Open up the Forefront UAG console, right click on HTTPS Connections, select New Trunk and then click Next.
Step 2. At the “Select Trunk Type” screen, select ADFS trunk.
Step 3. Click Next at the “Select Application” screen.
Step 4. At the “Setting the Trunk” screen, name the trunk (any valid name will work) and type in the external DNS name that you publish your ADFS server. Select an unused external IP address for the published ADFS site. Remember this IP address is dedicated to the ADFS trunk.
Step 5. At the “Authentication” screen, select the AD server you have defined for use by your existing Forefront UAG trunks.
Step 6. At the “Certificate” screen, select a valid SSL cert that includes the FQDN of the ADFS server name you typed in step 4. In my example, I use a wildcard certificate. Note, this does not have to be the same certificate or the token signing certificate that ADFS uses, it simply has to be valid for the name in step 4.
Step 7. At the “Application Server” screen, type in the internal IP address of the ADFS server, select the port as 443, check the “Use SSL” box and type the valid internal DNS name of the ADFS server. In my case, the internal name is quite different from the external name, but because I use wildcard certs on both Forefront UAG and the ADFS server, the internal server name and the public host name of the trunk (see step 3 of the wizard) do not need to be the same. WARNING: If your ADFS server also hosts your web application, you will want to use a different name, so that Forefront UAG does not rewrite content it should not. Generally, it is recommended to use specific certificates instead of wildcard certificates.
Step 8. At the “Application Login” screen, select the same AD authentication server you selected in step 5 above. Note that it only uses 401 requests (ADFS calls them Windows Integrated logon pages) and it will not use HTML forms authentication by default.
Step 9. At the “Endpoint Security” screen, accept the default and click Next (Endpoint security will be disabled by default later).
Step 10. At the “Endpoint Policies” screen, accept the default and click Next.
Step 11. At the “Completing the Create Trunk Wizard” screen click Finish.
Step 12. Activate the configuration and perform an IIS reset. Optionally, you can click the Configure button under the Trunk Configuration area to view and modify any settings. Pay attention to the “Server Name Translation” tab (not shown) and the “Session” tab. Notice the Session tab has “Disable component installation and activation” checked by default. The key difference with the ADFS Proxy trunk setup as described on TechNet is that we use authentication on this trunk and use these user credentials to authenticate to the ADFS server to get a SAML token.
Now that it’s setup, time to test. Make sure that the ADFS protected resource (web server) that you are typing into the address field refers to the hostname you typed in step 4. Assuming this is the case, when you try access the web site, you will be redirected to the Forefront UAG login screen (see figure 3 below).
After logging in to the Forefront UAG portal, you will be redirected to the appropriate ADFS protected resource.
Cross Site Authentication is the configuration option that allows you to go from a Forefront UAG “Trunk” to “Trunk”, without having to authenticate at each trunk. This option is documented at: http://technet.microsoft.com/en-us/library/ee921441.aspx, so I won’t rewrite this, but instead just refer to it. In my case, I had to modify the following files which are all discussed in the link:
Demonstrating this is quite simple. In my lab environment, I simply open my browser to my ADFS protected web site, and get redirected to https://sso.scd-labs.com, which is my ADFS Server published via Forefront UAG. After authenticating once, I am sent back to my ADFS protected website. Next, to prove that the ADFS to Forefront UAG integration works, I just type in the Forefront UAG portal in the web browser and I am automatically logged in without being asked for credentials. I can also go the other way, meaning log into Forefront UAG first, then redirect from Forefront UAG over to the ADFS web site and access the site without being prompted for credentials.
So assuming your testing went well, we have integrated ADFS and Forefront UAG, gaining the unique strengths of both solutions and only asking the user to log in once. You will also notice that once you log out of either the Forefront UAG or the SSO site, you are logged out of both because the session cookie in the user’s browser is destroyed.
Author: Kevin Saye, Security Technical Specialist – Microsoft
Reviewers: Ben Ben Ari, Senior Support Engineer – Microsoft Carsten B. Kinder, Principal Consultant – Microsoft Eddie Huibers, Consultant – Microsoft Mike Havens, Senior Support Engineer – Microsoft Meir Feinberg, Technical Writer – Microsoft Mohamed Mall, Security Technical Specialist – Professional Advantage
Excellent article! I have been looking everywhere to find out if this was possible and how to do it. This is a great solution for SharePoint 2010. Thanks for addressing it.
Do you know how to go from a trial to a real licens without uninstalling the trial?
Is this the same way to publish ADFS 2.0, instead using an ADFS 2.0 Proxy? If not, what do I need to change?
Thanks for this nice article! How about ADFS 2.0 (your article describes ADFS 1.1) and UAG?
I heard an ADFS proxy is not certified to be used with UAG is that correct?
this solution seems to be using ADFS 1.1, is that correct? If so, is there a solution around integrating UAG authenticating against AD LDS and then using ADFS 2.0 for SSO with other application that consume SAML 2 assertion?