Share via

UAG and AD FS are Better Together – Strong Auth to Cloud Based Applications

  • Article

Today we will discuss a solution that provides the following functionality: You what to require your company external users to use strong AuthN when they access 3rd party trusted claims based applications. These applications can be hosted in the Cloud or by Partner organization.

The description of this topology is a mouthful, but that is exactly what this topology provides to us. It is really an extension of the second topology with addition of federated Resource Provider components. Figure 1 shows this topology.

In many situations you want to allow your remote users to be able to access claims based applications published by your business partners. So the critical question is how do you want to authenticate your remote users against IDP STS? Business partner would usually have RP STS which will issue security tokens for application access. Your user identity does not come from RP site of the equation; it comes from your side. If you want to increase the security, and in the current day and age it is becoming a requirement, your remote users must use smart cards before they can gain access to the IDP STS and receive their initial security token.

First, remote user will try to access partner application which will redirect them via their RP STS back the IDP STS Federation Service. IDP STS external URL is published via UAG and it will require smart card authentication. User authenticates to UAG, receives their security token from internal IDP STS and redirects it back to RP STS and then gains access to the partner application.

image

Figure 1

Figure 2 shows authentication traffic to for this configuration.

image

Figure 2

  1. First, remote user will try to access application published by the Partner organization or by the Cloud Application provider.
  2. Application will redirect user browser to its own STS (RP-STS). RP-STS will need to perform a home realm discovery. At this time user will be automatically or manually redirected to his own IdP-STS.
  3. Since in this situation, the IdP-STS is published via UAG on the a trunk that requires certificate authentication, the user will be prompted to authenticate with his Smart Card. The authentication will be done against his corporate AD.
  4. When UAG authenticates the user, it will use Kerberos Constrained Delegation to authenticate to the IdP-STS, and those providing SSO experience to the user. IdP-STS will authenticate the user and will issue Security token for RP-STS.
  5. User browser will receive the token from IdP-STS and post it to the RP-STS.
  6. Finally, RP-STS will take token issued by IdP-STS, it will evaluate it content and based on its own rules, will create its own security token. Claims in this token might be the same as what was issued by IdP-STS or they can be transformed according to specific business rules. User browser will receive the final token from RP-STS and will post it to the target application. Application will authenticate the user and proceed with its logic.

As we can see, this configuration topology provides a powerful way to increase remote user security and it did not require any type of special modifications on the part of the Resource Provider organization. For all they care, the initial authentication by the end user was done via any type of authentication mechanism. It gives a powerful and flexible way to security managers to increase their organization security posture and the same time provide access to remote applications over which they have no direct control.