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 Changes
Date Tue, 15 Jan 2002 08:11:24 GMT
> 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...

This will really change the psml managers

> 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


> 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

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

Yes! I would really like to see the customizer working on all PSML
If I can help there let me know

> 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 think we are finally getting security to better fit a portal.
My vote is "Do it!" +1

> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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