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.