portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Sean Taylor" <da...@bluesunrise.com>
Subject RE: Security_14 Branch Merge
Date Mon, 24 Jun 2002 17:46:34 GMT

> >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
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 


To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>

View raw message