portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Spencer <pau...@apache.org>
Subject Re: Security Changes
Date Tue, 15 Jan 2002 17:12:41 GMT
Santiago,
May be we should add :
User.. global_admin
   This user can maintain "global" portlets, i.e. modify and view.

Role.. global_viewer
   This role allows "global" portlet to be viewed.  By default, all
   user will have this role.


More comments below

Santiago Gala wrote:

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


   - role: global_viewer (can "view")
   - role: global_maintainer (can modify things in the group: "view", "customise",...)


> 
> users:
> - warehouse_clerk (role: clerk in warehouse, clerk in global)


  - warehouse_clerk (role: clerk in warehouse, global_viewer in global)


> - warehouse_manager (role: manager in warehouse, clerk in store, clerk 
> in global)


 - warehouse_manager (role: manager in warehouse, clerk in store, global_viewer 
   in global)

> - store_clerk (role: clerk in store)


  - store_clerk (role: clerk in store, global_viewer in global)

> - store_manager (role: clerk in warehouse, manager in store, clerk in 
> global)


  - store_manager (role: clerk in warehouse, manager in store, global_viewer in 
  global)

  - global_admin (role: global_maintainer 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) 

     - Role assigned: global_viewer and global_maintainer

> 
> 
> 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"/>
         <role name="zzz"/>
>   </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.


Missing group = all user have access based on roles.
Missing roles = all user have "default access"

<portlet-entry name="warehouse_stock_edit"
  <security>
    <group name="store">
         <role name="clerk"/>
    </group>
    <group name="warehouse">
         <role name="manager"/>
         <role name="clerk"/>
    </group>
  </security>
</portlet-entry>

Only user's with in the store and warehouse groups will have access to 
this portlet.  All other user will be denied.

<portlet-entry name="search"
</portlet-entry>
All users will have access with the "default permissions".  The the 
"Default permissions" need to be defined!

<portlet-entry name="current_news"
   <security>
      <permissions name="view"/>
   </security>
</portlet-entry>
All user will have view permissions.

> 
> Does it fit? I'm not sure if I'm clarifying or obscuring here ;)
> 



We also need to define a standard set of permissions:
view       - Allows portlet content to be viewed and
              added to pane
customize  - Allows portlet to be customized
minimize   - allows portlet to be minimized

maximize   - allows portlet to be maximized
remove     - allows portlet to be removed from pane

move       - allows portlet to be moved in pane


One other area the is related, it the ability to have common portlet(s) 
the are maintained in one place for a group of users.  As an example 
corporate E-mail and corporate News should be on all pages and in the 
left column.  (I am not ask this be addressed now, just be aware of this 
desired functionality while designing the security changes)

Paul Spencer


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