While, in my never-ending arrogance (heh), I find the current Digi security system quite robust and extensible, as well as, well-integrated with the main JAAS principles, it is not enough.\r
\r
There are two things that were purposefully disregarded, in the rush of providing the solution to those who needed it, and that should be revisited. \r
\r
First is the Security API from the JSR-168. As much as I am sceptical about the version 1.0 of any specification, JSR-168, in particular (arrogance, again), for things like the security it may be beneficial to, at least, consider being compliant. Well, if that does not harm, more valuable assets.\r
\r
Second is the fact that if anything, security is the component/service that would benefit from being as pluggable, extensible and de-coupled as possible. While, it would be hard to clain that the current implementation is rigid, Digi Security is still using only the plain-old approach of coding to interfaces. There is space for more flexibility, widely known as the introduction of the Dependency Injection techniques. This could make things more de-coupled, with less code. \r
\r
From a quick glance and research, it seems that Acegi Security System for Spring is a good example of employing DI techniques for a Security System implementation.\r
\r
As I do not have time for all these, right now, I am posting this as a note (reminder) to myself here. Somebody thinking about improving his/her own security system may, also, find this information useful.