Monthly Archives: September 2011

September 24, 2011 · 10:26 am

UAG and AD FS are Better Together – Publishing Non-Claims Based Applications

In article “UAG and AD FS are Better Together – UAG as AD FS Proxy”  we explored how user authenticates to UAG portal via claims based authentication and then accesses claims based application published via UAG portal. But what if published application does not support claims based authentication, after all how many applications out there that do? Fortunately, UAG is capable to publish and provide SSO experience for non-claims based applications as well. The caveat here is that they must support Kerberos authentication. If you remember this “UAG and ADFS are Better Together– Strong Authentication” topology where we provided access with strong authentication, we configured KCD authentication  between UAG and AD FS server. In this topology the configuration is slightly different but concept is the same. Instead of doing KCD between UAG and AD FS, we’ll need to configure KCD between UAG and the target application.

UAG is smart enough to transition from the claims based authentication and request Kerberos ticket from AD Domain Controller on behalf of the user. During application configuration you’ll need to specify what claim you’d like to use as a leading value to get the Kerberos ticket. UPN is a good choice. Also, the proper SPN must be configured in AD for the target application.

Figure 1 shows main aspects of this configuration and Figure 2 provides high level authentication steps of how this works. It is very similar to the previous configurations, just in slightly different order.

image

Figure 1

  1. First, user must authenticate to the portal with SAML token, this is done via authentication to the backend AD FS server.
  2. When user tries to access published application that was configured with Kerberos Authentication, the UAG server will contact AD Domain Controller and will get Kerberos Service ticket for the target application. It will use the claim value that was configured with this application in its request to Domain Controller.
  3. Then UAG will send Kerberos ticket to the target application. Application will use the Kerberos ticket for authentication and authorization decision.
  4. If authentication was successful target application will allow access to the end user.

image

Figure 2

This configuration has similar constraints as was discussed in topology with Smart Card authentication, they relate to the Kerberos constraints. In this configuration 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.

About these ads

Leave a Comment

Filed under AD FS, Cloud Security, Federation, Identity Management, Security, UAG

Tagged as , , , , ,

September 22, 2011 · 7:23 pm

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

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.

1 Comment

Filed under AD FS, Cloud Security, Federation, Security, UAG

Tagged as , , , , , ,

September 1, 2011 · 7:17 pm

UAG and AD FS are Better Together – UAG as AD FS Proxy

In previous topologies (1 and 2) we did not expose AD FS server to the outside users as primary form of authentication. This topology will do this. One of the benefits of using UAG server in combination with AD FS is that it can now act as gateway or proxy server to the internal AD FS server, in fact UAG can now be configured as the relying party with AD FS server and accept SAML token for user authentication.

Figure 1 shows topology with AD FS acting as main authentication directory and providing access to internal claims based applications.

image

Figure 1

With this configuration UAG trunk is configured to use AD FS for authentication, it passes you all the way to the AD FS server, which challenges you for credentials, in this case it will prompt to provide username and password. AD FS issues security token to the user and it is presented for authentication to the UAG server. UAG server grants access to the UAG portal based on the security token issued from the trusted IDP STS – our internal AD FS server. Figure 2 shows how UAG trunk and published applications configured with different authentication providers.

image

Figure 2

When user tries to open published application, the user will obtain a new security token from the IDP STS, specific to this application.

Figure 3 shows authentication traffic to access the UAG portal and Figure 9 shows how user will access published claims based applications via UAG portal.

image

Figure 3

  1. The remote user attempts to access Forefront UAG portal. Since the UAG trunk is configured to use AD FS as its authentication provider, the Forefront UAG redirects the web browser request to the AD FS (IdP STS) server to authenticate the user. During this step, the IdP STS server might show the home realm discovery page to user (not shown in this diagram) on which he/she must choose the organization to which they belong; in this case, it would be Woodgrove Bank, but since this is a WebSSO configuration, the IDP STS will not show home realm discovery page. The IdP STS must authenticate the user. Depending on how it is configured, it might present user with AD FS Forms based authentication page or it might prompt with Windows authentication pop-up dialog box. The remote user provides credentials and authenticates using his/her own AD DS credentials.
  2. After successful authentication IdP STS creates security token with claims and it is transferred to the user.
  3. User is silently redirected and automatically authenticated to Forefront UAG using the security token created by the IdP STS server. User will see UAG portal with applications that this user is authorized to access. It is important to note, that authorization is done via claims and not via traditional windows security groups. In this configuration UAG did not authenticate the user against AD, it authenticated user solely based on the SAML token, and as such, the authorization decisions must be made based on the content of SAML token. Thankfully, Forefront UAG is smart enough to perform such authorization decisions.

After user authenticated to the portal he might decide to access published application, after all, why access the portal if not using applications?

image

Figure 4

  1. The remote user attempts to access the published claims based application using claims-based authentication in one of two ways, listed below. Regardless of the mechanism, target application will redirect the user to its trusted Resource Provider STS, in our case it is IdP STS.
    • By accessing the Forefront UAG portal and then clicking the published application (this is the follow up procedure to the previous diagram)
    • Or by accessing the published application directly using the alternate access mapping name (if application was published that way). If this is the case, the preceding steps in the previous diagram might take place as well, but user will not see the UAG portal, he will be taken straight to the published application.
  2. Forefront UAG redirects the web browser request to the IdP STS server to authenticate the user. Since user is already authenticated to IdP-STS when he authenticated to UAG portal, he will automatically re-authenticate to it with current session cookie.
  3. IdP STS creates security token with claims for published application and it is transferred to the user.
  4. User is silently redirected and automatically authenticated to the published site, after which the site appears.

By using UAG as the front end secure access point we are actually able to simplify AD FS infrastructure. In most situations, for Internet facing deployments, AD FS would deploy Federation Proxy server, which authenticates users on behalf of the internal AD FS server. With this configuration UAG server act as the front end gateway to the internal AD FS server and it is publishing AD FS authentication pipeline via its application publishing mechanism.

At this point it would be a good time to mention what type of UAG Portal features are not available if UAG trunk is configured as relying party to AD FS server. The first one is important to mention because it relates to the user password management. When UAG trunk is configured with AD authentication, it is capable to provide the following two important functions for our remote users:

  1. Password expiration notification. This is configurable on the trunk usually with 7 days threshold. If user password is about to expire, UAG will notify the user about it and allow to change it to a new password.
  2. Password change. After user authenticated to the UAG portal, he can always change password via this function. So if remote users are never come on site and they have no way to change their AD passwords via normal mechanism, then this is pretty much the only mechanism for self-password management.

With UAG trunk configured as relying party to AD FS, it never authenticates to AD. AD FS server authenticates user to AD and provides SAML token to UAG for authentication. UAG portal will never know if user password is about to expire and it is not capable to change user passwords because it is not configured with AD as authentication provider. Unfortunately, none of the password management functions provide via AD FS authentication, all it does, is authenticating the user. It will not notify the user about pending password expiration, nor does it provide the mechanism for password change. This is important limitation as it might affect overall design of your solution. If you must provide password management to your users, then you must publish UAG portal with AD as primary authentication provider.

There are other UAG features that are not available with AD FS authentication, here is a short list:

  • UAG supports only WS-Fed Passive profile
  • No Rich Applications publishing with AD FS authentication
  • Impact on Office Applications
  • Cannot publish applications installed on the AD FS 2.0 server
  • No HTTP to HTTPS redirection
  • No mobile device access on federated trunks

5 Comments

Filed under AD FS, Cloud Security, External Publications, Federation, Security, UAG

Tagged as , , , , , ,