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 > - 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. 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. 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 David -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
