Jeanfrancois Arcand wrote: > Costin Manolache wrote: > >>Wouldn't be better to just standardize on JAAS for authentication >>and stop using our own private interfaces ? >>AFAIK JAAS is included in JDK1.3+ - and available to older VMs. >> > I agree on JAAS too for Authentication if it is available for the > majority of open source VM I will first refactor the interface, commit > them and then start working on JAAS if everybody agree.
AFAIK it is available- haven't checked it. Even if it isn't - I hope there is still a standalone download that can be used with any VM ( like JDK1.2 ). >>The only problem is getUserRoles(), which is not supported very well >>by JAAS. >> >>I'm fine with implementing them as valves - I'm not sure the interface >>you're proposing is the best choice. >> > Why? To be able to authorize properly, we need at least the Principal > and the resource (+ the SecurityConstraint from the web.xml). We already have _far_ too many interfaces ( and base classes, abstract classes, and so on ). Do you expect people to implement this new interface ( instead of JAAS ) ? As long as a clear standard interface exists ( JAAS ) and we know that it can be used ( there is a JAAS plugin for tomcat ) - I see no reason to create yet another interface. Are you going to port LDAP, JAAS, database plugins as well as UserDatabase to the new interface ? Just refactoring the interface and increasing the mess with 33% is not good. ( 33% - because we already have 2 interfaces for this, Realm and UserDatabase ) >>I would be +1 on using the Policy for authorization - my understanding is >>that it _does_not_ require the security manager to be enabled. >> > I'm not sure about that. My understanding was that when you call > AccessController.checkPermission (that require the Security Manager to > be turned on), the class will delegate the call to Policy.implies > implementation. If we don't have the security manager enabled, that > means we use Policy.implies only. Where did you get the information? Why would we call AccessController.checkPermission ???? The information about the access control is stored in a PolicyObject. If the base implementation requires the security manager ( and I doubt )- we can use our own implementation of Policy. We'll have to use our own anyway for performance optimizations. At least from the javadoc of Policy and my understanding of java security - I can't see any good reason why Policy would require a security manager ( except the fact that this is how most people use it today ). Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
