Acegi Security and Site Minder
Some assembly required
Acegi Security has made a name for itself as a flexible and powerful Java security application that is fairly easy to use and integrates well with existing applications. Its strength is that it is interface based relying on Spring’s dependency injection to assemble a configuration for your application. Because of this, Acegi can integrate with a wide range of security technologies.
CA’s SiteMinder is a security application that is designed to integrate into the web server portion of an application. It assumes the responsibility of authenticating the user and determining if they are authorized for the URL they are attempting to visit. Once the user is authorized for a resource, the request is forwarded to the server responsible for providing it. The user’s identity is passed as a request header.
Acegi integrates with SiteMinder by providing a specific authentication processing filter. This filter looks for a specific URL and verifies that a user has been created for the SiteMinder header. There are a few shortcomings with the out of the box solution.
First, passwords are not needed in this scenario as SiteMinder has already authenticated the user. Acegi still requires a password be present. A simple work around is to use the id header as the password header as well.
Second, the default authentication processing filter requires a “defaultTargetUrl” be defined. This is the only URL that will be authenticated. This does not work for sites that allow users to enter from a number of different pages such as bookmarks or email links. I had to implement an alternative authentication processing filter to avoid this problem.
Lastly, Acegi does not invalidate the session if the user or the SiteMinder session number does not match what is stored in the session. Each application has to build a unique solution to these problems.
Despite the inadequacies, I found using Acegi to be fairly simple to integrate with SiteMinder. It took longer than simply coding a custom solution but not by much. We have yet to see if we will see any benefits as we transition from the legacy code to the Acegi interfaces.
Re: Acegi Security and Site Minder
/**
* @author Marty Milligan
*
* This class is used to get around limitation in the default Acegi implementation.
*
*/
package com.milligansisland.open.security.acegi;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.acegisecurity.Authentication;
import org.acegisecurity.context.HttpSessionContextIntegrationFilter;
import org.acegisecurity.context.SecurityContext;
import org.acegisecurity.providers.UsernamePasswordAuthenticationToken;
/**
*
* Extend the existing SiteminderAuthenticationProcessingFilter to simply check that the user has been authenticated
* and not care about the URL that is being accessed. This filter must be configured to only process secured resources.
*
*/
public class SiteminderAuthenticationProcessingFilter extends org.acegisecurity.ui.webapp.SiteminderAuthenticationProcessingFilter {
protected boolean requiresAuthentication(HttpServletRequest request, HttpServletResponse response) {
boolean bAuthenticated = false; // define return value
SecurityContext context = (SecurityContext)request.getSession().getAttribute(HttpSessionContextIntegrationFilter.ACEGI_SECURITY_CONTEXT_KEY);
if (context != null) {//if there is a security context
Authentication auth = context.getAuthentication();
if (auth != null && auth instanceof UsernamePasswordAuthenticationToken) { //check for an authentication token
UsernamePasswordAuthenticationToken token = (UsernamePasswordAuthenticationToken)auth;
bAuthenticated = token.isAuthenticated(); //make sure it is authenticated
}
}
return !bAuthenticated; //return true if user needs to be authenticated
}
}