See comments below > -----Original Message----- > From: Santiago Gala [mailto:[EMAIL PROTECTED]] > Sent: Monday, June 24, 2002 7:53 AM > To: Jetspeed Developers List > Subject: Re: Security_14 Branch Merge > > > David Sean Taylor wrote: > > >We (Paul and I) would like to merge the new Security_14 > branch into the > >cvs main branch. All the unit tests have passed. > >Could you please review the branch before we merge. > >We would like to merge the branch in by Tuesday June 25. > > > > > I have been looking at the branch, but I have not been able > to clarify > some important issues: > > - Is there any way to have groups of pages (realms, turbine's groups) > having different permissions for users with the same role? > Going back to > the current turbine model, can I have users having role > "admin" in the > group "production" having no "admin" rights in different groups, for > instance, in the "global" group or in a "sales" group? This > is mandatory > for any portal where there are different pages for different kinds of > users without having a mess of "productionadmin", "salesuser", > "salesadmin", etc. roles, and even more mess with the > administration of > the PSML resources and portlets.
Nope. Turbine's model is very specific. We've had so many users confused with the USER/GROUP/ROLE model, and it always leads to disagreement. So the new model is flat, no 3-way relationship. However, the Turbine security service could be easily extended to support this approach, since I still use the TURBINE tables in the default Turbine impls Just override a few checkPermission methods. The Group interface could also easily be extended to receive a Role parameter if you need such a thing. > - I can't understand how the "group" thing in the Security > proposal fits > in. I need more time to study it. Exactly, the group "thing". Its still undefinable after all this time.. Groups can be used for whatever you'd like. The new security model simply provides an optional maintenance api. The goal of the new security proposal was to decouple from Turbine security, and faciliate the needs of so many users to plug in their own security. Specifically, authorization and authentication are made pluggable and extensible. Groups are often not required by many security impls, so why force this concept upon users > - Do you feel that functional testing has gone far enough? I have not > had time to compare both implementations, let it alone to run it with > any realistic portal. We have passed all the unit tests in the system. I believe Glenn is just starting to test secure access to PSML pages. I agree, it needs more testing. I'd like to merge to the cvs head since it will get more testing there and quicker acceptance. The cvs head isn't a production release, it's where development is ongoing. > > I think merging the code while we still don't have any (positive or > negative) feed back is risky. > > I still have ongoing changes related with the current security model, > and I would like to be sure that the new model is at least as > expressive > as the previous one. > The new model is much more expressive. Take a look at the registry-based authorization. The model is no longer tied to the Turbine security model, which where, I believe, you take issue since we no longer support USER/GROUP/ROLE. Again, from the requirements of users that I worked with, and from users on the list, people found this model confusing and too specific to one application. With due respect to your ongoing changes, these changes have been ongoing for a very long time now. Could you formalise a list of what exactly it is that you are doing, and add it to the security proposal? Otherwise I request that you please step back and let others, who have more time, participate and commit in this area. Regards, David > > Regards, Santiago > > >Thanks > > > >To check out the branch: > > > >cvs co -r security_14 jakarta-jetspeed > > > >The proposal is located in the cvs at: > > > >http://cvs.apache.org/viewcvs/jakarta-jetspeed/proposals/Secu rity.txt?r >e >v=1.5&content-type=text/vnd.viewcvs-markup > > A note for people looking at the proposal: The version in head is *not* the latest. Use the cvs or the one in the checkout with the branch. > > > > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: ><mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
