Tag Archives: Smart Card

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 , , , , ,

August 25, 2011 · 8:33 pm

UAG and ADFS are Better Together– Strong Authentication

In the previous post we looked at the most common UAG configuration, with user using username and password for authentication to UAG. In this post we are going to explorer the following  configuration – user authenticates to UAG Portal via Certificate Based Authentication (Soft Certificate or Smart Card based certificate) and then access internal claims based application and other types of applications.

Smart Card authentication is becoming a major requirement in many industries. In Federal Government very soon it will be a mandatory authentication mechanism for internal and external logical application access.

AD FS configuration in this topology is very similar to previous topology, but with a few very critical differences. To enable Smart Card authentication, the UAG trunk is configured to require certificate authentication. During certificate authentication, the user will use a certificate from his smart card, it will be presented to the UAG server and UAG server will authenticate user based on the certificate content, usually it is done based on the value of Subject Alternative Name extension UPN value. UPN stands for Universal Principal Name, it is e-mail like value and it is enforced by Active Directory to be unique. UAG will read this value from user certificate and map it against Active Directory user account with the same value. All of this is done via Kerberos authentication and nowhere during this process has user provided his username or password.

Figure 1 shows classic design with Microsoft Active Directory (AD) acting as main authentication directory and providing access to the internal applications using Kerberos authentication and providing authentication to the IDP STS.

image

Figure 1

So how does user get security tokens from AD FS in this configuration? UAG must be able to authenticate to it on behalf of the user, but user never provided his username and password. It is done via Kerberos Constrained Delegation (KCD). UAG is configured to be able to impersonate authenticated user via KCD and request service ticket from AD and present it to the AD FS server on behalf of the user. AD FS will issue security token to the user and user will be able to authenticate to the claims based application the same way as it was done in the previous topology. Let’s review step-through process again, Figure 2 show us simplified authentication flow.

image

Figure 2

  1. Remote employee goes to the Forefront UAG portal and authenticates against the AD DS server using Certificate based authentication (Smart Card). They will get access to the UAG portal with published applications based on their security profile.
  2. When user tries to access claims based application, the application will redirect the web browser request to the AD FS v2 server for user to obtain a security token.
  3. Depending on the configuration, the AD FS server might show the home realm discovery page to users on which they 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.
  4. The IDP STS will send back a HTML 401 response message for user to authenticate. Forefront UAG is able to provide a single sign-on (SSO) experience for the user by answering the 401 response with the Kerberos ticket acquired on behalf of the user (KCD).
  5. The IDP STS server provides a security token (containing a set of claims) to the user.
  6. The user is redirected to the application and the user’s security token is presented to the application and the application appears.

While this topology increases security of initial authentication, it does lead to some limitations on the back end authentication and limits Single Sign On experience. To provide seamless access to back end applications they must support Kerberos authentication. On top of that, 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. These requirements put some limitations on the Single Sing On experience. If one of the listed conditions is not satisfied and user tries to access published application, the KCD will not work and he/she will be prompted to provide credentials in the common form of domain\username and password. 

Same as in previous topology, the AD FS server does not get exposed to the Internet and you can’t federate it with external partners as RP. This is purely for internal use only, WebSSO solution design.

3 Comments

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

Tagged as , , , , ,

February 21, 2011 · 11:41 pm

Secure Application Access by using AD FS and UAG – Strong Authentication

In the last two posts on this subject I showed to you how to use UAG with Forms Based Authentication and as ADFS Proxy. Todays demonstration shows how to use it with Strong Authentication – Certificate Authentication. The topology in this configuration is very similar to the FBA topology, but it requires additional configuration on the UAG to require certificate authentication and we have to utilize Kerberos Constrained Delegation to access ADFS server. KCD is required because when user authenticates to the UAG portal, he never provides his UserID/Password, so if we want to have SSO then UAG must be able to impersonate user by using KCD, and provide Kerberos ticket on the behalf of the user to the AD FS server.

This demonstration was created to satisfy the following requirements for our fictitious Woodgrove Bank Corp:

  • Woodgrove Bank must provide secure access to documents on its Extranet SharePoint site to remote employees.
  • SharePoint site was designed to accept Claims based authentication.
  • Remote employees must use Smart Cards for accessing the site (certificate authentication). 
  • Limit access to client computers that do not meet the company policy.

As always, for best user experience please watch this demo in Full screen and enable HD. Let me know if you have any questions.

1 Comment

Filed under AD FS, Federation, Security, UAG, Video Demonstration, Video Presentation

Tagged as , , , , , , , , , , ,