UAG SP1 and AD FS v2 are Better Together–FBA and Claims

In previous post I started with introduction for UAG and AD FS integrations scenarios. Today post will discuss the first topology - Authentication to UAG Portal via Forms Based Authentication and accessing internal claims based application and other types of applications.

Many companies want to provide rich application experience to its remote workforce and telecommuters. This is one of the most common configurations for WebSSO scenario where company needs to publish internal applications to its remote users while ensuring that application access is done via secure access mechanism and users are properly authenticated before accessing internal applications. One of the great advantages of using FBA on the UAG trunk is that it will allow us to access all kind of applications on the back end, as long as you can authenticate to them with the same AD credentials used during FBA. It can be NTLM authentication, it can be Kerberos Constrained Delegation or it even can be forms based authentication, UAG can do them all.

Figure 1 shows classic design with Microsoft Active Directory (AD) acting as main authentication directory and providing access to the internal applications using NTLM or Kerberos authentication and providing authentication to the IDP STS. IDP STS server is published on UAG as an application server and it can be authenticated to just like any other internal Web application.

Figure 1

With this configuration users authenticate to the UAG portal with their user name and password and then are able to access any type of application via Single Sing On experience. For Kerberos and NTLM based applications it is accomplished via application configuration just like it was done in the prior versions of UAG. For claims based applications, the UAG is configured with additional authentication provider – AD FS v2, which provides SAML security tokens for authenticated users and allows seamless access to the application. Figure 2 shows how two different applications published on the same UAG portal use different authentication providers. As shown, application that uses Windows Authentication is configured with the same authentication provider as the UAG Portal Trunk, so after user is authenticated to the UAG trunk he/she can gain access to the application without providing additional credentials, experiencing SSO.

Figure 2

For the claims based application it works slightly different. The UAG is configured with additional authentication provider pointing to the AD FS v2 server. The claims based application is configured to use this AD FS v2 authentication provider. So how SSO is accomplished in this configuration? After configuring application with AD FS v2 based authentication provider UAG will publish another application under the application list. To accomplish SSO, you’ll need to open that application and under authentication tab configure SSO with the same authentication provider as the main UAG trunk (under which this app is published), in this case it is AD. When user decides to access claims based application, it will first authenticate to the AD FS v2 server by using AD credentials, obtain a security token and then present this token to the application. Figure 3 shows simplified authentication flow to the claims based application via UAG.

Figure 3

1. To access UAG Portal external users will be required to provide Username/password via Forms Based Authentication.
2. UAG will authenticate user against Active Directory.
3. After authenticating to UAG they will be presented with applications based on their security profile. It will be presented via UAG portal.
4. When user tries to access claims based application, the application will redirect the web browser request to the AD FS v2 server for user to obtain a security token.
5. Depending on the configuration, the AD FS server might show the home realm discovery page to users on which they must choose the organization to which they belong; in this case, it would be Woodgrove Bank, but since this is a WebSSO configuration, the IDP STS will not show home realm discovery page.
6. The IDP STS will send back a HTML 401 response message for user to authenticate. Forefront UAG is able to provide a single sign-on (SSO) experience for the user by answering the 401 response with the credentials previously entered by the user.
7. The IDP STS server provides a security token (containing a set of claims) to the user.
8. The user is redirected to the application and the user’s security token is presented to the application and the application opens in the user browser.

In this topology, the AD FS server does not get exposed to the Internet and you can’t federate it with external partners as RP. This is purely for internal use only, WebSSO solution design.

Next post will discuss the next topology - Authentication to UAG Portal via Certificate Based Authentication (Soft Certificate or Smart Card based certificate) and accessing internal claims based application and other types of applications.