In the previous post we looked at the most common UAG configuration, with user using username and password for authentication to UAG. In this post we are going to explorer the following configuration – user authenticates to UAG Portal via Certificate Based Authentication (Soft Certificate or Smart Card based certificate) and then access internal claims based application and other types of applications.
Smart Card authentication is becoming a major requirement in many industries. In Federal Government very soon it will be a mandatory authentication mechanism for internal and external logical application access.
AD FS configuration in this topology is very similar to previous topology, but with a few very critical differences. To enable Smart Card authentication, the UAG trunk is configured to require certificate authentication. During certificate authentication, the user will use a certificate from his smart card, it will be presented to the UAG server and UAG server will authenticate user based on the certificate content, usually it is done based on the value of Subject Alternative Name extension UPN value. UPN stands for Universal Principal Name, it is e-mail like value and it is enforced by Active Directory to be unique. UAG will read this value from user certificate and map it against Active Directory user account with the same value. All of this is done via Kerberos authentication and nowhere during this process has user provided his username or password.
Figure 1 shows classic design with Microsoft Active Directory (AD) acting as main authentication directory and providing access to the internal applications using Kerberos authentication and providing authentication to the IDP STS.
So how does user get security tokens from AD FS in this configuration? UAG must be able to authenticate to it on behalf of the user, but user never provided his username and password. It is done via Kerberos Constrained Delegation (KCD). UAG is configured to be able to impersonate authenticated user via KCD and request service ticket from AD and present it to the AD FS server on behalf of the user. AD FS will issue security token to the user and user will be able to authenticate to the claims based application the same way as it was done in the previous topology. Let’s review step-through process again, Figure 2 show us simplified authentication flow.
While this topology increases security of initial authentication, it does lead to some limitations on the back end authentication and limits Single Sign On experience. To provide seamless access to back end applications they must support Kerberos authentication. On top of that, application servers must reside in the same Active Directory Domain as UAG server (obviously that means that UAG must belong to AD domain) and the user account must be in the same Active Directory Forest as UAG server as well. Also, there are requirements on the Domain and Forest Functional level, it must be at least at Windows 2003 level. These requirements put some limitations on the Single Sing On experience. If one of the listed conditions is not satisfied and user tries to access published application, the KCD will not work and he/she will be prompted to provide credentials in the common form of domain\username and password.
Same as in previous 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.
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.
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.
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.
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.
A few weeks ago I started working on a white paper about UAG SP1 and AD FS v2 configuration topologies and sample complex design based on those topologies. I’m still working on it, but I decided to publish different parts of it for folks to see and potentially get some feedback about it as well.
Today is the introduction time.
Unified Access Gateway (UAG) SP1 has introduced support for the AD FS v2. Now it is possible to publish claims based applications via UAG and provide secure access to AD FS servers by using one of many different configuration topologies supported by these products. This paper explains how to design solution by using UAG and AD FS v2, what type of critical requirements will dictate specific configuration and how to get around some of known limitations. It is assumed that reader has basic knowledge of UAG technology and AD FS technology, as this paper will build on that knowledge and introduce more advanced concepts of UAG and AD FS integration.
There are four main topologies that you can choose for AD FS WebSSO design and they are largely depend on the authentication requirements from the Internet to the UAG server or AD FS server and authentication requirements to the published application. The main topologies are as following:
Of course, the WebSSO configuration can be extended to the Federated WebSSO configurations, where customers will be accessing resources published by your company UAG or where your company might require authentication against UAG before accessing resources published by your partner company. The following three topologies are extensions of the last three main topologies:
There is another potential design topology which existed before UAG SP1. It is always possible to just publish internal AD FS v2 server via UAG server as a web app and expose authentication against STS Proxy FBA or straight to the actual AD FS server FBA or Certificate based authentication. This type of configuration does not utilize new advanced functionality introduced in UAG SP1 and we are not planning to review it here or use it as potential design topology.
The rest of the document is divided into two parts:
Part 1 – Provides detailed review of each topology. Before looking at potential design choices for potential customer environment we must understand how each topology works, what type requirements it has and any type of limitations.
Part 2 – Provides a sample design of UAG and AD FS solution. Powered by the knowledge of configuration options we’ll look how to fit each topology or a combination of topologies to different customer situations.