> This happens when you look at the system from both sides: the Tool > Designer will see "groups of pages needing different levels of > protection", while the Application Designer or Admin will see "groups of > people with common access". This is why names are so dangerous.
Adding to what Santiago said... I agree "Group" is an ambiguous term and seems to have always been one of the biggest issues with the way Turbine security is set up. Also, you would not believe the number of times Turbine security was *supposed* to be re-designed. There were issues from conflicting opinions on how it should be implemented all the way down to the dreaded entity naming issues. The attempts that did get under way always ended prematurely with the primary contributors having to stop due to more pressing issues. It's been awhile since I have looked at the Turbine list, so all these things may have been/will be in addressed Turbine 3.x. Just some turbine security history for ya' ;) -scott > -----Original Message----- > From: Santiago Gala [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 12, 2003 11:44 AM > To: Jetspeed Users List > Subject: Re: PSML user group role : how to use Group? > > Gabriel Santonja wrote: > >>Hi Gabriel, > > > > Hi Scott, > > > > > >>This is because the default Jetspeed security implementation is still > >>attached at the hip to turbine. So, there are some remnants of that > >>association that still remain. > > > > > > If I uderstand the groups are used only to keep some Compatibility > > with Turbine?. > > > > Groups can be "morphed" into Realms or Virtual Hosts in the future > evolution of Jetspeed, as HTTP has a Security model not completely > compatible with java.security.* or JAAS (J2EE security). (This is just a > hypothesis, don't trust on it). > > > > >>The default is using the underlying turbine security. > > > > > >>I may not have understood this question, but there is no association > >>between the two. > > > > > > Excuse me the question was truncate: > > Why the groups doesn't <works> like the groups in the tomcat > > administration tools?. > > > > group in turbine means "a group of resources/pages" nor "a group of > users". It is more like a HTTP Realm. > > This happens when you look at the system from both sides: the Tool > Designer will see "groups of pages needing different levels of > protection", while the Application Designer or Admin will see "groups of > people with common access". This is why names are so dangerous. > > Actually the tomcat groups can be mapped as turbine roles, i.e. sets of > permissions. Users with the same role in the same turbine group will > have the same permissions. There is no way in Turbine-2 to express > "groups of users", but you can do the trick if you use a different ROLE > for each GROUP_OF_USERS, since changing the permissions of the ROLE will > affect all the users having it. Again a user BELONGING to several roles > will have the sum of the permissions on those roles. > > *And* what you would call ROLE in tomcat is really PERMISSION in > turbine. Since the only possible authorization in tomcat comes from the > isUserInRole() call. (So you can think of permission VIEW in Jetspeed as > role pageviewer in tomcat, etc.) > > Funny, isn't it? Don't play much with it, as I guess Jetspeed-2 Security > will have to change a lot to be J2EE compatible in the near future. > > > Yes there is no association between the two. The notion of group is > > diff�rent between tomcat and jetspeed and that's surprising. > > > > Given the response I got when I asked for java.security.Principal, it is > not that surprising: > Request: GET /java.security.Principal > http://www.mail-archive.com/[EMAIL PROTECTED]/msg05244.html > Response: (404 NOT_AVAILABLE_HERE) > http://www.mail-archive.com/[EMAIL PROTECTED]/msg05250.html > > ;-) (Notice the response comes from the main developer in Turbine-2, for > those who don't know) > > > thank you for your response. > > I hope I clarify. > > Regards, > Santiago > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
