>
> 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
group/role/user
CREATE TABLE TURBINE_ROLE_PERMISSION
(
ROLE_ID INT NOT NULL,
PERMISSION_ID INT NOT NULL
);
> 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.
+1
wouldn't you have to change that in Turbine, or we can override it in
JetspeedSecurity?
>
> 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
resources.
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:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
