Forefront UAG and ADFS: Better together

Artikel
04/14/2010

Overview:

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)

Requires agents to be incorporated into the web application – unless using Token agent.
Requires connectivity to the host from the internet – this can be a direct connection or a connection via a reverse proxy / web publishing solution.
ADLDS or Active Directory can be used as the account store.
Open standards based and integrates with other Federation technologies.
Licensing included in Windows CAL (Client Access License) or with the Windows Internet Connector.

Forefront Unified Access Gateway (UAG)

Does not require an agent on the web server, as this is a gateway based solution.
Can publish applications, eliminating the need to for an application server to have direct application connectivity with the internet.
Can authenticate to many authentication repositories.
Not based on open standards but it can be configured to pass credentials to other SSO and Federation technologies.
Licensing included in Enterprise CAL (ECAL), or can be purchased standalone or as an Internet Connector.

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!

ADFS, one size architecture does not fit all:

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:

Term	Definition
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: https://msdn.microsoft.com and https://www.microsoft.com.

Table 1

Consider the following typical (and generic) scenario (figure 1 below).

The user’s web browser tries to access the web server and is redirected to the ADFS-R (proxy) server (steps 1 and 2) to authenticate the user.
At the ADFS-R server, after discovery of what identity partner the user should access, the browser is redirected to the ADFS-A (steps 3 and 4).
At the ADFS-A (proxy) server, they are authenticated and given an SAML token and redirected back to the ADFS-R server (steps 5 and 6).
Once back at the ADFS-R server, the SAML token is exchanged for a token that the web server understands and the user is redirected back to the web server (steps 7 and 8).
Finally, once the user’s web browser presents the appropriate token (cookie), the web server allows the user access to the content (steps 9 and 10).

Figure 1

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: https://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 (https://www.bing.com).

Why integrate Forefront UAG and ADFS?

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:

A corporate user accesses a portal environment represented and protected by Forefront UAG.
Forefront UAG prompts the user for credentials and then provides the user access to the portal.
The user clicks a link that is protected by ADFS, either an internally or externally hosted server.
Without ADFS and Forefront UAG integration, the user will be prompted for the same credentials again and then allowed access to the web server.

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).

The user accesses a portal published by Forefront UAG and is authenticated. The user then clicks on a link in the portal and is redirected to an externally hosted web server (steps 1 and 2).
The user tries to access the web server and is redirected to the ADFS-R (proxy) server (steps 3 and 4).
At the ADFS-R server, after discovery of what identity partner the user should access (home realm discovery), the user is redirected to the ADFS-A (steps 5 and 6).
At the ADFS-A server (published by Forefront UAG), the user is automatically authenticated using the existing Forefront UAG cookie/credentials and given a SAML token and is redirected back to the ADFS-R server (steps 7 and 8).
Once back at the ADFS-R server, the SAML token is transformed into a token that the web server understands and the user is redirected back to the web server (steps 9 and 10).
Finally, once the user presents the appropriate SAML token, the web server allows the user access to the content (steps 11 and 12).

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.

Ok, I am sold, how do I get there?

Requirements:

The configuration is pretty simple. There are a few requirements:

You will need to define a dedicated IP address on the Forefront UAG server for publishing the ADFS trunk – you can’t share an existing Forefront UAG IP address.
You will need to configure an ADFS SSL (HTTPS) certificate on the Forefront UAG server. The SSL certificate must carry the FQDN of the ADFS server.
You will need to enable “cross-site single sign-on” authentication in Forefront UAG for the Forefront UAG Portal and the ADFS trunk, see: https://technet.microsoft.com/en-us/library/ee921441.aspx.
The cookie domain name of your ADFS trunk and the Forefront UAG Portal trunk should be the same, for example: the Forefront UAG Portal trunk could be named https://myportal.CONTOSO.COM and the ADFS trunk could be named https://adfs.CONTOSO.COM. As long as the domain names (CONTOSO.COM) are the same, you can use the Forefront UAG cross site authentication.

Setup (Publish ADFS with Forefront UAG):

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.

Testing (Publish ADFS with Forefront UAG):

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).

Figure 3

After logging in to the Forefront UAG portal, you will be redirected to the appropriate ADFS protected resource.

Setup (Enable Cross Site Authentication):

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: https://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:

C:\Program Files\Microsoft Forefront Unified Access Gateway\von\InternalSite\inc\CustomUpdate\adfssso.inc (see figure 4)
C:\Program Files\Microsoft Forefront Unified Access Gateway\von\InternalSite\inc\CustomUpdate\uagsso.inc (see figure 4)
C:\Program Files\Microsoft Forefront Unified Access Gateway\von\Conf\WebSites\adfs\conf\CustomUpdate\WFEList.xml (see figure 5)
C:\Program Files\Microsoft Forefront Unified Access Gateway\von\Conf\WebSites\uag\conf\CustomUpdate\WFEList.xml (see figure 5)
C:\Program Files\Microsoft Forefront Unified Access Gateway\von\Conf\WebSites\adfs\conf\CustomUpdate\WhlFiltSSO.ini (see figure 6)
C:\Program Files\Microsoft Forefront Unified Access Gateway\von\Conf\WebSites\uag\conf\CustomUpdate\WhlFiltSSO.ini (see figure 6)

Figure 4

Figure 5

Figure 6

Testing:

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.

Summary:

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

Comments

Anonymous
April 27, 2010
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.
Anonymous
June 03, 2010
Do you know how to go from a trial to a real licens without uninstalling the trial?
Anonymous
December 13, 2010
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?
Anonymous
June 22, 2011
Thanks for this nice article! How about ADFS 2.0 (your article describes ADFS 1.1) and UAG?
Anonymous
May 14, 2012
I heard an ADFS proxy is not certified to be used with UAG is that correct?
Anonymous
June 13, 2012
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?

Freigeben über