David Sean Taylor wrote: >Santiago, > > > >>>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. >>> >>> >>> >>> >>This leaves us with a "one portal, one set of permissions" >>model, that >>has a lot of problems. >> >>While I agree that Turbine's model is confusing (group should >>be really >>called "Realm", after HTTP Realm), I think we need such a concept. >> >> > >I agree that this concept is very important in large portal sites. >The requirements of smaller portals may be simply one realm / security >policy per portal. >I would like to support the concept of realms, but not to overload the >API with this concept. >Perhaps we can find another way to configure the context of the realm. >I need to give this some thought... > > > >>We have no way to split a portal into areas for which users >>having the >>same role do have different permissions, much in the way that you can >>erase a file in your home directory, but *not* in a different user's >>home. (You have the user role in both cases, but the resources have >>different "labels", those owned by jane, and those owned by james. >> >>This means the security manager will be forced to use hundreds of >>different roles, like "salesadmin", and mark PSMLs like >>role="salesadmin" if you need to have different pages managed by >>different people. Do you have an idea on how to implement this? >> >> >> >>> >>> >>> >>> > > > >>What remains to be committed is: >> >>(I'll call turbine's groups realms, since it is much more >>close to how >>they behave.) >> >>- Secure portletset (PSML) access. >> >> > >You can do this now with the registry access controller. >Put a security-ref on the the top-level <portlets> collection in a psml >file. >See security.xreg and the psml used in the unit tests > > I will be looking into this ASAP.
> > >>- Ensure that every request is executed in the context of a >>realm, i.e. >>that we can have different permissions for different pages. >>- Change the admin portlets so that users are given roles in >>different >>realms, not just in the "Jetspeed" one. >> >> >>Since I see the strength of your arguments, and I don't want to be >>stopping other work, I thing we can do what follows: >> >>- Tag and open a branch before you start the merge. >>- Let me use this branch to have a working implementation of >>the older >>model. >>- Have it migrated to the new model, and maybe mixed, if it is >>considered relevant. >> >> > >I prefer that we all work off the same cvs head in a common goal. >Wrt Realms, you have a valid argument, and as stated above, there are >standards (HTTP, Java) that support your argument. > As you may know, I am supporting a derivative product which uses jetspeed. We need to deliver a portal with this requirements now. While I prefer to work together in HEAD, I am in the middle of testing and integration of a new release. I could do two things: 1- freeze my jetspeed release date and keep private changes (say, on Jetspeed 20020625 or whatever) until the moment we can resynchronize versions. 2- open a branch and keep having changes that can be mixed together gradually. From my previous experience, 2 is much better than one. So, even if we work together, I need this branch to keep the current security operative while changes are merged. Don't think "fork" when I propose a branch. Rather, think about better merging abilities later on. In a sense, it is reversing our current roles: instead of you two working on a branch and me touching HEAD, it will be the other way round. But I don't think it would be a long term branch. >Lets try to find something we can agree upon first. Give us a little >time to find something that meets everyones needs >Im just not convinced that the best way is to change the API to always >receive a realm as a parameter to all the API calls. > I don't have clear views on how to achieve this. I have been thinking about having a /group/XXX parameter (optional means /group/global -> whatever name, global is hardcoded in current Turbine model and looks a good name), and having the psml directory/db structure carrying a "group" hierarchy. A PSML would be checked in the realm associated to the group it is under. A (hypothetical) PortletSet-imported-fragment could have a security reference stating the group/realm under which checks would be done, useful for "read-only", or imported content. (I use group, but it could be another name. Think "company" or "division".) The only conceptual problems remaining to be solved are: - Which page will be shown after login (i.e. is there a "primary"/"default" group/realm? ) - After a user registers, which groups/realms does she belong to? (For our scenarios, users will register in a "global" group (like now), and the admin would grant new group permissions. >Please review the current interfaces and make suggestions as to how you >see realms in the api. >Also review the registry.xreg format. >I will start doing some research on realms. >Its great that you are participating in the proposal now, and Im happy >to modify the proposal to meet your design > > I have been too overloaded :-( . I concentrated my current efforts in getting rid of my very old patches pending (I still have some, which I'm not sure if are still needed/relevant). Now I have got rid of most "ready" code, I'm working to get into synchrony. I still have not found time to review extensively the proposal and code in 1.4. The reason why I proposed a branch is two-fold: - non blocking behaviour WRT your efforts. - don't throwing away my (slow,painful) implementation I agree that your proposal looks cleaner than the current model, and decouples us from the Turbine security model, which I don't like very much. I'm not sure the public APIs need to be changed. It would be a matter of knowing which is the relevant group for each checkPermission() call, which could be a property of portletsets (both top portletsets, for the pages, and "imported" portletsets, for shared content. I'm still thinking about the merge, so I don't want to venture ways to do it yet. The whole idea of the branch is to enable more thinking on how to do it. I hope we are able to put Jetspeed in better shape soon :-) >David > > > >-- >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]>
