> I don't get what the session interface is for? Session management: a session holds zero or one (authenticated) user.
> > I'm not familiar with this "implies" concept. > an example > > HaveRootPermission.implies -> HaveReadWriteAccessPermission implies -> > HaveReadPermission implies .... Ok, a hierarchy of permissions. Of course, this concept could also be applied to roles, right? > > 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. > 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. > 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! > - Kasper -- Gonzalo A. Diethelm [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
