Resource blocking based on roles

Portal, V6.1

Resource blocking based on roles

Role blocks prevent inheritance through the resource hierarchy. Two kinds of role blocks exist: Inheritance and Propagation.

Role blocking
Role blocks prevent inheritance through the resource hierarchy. Two kinds of role blocks exist:

Inheritance blocks: prevent a resource from acquiring role assignments from parent resources. Visualize this as inserting a block above the resource.
Propagation blocks: prevent a resource from extending role assignments to child resources. Visualize this as inserting a block below the resource.

A role block is role type specific and tied to a specific resource. For example, an inheritance block for roles of type Editor on the Europe Market News page ensures that the Europe Market News page does not inherit any Editor role assignments from its parent resource, the Market News page. This role block does not affect inheritance of other role types. For example, Manager roles are still inherited. So, all users with the Manager@Market News Page role inherit the Manager@Europe Market News Page role unless a separate role block for the Manager role type exists.
Use the Portal Scripting Interface, the User and Group Permissions portlet or the Resource Permissions portlet to create or delete role blocks for all role types except for roles of type Administrator and Security Administrator. Role blocks for roles of type Administrator and Security Administrator can only be inserted or removed through the XML configuration interface. For example, if Mary has the Administrator@Market News Page role, and the USA Market News Page is a child of the Market News Page, Mary automatically has the Administrator@USA Market News Page role. The Administrator@USA Market News Page role cannot be blocked with an inheritance or a propagation block set through the Portal Scripting Interface, or the User and Group Permissions or Resource Permissions portlets. All role types (including the Administrator and Security Administrator roles) are automatically blocked for the following types of resources:

Private pages
Externalized resources that have an internal parent resource
Internal resources that have an externalized parent resource

For example, if access to the Market News page is controlled internally by WebSphere Portal , and the USA Market News Page is controlled externally by IBM Tivoli Access Manager for e-business, none of the roles on the Market News Page are inherited by the USA Market News Page. So, if Mary has the role Editor@Market News Page she does not automatically get the role Editor@USA Market News Page because the USA Market News page is managed externally. If both the Market News page and the USA Market News page are managed externally (or if both are managed internally), Mary inherits the role Editor@USA Market News Page unless a role block is used. In general, there is never any inheritance between two resources that differ in their externalization state. In other words, an externally protected resource never inherits from an internally protected resource and vice versa.

Parent topic
Resources