Gonzalo A. Diethelm wrote: (...) >>>I'm sure this is the case. In fact, I think we should seriously >>>examine JAAS to see if we would not be better off simply dropping >>>Turbine's security model and adopting JAAS. >>> >>+1 on dropping the current Turbine security model for 3.0 and above >> > >I'm not sure yet this is the wisest move; I think we have to EXAMINE >JAAS and come up with a decision. > I agree.
> >>remember JAAS is =>JDK 1.3 only. >>but +1 on dropping support for JDK < 1.3 for the new security framework, >>people that want to use the new security framework will just have >>to upgrade >>to JDK 1.3, we need to move on. >> > >I suppose setting 1.3 as a minimum would be Ok. > >>Besides people need to use a policy file for security settings. >>And I've been unable to find out how the heck I can dynamically add users >>without restarting the application, it should be possible though. >> > >I think just this one aspect would absolutely rule JAAS out. This >is exactly the reason why Turbine did not use container-based security. > >>Take a look at how they do it over in jboss land >>http://www.jboss.org/online-manual/HTML/ch09s08.html, not much doco, but >>download their source code, there was also a good JAAS framework >>in Enhydra, >>if you can dig up the enterprise source code somewhere. >> > >It looks interesting, it seems they defined a couple of generic >classes/interfaces, and their reference implementation uses JAAS >but they are NOT tied to JAAS; in fact, they say: > > These interfaces can be used to integrate any > security infrastructure. > But, ... I think they use java.security.Permission, and I'm sure they use java.security.Principal I mean thare are two issues here: - Our SecurityManager is a standard java2 SecurityManager, and then we map our classes (User->Roles->Principal) any way we want, but we have the java.security.Principal and java.security.Permission implementation built upon java2 APIs (This is jdk1.2), or we implement our own security stuff from the root. - We move to the javax.security.auth (JAAS) API for authentication, or we have our own authentication. While the second bullet is more controversial, I think that the first one is a must. If we don't use Principal and Permission from the java API we will not interoperate with J2EE environments. > >>I tried once to figure out a new security model for Turbine, but I came to >>realise that one couldn't make one that could satisfy everybody: easy to >>use/speed/flexibility/based on standards. >> > >This may be the case; at least, we have to give it a try! > I think that holding to the standard classes for Permission and Principal will not have speed impacts (unless we start a SecurityManager). We could have alternative AccessControl checks in the security service using those classes for speedier/smaller/no checks. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
