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.
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. 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. 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/ I am no means an expert, but I thought I'd share my conclusions. - Dan Diephouse -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
