Securing a Flex/BlazeDS application with Active Directory Single-Sign-On

le 13/01/2011 par David Hatanian

Your CISO wants you to integrate your Flex/BlazeDS applications into Active Directory ? Sure, you could use the old fashioned LDAP way, but you certainly prefer remove the burden of typing once again their credentials from your users' back. Get your users to love you by integrating you application to Active Directory's SSO.

Picture a web application with a Flex client interface, calling business services through a BlazeDS channel. Before using said services from their Flex interface, users have to authenticate with their AD account. This article deals with the way to set up a transparent authentication by using the Kerberos protocol that AD implements.

If things were just set up perfectly, BlazeDS would handle the Kerberos authentication all alone, unfortunately its current authentication capabilities don't go further than the old login/password combination. But hey, a BlazeDS channel remains a Java web-service, so let us take advantage of this ! Enter Spring Security...

Spring Security framework provides Java applications with a whole bunch of different ways to handle authentication. Starting from version 3, the framework xml-based configuration got simpler. And, rejoice, Spring Security supports Kerberos thanks to a recent extension. Now that every component of our architecture is defined, let us make them communicate together.

Architecture

This diagram summarizes the interactions between the components of our architecture to protect the BlazeDS channel :

Kerberos and Active Directory

First published in the 80s by the MIT, the Kerberos protocol is an Active Directory's default authentication mode which started off with Windows 2000. It replaces NTLM, which is not recommended by Microsoft anymore.

The protocol is based on ticket exchanges with a domain controller. This diagram shows how those exchanges are orchestrated when a client accesses a Kerberos-protected service :

(1) The user opens his Windows session with his AD credentials to use his workstation, as usual.
(2) The workstation contacts a domain controller to check the credentials and get a session-related ticket called a TGT (Ticket Granting Ticket).
(3) When the user accesses a Kerberos-protected service, Windows requests the Domain Controller for a ST (Service Ticket).
(4) The DC sends to the workstation a ST encrypted so that it will only be used by the requested service.
(5) The client can now authenticate himself to the service, no password is then requested.

The DC identifies a service by its Service Principal Name (SPN). In AD, each service is registered as a user account, which is then mapped to a SPN during the generation of the service key with the ktpass tool. In our case, our web service's SPN is something like HTTP/appserver.octo.com@AD-DOMAIN.

Now, let us see how to integrate our service (the Flex application server part) with Kerberos.

BlazeDS configuration

Spring Security integrates in theory with BlazeDS through the Spring-Flex project. Unfortunately this support is currently limited to username/password authentication. Thus, we have no hope to take advantage of Spring-Flex for the Kerberos authentication. We detail our solution below.

We use Spring Security URL filters to protect two types of resources :

Static resources (html, css, ...), including the swf file which is the client part of the application
The BlazeDS endpoint (i.e. the server-side of the BlazeDS channel)

Here is our Spring Security configuration file :

<sec:http entry-point-ref="spnegoEntryPoint" auto-config="false">

  <sec:intercept-url pattern="/**" access="IS_ AUTHENTICATED_FULLY"  />

  <sec:custom-filter ref="spnegoAuthenticationProcessingFilter" position="BASIC_AUTH_FILTER" />

</sec:http>

The intercept-url tag is used to require the user to be authenticated. The custom-filter tag specifies that the authentication data will be processed by SPNego (see below).

When accessing one of those URLs, Spring Securiy triggers authentication exchanges following the SPNego protocol. SPNego enables to negotiate the authentication mode used (for example NTLM or Kerberos) so that the client and the server reach an agreement on a mode they can both handle. The negotiation uses an HTTP 401 response from the application server, containing the SPNego headers which state that the server can handle Kerberos.

Once the browser and the server have agreed on the use of Kerberos, the browser calls the Windows API to request the Domain Controller for a Service Ticket to get access to the application server. Then, the ticket is validated by the Spring Security Kerberos Extension by using the server's own service key described in the Kerberos presentation above.

If the ticket is validated, the user is authenticated and Spring Security authorization mechanisms (roles, ACLs) take place to grant or deny access to a given resource. The authorization phase is independent of Kerberos.

But here's the snag : using a HTTPS BlazeDS channel (SecureAMFEndpoint) requires to use the BlazeDS login mechanism consisting on the server of a LoginCommand class. So, we implemented our own LoginCommand (PreAuthLoginCommand)... which does not bother to make any credentials check, the authentication being actually handled by Spring Security before any access to the channel.

public class PreAuthLoginCommand implements LoginCommand, LoginCommandExt {

public Principal doAuthentication(String username, Object credentials) {
//On n’effectue aucune verification !
logger.info("doAuthentication " + username + ", returning a PreAuthPrincipal");
return new PreAuthPrincipal(username);
}

public boolean doAuthorization(Principal principal, List arg1) {
logger.info("doAuthorization " + principal + ", returning true");
return true;
}
…
}

Getting further

The article did not mention the client workstation configuration. It is very simple and consists of two points :

Use a SPNego-Kerberos-enabled browser such asInternet Explorer, Firefox or Chrome
Configure the browser to trust your application (thus allowing the application to receive Service Tickets from your browser). This configuration can be deployed on a whole set of workstations through Active Directory GPOs

For further details see the "Links" section below.

One last idea to improve your security architecture : give your users a way to logout from their Kerberos-related session in your application and ocasionnally get back to a password-based authentication. This will allow a user different of the AD account owner to authenticate.