Role based security and Spring

[spring04]

We are exploring the possibility of using ACEGI security framework in our Spring/Hibernate based application. Some of the basic requirements are that:

1. Role based security
2. Role based access for objects (e.g some objects are accessible to Admins only)
3. Role based access at object's method level.
4. Instance level security e.g Administrator can access the delete method on the Person whose ID is 1234

The question i've is that, if we keep the security rules in the DB, our application needs to constantly access the DB which might be a performance overhead as our application is a large scale application with hundreds of concurrent users. The alternative is to keep these rules locally. But this would be a security issue as anybody who has access to the m/c can see the roles, password etc. We need to encrypt this information but still able to INSTANTLY access this.

One other requirement is that we would like our application to be Single-Sign-ON enabled as it's a corporate level requirement. Hence this will be used for authentication purposes. Per my understanding, ACEGI security framework provides this support. Is my understanding correct?

Could someone please let me know what is the best approach for this?

Thanks in advance!

[Ben Alex]

Acegi Security uses CAS which addresses your single sign on requirement.

As for large numbers of concurrent users, Acegi Security uses HttpSession internally to store a small Authentication object (which basically identifies the principal and its GrantedAuthority[]s). So this shouldn't be a problem. Acegi Security uses caching extensively at every location where expensive access might be required.

If you use CAS, Acegi Security provides a CAS Adapter which allows you to use an Acegi Security AuthenticationManager. I'd encourage you to do that, probably with DaoAuthenticationProvider backed by JdbcDaoImpl. This will give you a single (zero code) but cached and flexible authentication base.

In terms of keeping "security rules in the DB", I don't know what you mean. If you are referring to authentication details, these really need to live in a DB for practical administration of a user community of the size mentioned. If you mean the authorisation details, you need to break it into the three authorisation areas:

- Web request authorisation. Meaning controlling access to different URI targets. Generally your URI targets will correspond to MVC actions, so these can live in the IoC configuration.

- Services layer authorisation. Meaning an interceptor around your middle tier beans. Again, these can live in the IoC configuration as they probably only change with new versions of your application.

- Domain object security. Meaning an interceptor around methods on your services layer, or any other domain object ACL information you require. Acegi Security provides a DAO-based implementation to obtain ACL information from a database. There is a proper caching layer provided for ACL services and an EH-CACHE implementation.

Some people might have a real need to dynamically (ie at runtime) source web request or services layer authorisation directives from a database. In this case you can easily implement the ObjectDefinitionSource interface and do so. Just remember to put some caching logic into the implementation so the database isn't hit too hard. However, in almost all cases this is unnecessary.