In a new Spotlight Feature, Javalobby hosts an article by Matthew Porter introducing the Acegi Security Framework - the new kid on the block in the Java security space. In this first of a two part series, Matthew discusses how to work with simple Authentication, Authentication Providers, and Authorization with Acegi and Spring. In part two, he will discuss how to use AOP and Acegi to secure your business objects. Check out Part 1 and leave Matthew some feedback!

Read part one of the article here.

I've been working with Acegi for several months and am quite happy with it, especially since we're using it in a very granular way, down to object->property->value based entitlements. If you're looking in to a flexible and sophisticated security framework, especially if you're already using Spring, give Acegi a few hours' look. Just don't expect it (or any security framework) to be easy sailing at first unless your needs are very simple...

Can you give a quick overview how based on a prinicpal determine access to a particular object instance attribute? Visibility, Read vs. Read/Write?
Thanks
-phil

In Acegi Security we have an AclManager which can retrieve a list of AclEntry[]s for any Object. The general idea is you pass your domain Object to AclManager along with your Authentication and it will return just those ACL entries applicable for the principal and domain Object.

There is a new AccessDecisionVoter not mentioned in Matthew's article (it is very new), called BasicAclEntryVoter. It accepts a list of acceptable permissions and the class of domain objects you wish to secure. Any method invocation will then have its arguments iterated, and if the specified domain object class is located, the AclEntry[]s will be looked up via AclManager. A list of allowed permissions is also defined against the BasicAclEntryVoter, one of which must be granted to the principal according to the AclEntry[]s list.

Also working in concert with AclManager are two "after invocation" providers. They look at the Object returned from a secured method invocation. One throws an AccessDeniedException if one of the list permissions defined against the provider is not held (according to the AclEntry[]s). The other iterates a Collection, removing elements to which the principal does not hold one of the provider-defined listed of permissions.

If you checkout CVS, you will see our Contacts Sample application has been refactored to use these new ACL capabilities and provides a good example of how even domain instance security can be employed without adding a single line of secure-aware Java code to your services layer. It also demonstrates an Acegi Security taglib which works with AclManager as well.

I think Matthew was going cover this next time in the part 2 in more deteail.

The article starts off saying that J2EE security and JAAS are incomplete in that they are not sufficient, but beside of seeing a different way of configuring and processing security, I don't see a difference. Also, I don’t share the opinion that it matters how a container vendor implements container security as long as he follows the specs, which is something they all do.

Lets assume for a moment that Acegi becomes successful as a security framework. Wouldn’t it be easier for the industry to pick this up as a pseudo standard if it was based on JAAS?

Like JAAS, Acegi has pluggable authentication and allows authorization against different policy stores. Primarily the authentication is enforced through J2EE security constraints. The use of j_username and j_password is very close to container managed J2EE security (with the same caveat of requiring SSL to be secure), except for that the j_security_check action can be freely named because it is handled by the Servlet filter than the application server.
 
I am not saying that Acegi isn’t a good approach to follow and people seem to like what it does. I am questioning the need for multiple open source projects (JGuard and Gabriel) doing the same thing.

It seems that everybody is somehow unhappy with J2EE security and JAAS – I agree -, so why not putting it all on a list and work on improving the standard or to come up with a standard framework for application security?

Frank

Frank, the Acegi Security FAQ at http://acegisecurity.sourceforge.net/faq.html contains an answer to the JAAS question, as well as why one would use Acegi Security instead of Servlet Spec security services for enterprise applications.

I am certainly happy to work with others on developing formal standards. In the meantime we needed a solution for our internal needs, and due to public requests we made it public and continued to develop it, accept contributions etc.

Have been looking at this security framework with a lot of interest. I had a query

- Can the Acegi be used without Spring. If Yes how?

Maybe a pretty dumb question :) considering that it does say Acegi for Spring