portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <sg...@hisitech.com>
Subject Re: Security Changes
Date Tue, 15 Jan 2002 15:56:18 GMT
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:jetspeed-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>


Mime
View raw message