Steve wrote:
I'm considering using Acegi for a project, but I'd like to find out a bit more. Can you give me an idea of how Acegi fits into the J2EE picture with regard to JAAS? The client requires J2EE "compliance" for all new applications. That doesn't mean we have to use J2EE APIs for everything, it just means we have to have a coherent story where we deviate. My (brief) impression of JAAS is that it's got some problems, and is not all that well understood or utilized in the developer community.
For example, I'm working with JRun at the moment. They make a pass at using JAAS, but they use their own framework for the authorization piece. No explanation as to why. There are other reasons why we don't want to use it, but one of them is that we would like to stay within the J2EE API if possible and advisable. So my question to you is, in creating Acegi, did you consider how it fits in with JAAS, where it deviates and why. Thanks!
Hi Steve
Remember, I'm biased, but here's my summary:
JAAS (generally)
+ It's a standard in Java land
+ Great classloader-level authorization capabilities (ideal for web browsers)
- Configuration is ugly (.policy files) and inconsistent (compare JBoss with JRun with Jetty)
- Still need to trust the authors of the .policy files
- Still need to trust the authors of the login modules
- No container portability
- Few containers actually implement JAAS-based authorization
Acegi Security (compared with JAAS)
+ Currently no real other security option for Spring (at least in open source)
+ Tight Spring integration saves you time and simplifies configuration (compared with .policy files anyway)
+ Complete container portability (by simply copying the WAR)
+ Reimplements authentication and authorization from scratch, making it easy to customise or extend
+ Provides the same key JAAS/servlet capabilities of pluggable authentication and web request URI security
+ Better web request URI security than servlet spec due to pluggable modules
+ Provides additional capabilities needed for enterprise apps like method interception, single sign on, and Swing clients
+ Can still wrap JAAS authentication modules if desired
- Does not offer authorization at the classloader level
- Is not a Java standard
So it really boils down to whether the two "disadvantages" of Acegi Security are worth it. Being a Java standard is a policy (non-technical) issue. In reality you're pretty safe using Acegi Security, as it's the de facto Spring standard, has been peer reviewed, has good test coverage, been around a while, has a supportive community etc. So the only true technical debate is the classloader-level security. Before getting too carried away, here are issues offsetting classloader-level security offered by JAAS:
- Few containers will let you leverage JAAS classloader-level authorization anyway (as you mentioned with JRun)
- It's difficult to configure compared with Acegi Security method interception (open up a policy file and take a look)
- Unlike web applets, enterprise applications (ie Spring bread and butter) are trusted and so are their developers
- You still need to trust the policy file, web.xml and login module developers, so it's not 100% safety using classloader authorization anyway
- Most enterprises have more serious risks to deal with than classloaders running untrusted enterprise code (firewalls, viruses, audit, backup, testing, redundancy, delivery etc etc etc)
The above is why I didn't base Acegi Security on JAAS and I don't believe people using Spring are really disadvantaged by not having JAAS classloader-level authorization services. Having said that, I would welcome it if someone contributes such capabilities to Acegi Security.
HTH Ben
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Acegisecurity-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
