Paul Spencer wrote:
> 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?
In turbine's model, a group is a set of resources for which separate
access control rules exist. I think a group is a set of PSML documents
that share control rules.
>
> What are the Roles?
A role is a set of permissions in a given group.
>
> What would the directory structure look like?
> Can you show a sample <portlet-entry> for store_stock_view.
This is the fuzziest area I have now. I think security elements in
registries should cover all group, role, user attributes.
Portlets should be accessed from different groups, maybe with different
access rules. I'm thinking that the profile/PSML resource gives the
group context for acccess to portlets. So, if a portlet specifies group
"warehouse" access, "view" permissions are checked against this group,
if a portlet specifies group "store" role "manager", only managers in
store can see it. Otherwise, it the portlet does not specify group,
checks will be made in the group of the PSML resource in which they are
contained.
In a sense, groups are like codebases in java security, and a PSML is
like a class we load in this context. Also a portlet. It will have its
own access restrictions, checked in the context of the PSML (read
portletset) loading it.
>
>
> 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
You have users and portlets for two different entities: store and
warehouse. If I see it correcly, I would set up two groups, store and
warehouse. For each groups, roles would be assigned as follows:
store:
- role: clerk (can not modify anything, just "view" )
- role: manager (can modify things in the group: "view", "customise", ...)
warehouse:
- role: clerk (can not modify anything, just "view" )
- role: manager (can modify things in the group: "view", "customise",...)
global:
- role: clerk (can "view")
- role:
users:
- warehouse_clerk (role: clerk in warehouse, clerk in global)
- warehouse_manager (role: manager in warehouse, clerk in store, clerk
in global)
- store_clerk (role: clerk in store)
- store_manager (role: clerk in warehouse, manager in store, clerk in
global)
WRT PSML, can users customise their PSML or not? Is customisation of the
different PSMLs done by a external admin? Are users allowed to remove or
add portlets?
>
> Portlets:
> general_info - Role assigned: (none)
no security, so even store_clerk, with no permissions in global can see
it. I'm not completely satisfied with doing this way.
>
> store_stock_edit - Role assigned: manager_1
role="manager"
>
> store_stock_view - Role assigned: clerk_1
role="clerk"
>
> warehouse_stock_edit - Role assigned: manager_2
role="manager"
>
> warehouse_stock_view - Role assigned: clerk_2
role="clerk"
>
But this would mean store_clerk would not have any global permissions.
This is the reason why I'm not completely satisfied. Still, it looks
much better than current implementation.
The portlets should have something like
<security>
<group name="xxx">
<role name="yyy"/>
</group>
<group name="global">
<...>
</glroup>
</security>
to allow for proper expression of permissions. Missing group should
mean "global", missing role or user imply one by one permission checks
in given group (global or otherwise).
I think we could also need <permission name="arbitraryName"/> for
enabling specific permissions needed for portlet access.
Does it fit? I'm not sure if I'm clarifying or obscuring here ;)
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
