UAG and ADFS Better Together–Publishing Applications to Partner Organizations

In this scenario, our partner organization users access claims based applications published by our organization UAG servers. The partner users provide security tokens issued by the partner controlled Identity Provider to our AD FS v2 published by the UAG server. This configuration is the most common federated access scenario, and UAG works very nicely to make it all happen.

The ultimate goal of such configuration is to provide a SSO experience to the end user and never ask them for additional credentials or any type of questions. There are two main areas that must be properly configured to accommodate SSO. The first one is part of the partner organization configuration. Their IdP must be able to authenticate the user on their internal network via SSO. This is easily done if IdP is using AD FSv2. As part of the same AD Forest, it will authenticate internal users via Windows Integrated Authentication and will issue the required security tokens. The second part in this configuration is to configure Home Realm discovery. RP-STS residing on our network (woodgrovebank.com) is probably acting as IdP for internal users, or it might have more Federated trusts with other IdPs. The proper configuration of Home realm discovery is important in Federated configurations so that users are not confused where they need to authenticate and that they might not need to see other partners in your organization. Home realm discovery can be configured via multiple ways and is a topic of its own. We will cover it sometime in future updates to this paper or via a separate article.

Figure 1 shows the overall topology for federated application publishing. If you are familiar with all previous topologies, then you can see how this will work, as it is pretty much an extension on all the previous configurations. Let’s take a look via Figure 2 at the high level authentication flow.

Figure 1: Federated WebSSO Components

1. First, the remote user will try to access the application published via the UAG server. Since the application is configured to work over claims-based authentication, it will redirect the browser to its RP-STS.
2. RP-STS can be published on the same UAG trunk as our application. This trunk must not use internal AD for authentication. It must be configured as AD FS proxy trunk with RP-STS as the AD FS server behind it – i.e. it must be acting as a relying party. The user will contact RP-STS to get the security token for our target application. This is when Home Realm discovery takes place. If Home Realm Discovery is not configured to automatically redirect this user to his own IdP, then he/she will be prompted to choose his IdP from a list of configured trusted IdPs.
3. During this step, the browser is redirected to his IdP, and it will try to request a security token for RP-STS. IdP-STS and RP-STS have a trust relationship, and, based on the conditions of this relationship, the IdP-STS will issue a security token to the user.
4. This token will be posted back to the RP-STS, where it will be evaluated and based on the configured rules, and transformed into a new security token with a new set of claims suitable for consumption by the target application.
5. The token generated by the RP-STS is redirected back to the user computer, and then, in steps 6 and 7, this token is posted back to the target application. The application will make its authentication and authorization decisions based on the claims presented in the token.

Figure 2: Federated WebSSO Authentication Flow

This topology is an extension of the third topology we discussed in this paper, (Authentication to UAG Portal via Claims Based Authentication and accessing internal claims based application,) and all of the specific configuration related to the UAG and AD FS server are generally the same as in that configuration. The main differences are related to the more complicated Home Realm Discovery configuration and configuration of the partner IdP-STS.