Dan Diephouse wrote: > JAAS: Jaas is a complex beast, and from what I can tell does not work > well in the context of Turbine. I have found a couple resources on it > and applying it to web applications. They aren't neccessarily all > that relavent, but some people might want to see them.
It is true, but sometimes (for instance in J2EE environments) you will be forced to use it, and it should be already there, > > 1) javageeks.com did an article on implementing a custom Policy, which > is a starting point on how to do a custom (database, xml, etc) > implementation for the policy instead of a filebased policy file. > While it isn't directly talking about JAAS it certainly applies. > http://www.javageeks.com/Papers/JavaPolicy/JavaPolicy.pdf > > 2) On a more random note Struts had a small discussion about it once > upon a time. > http://www.mail-archive.com/struts-user%40jakarta.apache.org/msg14163.html > > > Correct me if I'm wrong on my next couple conclusions on why I think a > JAAS based security is bad: > 1) You have to overide the security policy for the whole VM. This > means that all your applications under the VM have to follow the JAAS > security policy. I don't think you can have multiple security > policies for different webapps. Not always. This situation happens if you are in control of everything surrounding you servlet engine. A lot of people is in a situation in which J2EE is there, and we already have a policy and/or authentication setup. What we want to do now is to have Turbine's system *compatible* with it. What I think would be a reasonable compromise (but maybe other people does not think this way) is: - use java.security.Permission/PermissionCollection classes for the implementation of Permissions. (They are relatively independent of the rest of the framework, everything is self contained except for the checkGuard() method, which checks for the SecurityManager.) Furthermore, any java2 implementation loads them, regardless of the SecurityManager is active or not. - implement java.security.Principal in whatever user abstraction we are using. - Leave the service pluggable. (A centralized AccessController which can be plugged, with interfaces functionally similar to java.security.AccessController) Then, if a default implementation is done (similar to what we have today), it will work similar to what we have today. If anybody needs a JAAS implementation, at least the Permission classes are already in place (thus the checks in user code are the same, if we wrap java.security.AccessController in our org.apache.turbine....security.AccessController class) All classes are there in jdk1.2* (except Subject, that requires JAAS, thus jdk1.3+extension or jdk1.4) > > 2) Not to mention its a huge pain in the arse to implement. Databases > are cake, policies are not. Look at the javageeks.com impelementation. This is not turbine's work. A policy will come in a very near future with jdk1.4 (JAAS is there). If this policy implementation is not enough, people around Tomcat-land or EJB-land will be the ones to implement it. In fact, I think they already have the -security flag to start a SecurityManager. We will just configure it and use it. Don't forget that J2EE requires this kind of security, and the Servlet API is part of J2EE. Our work is: - Login the user (this could be done through the Servlet Container, using the .getUserPrincipal() in turbine to get this info ) - Setup the > > 3) Even if #1 and #2 weren't that bad, not only do we need to > implement our security policy, but also our policy negates the vm's > current policy. So people's policy file is overridden > > There is a Policy.setPolicy() method, but I can't figure out if that > sets the policy for the whole vm, or just for the current thread. > That could be an option. > Now, in light of those observations - I think it would be very cool if > we could optionally use JAAS for login authentication. Although I > have no idea how to begin doing that. > For more information there is of course the sun website: > http://java.sun.com/products/jaas/ The main obstacle to being able to do this is that our model does not cleanly align with java2 security. If we: - used java.security.Permission subclasses (extending BasicPermission and/or reusing SocketPermission, FIlePermission, etc.) - implemented java.security.Principal - had a similar API that what java.security.AccessController has , in our current implementation, it would be a snap to rewrite our AccessController to wrap the java one, and to rewrite the Security service Authentication "part" to use JAAS login. The application security checks would not need modification. As an example of this approach, see the Tomcat-4 HEAD cvs source, in particular catalina/src/share/org/apache/naming/JndiPermission.java as a custom permission, and the Realm classes to see how they allow "classic" authentication as well as a toy/prototype JAASRealm. I'm just trying to have turbine prepare for the future. In my own interest, of course. If a Portlet API is standardized I'm quite sure it will require the standard java security mechanisms. While current Jetspeed can do with a Turbine-2 security implementation, next iteration will not, unless it is reasonably easy to write a JAAS compliant security service within Turbine. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
