NFJS - Spring ACEGI

Presented by Stuart Halloway, Relevance, LLC

ACEGI is a generalized authentication and authorization system for Java, with specific hooks built-in for the Spring Framework. Since my experience with such systems is light, my ability to cover what was presented will be correspondingly basic.

The name ACEGI is not an acronym. It is derived by using the first 5 odd letters of the alphabet. Like most Spring-based services, ACEGI relies heavily on XML-configuration files. It is built using the Inversion of Control pattern and with dependency injection, it is possible to modify behaviors of the security system. One key example pointed out by Stuart in the talk was that JAAS security library, which (if I remember correctly) is part of the Java standard, can be used as the authentication server instead of the default service provided by the ACEGI distro.

The key components of an ACEGI based system include:

• Authentication


• Authentication Manager


• Access Decision Manager


• Secure Object Interceptor


• Run As Manager


• After Invocation Manager

The last two components are only used in special cases. A simple use case would be:

1. User submits principle (user) and credential (password) to Authentication object


2. The Authentication Manager populates the Authentication class with Authorities (permissions) based upon the provided Principal and Credential


3. User invokes the desired method, which is intercepted by the Secure Object Interceptor (shades of AOP at work!)


4. The SOI queries the Access Decision Manager regarding whether the request can proceed


5. The ADM passes this query on to the Authentication object, which accepts or rejects the request based upon the stored security data


6. Assuming the request was allowed, the SOI then invokes the actual method requested by the user

Because of the use of AOP, it is possible to add security to objects that were not even designed with security in mind!

Internally, the Authentication object and the Access Decision Manager use a collection of web filters that are responsible for the ultimate processing of the security requests. These filters are configured in an XML file (another example of IOC and DI use). Several examples of how these filters are used were presented in the class. This turns out to be one of the more difficult concepts in using ACEGI. It turns out that these configuration files must be carefully constructed and the order of the filters must follow explicit rules in order for the system to work correctly. Stuart is a big fan of this system and even he had harsh criticism to levy about this issue.

As mentioned earlier, a lot of the details are being elided here, mostly because of my ignorance of security. Based upon the examples shown in class however, I believe that it would be very straightforward to set up a secure system (typically web-based, but that isn’t required) using the ACEGI Security system.