UAG and ADFS are Better Together– Strong Authentication

  • Article

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.

image

Figure 1

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.

image

Figure 2

  1. Remote employee goes to the Forefront UAG portal and authenticates against the AD DS server using Certificate based authentication (Smart Card). They will get access to the UAG portal with published applications based on their security profile.
  2. 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.
  3. 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.
  4. 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 Kerberos ticket acquired on behalf of the user (KCD).
  5. The IDP STS server provides a security token (containing a set of claims) to the user.
  6. The user is redirected to the application and the user’s security token is presented to the application and the application appears.

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.