Designing UAG and AD FS Solution

In the last many posts we looked at all kind of different topologies for UAG and AD FS configuration.

Now, since we are armed with knowledge of different configuration options, we can put all of them to use and see how we can apply them to real life situations. Before we do this, we need to revisit some critical technical requirements that exist with UAG and ADFS v2.

1. The UAG server can use the same AD FS v2 Federation Service URL only in one UAG trunk. This constraint is very important to understand because it is one of the critical elements that will affect your design.
2. Based on the previous requirement, if your configuration requires multiple UAG trunks with AD FS v2 support, and we will examine shortly why this might be the case, you will need to implement a separate AD FS v2 server for each UAG trunk.
3. UAG can provide Kerberos Constrained Delegation (KCD), but with the following constraints:

• • The UAG server must be in the same AD domain as the application server it is trying to access;
  • The User Account used to authenticate to the UAG server (the one we need to use KCD for) must be in the same AD Forest as the UAG server. If the user comes from a trusted AD Forest, the KCD will not work.

While designing your solution, you will have to gather a lot of requirements and understand the customer’s situation. Some requirements will force you into certain design topologies, and it is important to answer them at the beginning of the design process. There are at least three main questions that you have to answer when designing your UAG/ADFS access solution. The answers to these questions will direct you into a certain design topology or might require a combination.

The first question relates to password management. If you have a requirement to provide password management capabilities to remote users, -i.e. password change and notification of expiring password, you must use a UAG trunk that uses AD as the primary authentication provider. This type of trunk will authenticate you before providing access to any published applications. Access to claims based applications will be done via a secondary authentication to the back end published AD FS v2 server. This is the first topology that we discussed in the first part of this paper. Figure 1 shows this configuration.

Figure 1: UAG with One Trunk and dedicated AD FS in each Trunk

The second question relates to strong authentication, i.e. Smart Card based authentication. If there is a requirement to provide Strong Authentication, then your remote access solution must have topology #2, with UAG trunk configured for Smart Card authentication against the Active Directory and the AD FS server configured as an authentication provider for the claims based application. Anytime there is a requirement to use Smart Card authentication on the UAG portal, it will consume at least one AD FS Federation Service. Since we cannot use the same trunk to provide authentication via AD UserID/Password and Strong Authentication, the configuration will have at least two UAG trunks. Figure 2 shows this configuration.

Figure 2: UAG with Two Trunks and dedicated AD FS in each Trunk

The third question relates to the federation requirements with other companies. We need to identify if there is a federation requirement with external partners, specifically with IDP partners, where your company provides application resource for their use. If there is none, then our solution encompasses topology #1 and/or #2. If you must support federation as RP STS, then it complicates things. UAG trunks used for FBA or Smart Card authentication will consume their AD FS Federation Services, and it cannot be used by another trunk on the same UAG server.

We must implement yet another AD FS Federation Service on the internal network. If you need to satisfy all three requirements, you will need to have at least three UAG trunks, each with its own dedicated AD FS v2 server. Figure 3 shows this configuration.

Figure 3: UAG with Three Trunks and dedicated AD FS in each Trunk

As you see in Figure 3, this is not a simple solution anymore. While we can use the same UAG server to publish all of these services and all kinds of applications, we must implement three separate AD FS services. However, this is not the end of the complications. There are still some critical design decisions that you must make. What is the ultimate goal of this solution? Yes, the goal is to publish applications to the end users. And what type of applications are we trying to publish via UAG/ADFS configuration? We are trying to publish claims based applications. Let’s think for a moment about configuration requirements for claims-based application. The first and foremost requirement is that it must be configured with a trusted Security Token Service. It must be able to accept security tokens from trusted STS for user authentication.

How would we need to configure the claims-based application with multiple AD FS v2 servers and multiple UAG trunks? The first logical way to look at it is by creating trusts between the target application and each STS. As shown in Figure 4, in such configuration each trunk will have its own AD FS server which will be able to issue security tokens to the application. The problem with this approach resides with Home Realm Discovery. If we configure the application to trust multiple STSs, we have to make some type of determination at the application level of where the user must authenticate to get the valid security token. We are taking Home Realm Discovery out of the AD FS realm and trying to do it at the application level. While theoretically it is possible, the reality is that applications are not designed to do Home Realm Discovery. The underlying Windows Identity Foundation service must be extended to provide this functionality, which is not very easy to do and, in most situations, is not the best practice. The goal behind claims based authentication is to simplify authentication and simplify the application developer’s life, thus outsourcing authentication related Home Realm Discovery functions to the services designed for this purpose. The bottom line is that setting the application with multiple STSs is not recommended, and it is not the best practice.

Figure 4: Application with multiple RP-STS

The other common way to configure claims-based application is with one STS. Usually it will be designated as the Resource Provider role (RP-STS) and let RP-STS issue all security tokens for this application. RP-STS will be required to route user requests destined for other Identity providers. In our configuration, one of the AD FSv2 servers will be acting in this role. Which one should it be? The STS published via federated UAG trunk, (i.e. with UAG acting as AD FS proxy,) is the right choice for RP-STS. The configuration is shown in Figure 5.

Figure 5: Application with dedicated RP-STS

This is a complex solution, but if you must have at least two UAG trunks with support for claims-based applications, this is the only viable choice to publish them.

In the next post we will take a look at a specific real world example of how UAG and AD FS can be used to publish applications.