portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <sg...@hisitech.com>
Subject Security Changes
Date Mon, 14 Jan 2002 18:42:27 GMT
I'm working on a reasonable security implementation, and I see more 
changes that I anticipated. I wanted to request feed back to see if you 
agree that I commit.

Jetspeed security model is lacking, specially with regards to 
group/roles. Turbine security model implies that all security checks 
*must* be done in the context of a group, else they are meaningless (a 
user has a role *in a group*). On the other hand, to have jetspeed 
managing multiple groups is tempting and we have already partial support 
in this area.

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
------user
---------turbine
---------admin
------lurker
---------anon
---------...
------admin
---------admin
--- other groups...
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.

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.

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

With this proposal, PSML under /group/XXX will require view permissions 
*in group XXX*. Under /group/XXX/roleYYY it will require role YYY in 
group XXX. Under /group/XXX/role/user/user/YYY it will require that the 
user is YYY, and s/he has view permission in group XXX.

In the default distribution, there would be the global group (current 
root), with a user role, a admin role and a lurker role. The lurker role 
will contain the anon psml.

lurker role will only have view permission in default group.

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.

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.

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? ;)



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


Mime
View raw message