portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <sg...@hisitech.com>
Subject Re: Security_14 Branch Merge
Date Mon, 24 Jun 2002 19:08:29 GMT
David Sean Taylor wrote:

>>>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 
>>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
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 
>>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 
>>- 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 
2- open a branch and keep having changes that can be mixed together 

 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 

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

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

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