Santiago,
Below is an example implementation of security that I would like to
implement. Please confirm this can be implement in the security model.
"Role" also means "Job Function"
What are the groups?
What are the Roles?
What would the directory structure look like?
Can you show a sample <portlet-entry> for store_stock_view.
Paul Spencer
Users:
store_manager - Roles assigned: clerk_1, manager_1, clerk_2
o This user can see manager_1, clerk_1, and
clerk_2 portlets ( The user is a manager
in the store, but a clerk in the warehouse)
o Desired behavior: This user can change the
appearance of portlets with manager_1 role
and view portlets with a role of manager_2,
clerk_1, clerk_2, or no role
store_clerk - Roles assigned: clerk_1
o This user should NOT be able to change
the appearance of any portlets.
o Desired behavior: This user can view
portlets with a role of clerk_1 or portlets
with no role assigned
warehouse_manager - Roles assigned: clerk_1, clerk_2, manager_2
o This user can see manager_2, clerk_2, and
clerk_1 portlets ( The use is a manager
in the warehouse, but a clerk in the store)
o Desired behavior: This user can change the
appearance of portlets with manager_2 role
and view portlets with a role of manager_1,
clerk_1, clerk_2, or no role
warehouse_clerk - Roles assigned: clerk_2
o This user should NOT be able to change
the appearance of any portlets.
o Desired behavior: This user can view
portlets with a role of clerk_2 or portlets
with no role assigned
Portlets:
general_info - Role assigned: (none)
store_stock_edit - Role assigned: manager_1
store_stock_view - Role assigned: clerk_1
warehouse_stock_edit - Role assigned: manager_2
warehouse_stock_view - Role assigned: clerk_2
Santiago Gala wrote:
> 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:[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]>
