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 17:11:21 GMT

David Sean Taylor wrote:

>See comments below
>>-----Original Message-----
>>From: Santiago Gala [mailto:sgala@hisitech.com] 
>>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.
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.

>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
>>- 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
I agree. For what I have seen, it looks that the new API is much cleaner 
and makes less assumptions. I'm thinking how portal resources could be 
"labelled" so that permissions are checked against this label. This 
requires a kind of three-way relationship between 
user-role-realm/domain, so that user administration is cleaner. This is 
specially true for integrator portals, where a company sets up a portal 
with users from different companies, and part of the contents are shared 
while other contents are private to each "realm/domain/group". This 
applies, for instance,  to corporate portals where users of different 
divisions do have different pages with different sets of permissions.

Using different roles to model this situation leads to an administrative 
nightmare WRT roles and permissions.

>Specifically, authorization and authentication are made pluggable and
>Groups are often not required by many security impls, so why force this
>concept upon users

I agree that the naming of Turbine groups is very unfortunate, but we 
still need something that *every* security implementation has:

- HTTP has Realms (a set of resources (pages) with common security policies)
- The servlet spec has the concept of a Webapp as the security realm (or 
- Java has CodeBase ( " " )

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?

>>- 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
>>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 
>>as the previous one.
>The new model is much more expressive. Take a look at the registry-based
>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
I agree with the confusing terminology.

>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.
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.
- 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 
- Have it migrated to the new model, and maybe mixed, if it is 
considered relevant.

What do you think?



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