UAG SP1 and AD FS v2 are Better Together–Introduction

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:

1. Authentication to UAG Portal via Forms Based Authentication and accessing internal claims based applications and other types of applications.
2. Authentication to UAG Portal via Certificate Based Authentication (Soft Certificate or Smart Card based certificate) and accessing internal claims based applications and other types of applications.
3. Authentication to UAG Portal via Claims Based Authentication and accessing internal claims based applications.
4. Authentication to UAG Portal via Claims Based Authentication and accessing internal non claims based applications.

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:

1. Require your company external users to use strong AuthN when they access 3^rd party trusted claims based applications. This is an extension of the second topology in the previous list.
2. Cloud based authentication or partner based authentication. In this scenario, customers access claims based applications published by UAG server and provide security tokens issued by the Cloud Based Identity Provider or Partner company identity provider to AD FS v2 published by the UAG server. This is an extension of the third topology in the previous list.
3. Customers accessing non claims based applications published by UAG server by providing security tokens to AD FS v2 published by the UAG server. This is an extension of the fourth topology in the previous list.

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.