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.