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 Changes
Date Tue, 15 Jan 2002 13:24:10 GMT
David Sean Taylor wrote:

>>I propose that each Jetspeed request carries a /group/XXX part. If this
>>part is missing, we assume that we are speaking about Turbine's "global"
>>group, which (and whose name) cannot be configured without patching
>>Turbine. or writing a new security service. This implies changes in
>>DefaultJetspeedRundata, as we need to have a getGroup() for each
>>request, and also to the URI generator classes, so that they are
>>"group-aware". The same for role (no role ==> user role).
>>All security checks for a request will be done in the relevant group. To
>>mimick this, I also propose that the Profiler *does not* have the
>>assumption that a request is *either* group/role/user/anon. I think it
>>should be group *and* role *and* user (more about anon later). So, for
>>file based psml, it would be stored as:
>>- (group/role/user ...
>>--- global
>>--- other groups...
>This will really change the psml managers
Not that much. I have changed slightly 
CastorPSMLManagerService.mapLocatorToFile(), replacing some "else" with 
sequence of ifs.

I think the DBPSML will need more changes, but they should simplify it 
(a Profile -> group/role/user/name always, where group *can* be 
"global", role *can be "user"/"lurker", user *can* be "anon", name *can* 
be default).

>>Inside every user there would be the current stuff (media,language,etc).
>>The setup is slightly more complex, but it is the only way it really
>>works for applications. Given turbine's model, a permission is
>>completely flat. This means that our permissions are like the actions in
>>java.security.permission ("view", "customise",...). Unless our logic is
>>really complex (and I don't want a access control system being complex),
>>we cannot express a lot with those permissions.
>So how would you propose changing the permissions?
>With Turbine, a permission is  related to a role, not a group/role or
Yes, but:


A user can only be related to a role *in a given group*. Furthermore, 
checks with no explicit group are done against turbine's default group, 
named "global" (not configurable). This means that a user has 
permissions depending of the group. Again if no role is given, all 
permissions are returned. So, data.getACL().hasPermission("customize") 
will return true is any of the roles of the user in the global group has 
"customize" permission. This is the reason why I want to have always a 
group and a role to qualify permissions.

Think about group to wrap any psml file requests. It gives us extra 
control on Permissions. I'm trying to understand the previous email from 
Paul, and to give him an answer in terms of these abstractions. I hope 
this will help.

>>Also, to simplify the logic, I have tested having always a "real" user.
>>This implied adding a new AccessController action (mostly copy from the
>>turbine one), and getAnonymousUser() returning a real user called anon.
>>Thus, the permissions of anonymous users are configured exactly the same
>>than permissions of logged in users. Furthermore, the program logic does
>>not need to distinguish "hasLoggedIn()" anymore for security checks,
>>which is good.
>wouldn't you have to change that in Turbine, or we can override it in
I have tested overriding getAnonymousUser() in JetspeedDBSecurityService 
to return getUser("anon"), which I inserted in the DB. I needed to 
change the definition of the AccessController action, to ensure that 
hasLoggedIn() is not used as criteria to build acl. I also changed it to 
use User.setTemp, instead of Session.putValue.

hasLoggedIn() still works, but we always have a ACL, irrespective to the 
fact that the "anon" user has logged in or not.

>>The problem becomes greater when PSML access must be checked. For
>>instance, if I point the browser to /user/admin after having logged in
>>as turbine, I can see the PSML from admin, because I have view
>>permission. Furthermore, I can customise PSML from other users. If the
>>customizer was "group-aware", any user could customize the PSML in this
>Yes! I would really like to see the customizer working on all PSML
>If I can help there let me know
I think the key for that is that the customiser works always using the 
current Profile as a source of information. I have not looked into the 
details, but it should work. The current Profile has .save methods, ... 
I bet you need that this is sorted out for the DBPSML implementation to 
work also.

>>Administrators could add different groups (say for different
>>organizational *roles* in the company, and here I show why turbine's
>>names are confusing), have a user as admin role for each group
>>(different ones, by the way), and have top.vm showing URIs for the
>>groups the user is in / the roles s/he has in them.
>Excellent (im beggining to sound like an american. oh yeah, I am one)
>>I have it partially implemented. I'm missing several things:
>>- clean more code of "the old ways"...
>>- make rundata and contentURIs group/role/user aware.
>>- make the customizer Profile-aware, so that it customizes and saves the
>>document associated with the current profile.
>>- test more.
>>- test much more.
>- rewrite the profiler, psml managers (both db and file) to store to your
>new 'layout'
>I can help there, been there many times....
>>OK. I want some feed back on these changes before I keep moving. Do you
>>like the idea? does it break things? Would you pay me a beer? ;)
>I will buy you all the beer I can drink (I mean you can drink)
>When are you coming to SF again?
I don't know. I hope soon. I like being there.

>I think we are finally getting security to better fit a portal.
>My vote is "Do it!" +1
I will try to answer Paul's questions, which will show holes in my 
reasoning, first ;)

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