WebSphere Portal v6 Roles

 

+
Search Tips   |   Advanced Search

 

Access control is based on roles, which combine a set of allowed actions with specific WebSphere Portal resources.

The set of allowed actions is called a role type. For example, the role type Editor contains allowed actions like...

  • View resources
  • Modify resources
  • Create new resources

...with no ability to delete.

Roles are denoted as...

RoleType@Resource

For example, the Editor role type combined with the Market News Page resource results in the role...

Editor@Market News Page

By default, this role would also allow Editor-style access on descendant resources underneath the Market News Page through role inheritance.

Roles are organized in a hierarchy. Each role type contains all allowed actions that are contained in the role types directly beneath it in the hierarchy. For example, Privileged Users and Editors can do everything that Users can do. Managers can do everything that Editors and Users can do.

 

Role Types

Role Type Allowed Actions
Administrator Unrestricted access on resources.

Includes...

  • Creating
  • Configuring
  • Deleting

Administrators also grant access control rights to other users

Security Administrator Create role assignments on resources.

The user is allowed to delegate a subset of their privileges on a resource to other people according to the Delegated Administration Policy.

For example, a user who is assigned...

  • Security Administrator
  • Editor

...on a resource can assign the Editor role to other people provided he has Delegator role on those people.

Having the Security Administrator role on a resource alone does not give view or edit access to the resource.

Delegator Assigning the Delegator role to users and groups allows roles to be granted to them.

The set of roles that can be granted to those users and groups is defined through the role types...

  • Security Administrator
  • Administrator

For example a user has...

  • Delegator role on the SalesTeam user group
  • No Delegator role on the Managers user group

This user can grant roles only to the SalesTeam or individual members of the SalesTeam user group but not to the Managers user group.

Having the Delegator role on a resource does not give direct access to the resource. The purpose of the Delegator role type is to allow the granting of roles to users or groups, so assigning Delegator role on resources or resource types that are not users or user groups will not grant those users additional privileges.

Having the Delegator role on other resources, such as specific portlets, is not useful.

Manager Create, configure, and delete resources used by multiple users.
Editor Create, configure resources used by multiple users.
Contributor View portal content and create new resources.

Does not include the permission to edit resources. For example, a user is granted the Contributor role on the Template Category Teamspaces. The user will not be able to modify the category itself but can create new templates in this category.

This role type is only available for the following resources:

Privileged user
  • View portal content
  • Customize portlets and pages
  • Create new private pages.
User View portal content. For example, viewing a specific page.
No role assigned Cannot interact with resource.

 

Inheritance

WebSphere Portal resources are part of a hierarchy. By default, each resource in the hierarchy inherits the role assignments of its parent resource. When you assign a group to a role on a parent resource, the group automatically acquires that same set of allowed actions for all child resources.

For example, suppose that a user, Mary, is a member of the Sales group. We can give her Editor access to the Market News Page and all pages underneath this page by granting the role...

Editor@Market News Page

...to the Sales group. All members of the Sales group will also inherit the Editor role type on all pages that are beneath the Market News page in the resource hierarchy.

Inheritance through the resource hierarchy can be blocked at any level to provide more granular access control.

 

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

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

Administrator@USA Market News Page

...which cannot be blocked with an inheritance or a propagation block set through...

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

 

Application Roles

With WebSphere Portal Version 6.0 or later, there is a higher level concept of roles called application roles. Application roles are identified by a unique name and can contain an arbitrary set of other portal roles. An example is...

Editor@Market News page

...and...

Editor@Market News portlet

...This makes it possible to use application roles to bundle cohesive allowed actions, simplifying access control administration. Application roles with the same name in different database domains are correlated, so it is possible to aggregate roles from different database domains within one application role.

Access control portlets are not set up to handle application roles, but application roles can be handled through the XML configuration interface.

 

Role Assignments

Roles are assigned to users and groups that are contained in the user registry. Roles can be assigned by someone with the necessary authorization, such as the portal administrator, in any of three ways:

  • Explicitly assigned to an individual user

  • Implicitly assigned through group membership. If a group has a role, all members of the group automatically acquire the role. Nested groups (groups that are members of another group) inherit role assignments from their parent groups.

  • Inherited through a role assignment on a parent resource. By default, roles on a resource automatically apply to all children of that resource unless role blocks are used (see Inheritance).

Users and groups can have multiple roles on the same resource. For example, a user might have both the Editor and Manager roles on a particular page. One of these roles might be inherited through the resource hierarchy and the other might be explicitly assigned.

Assign roles to individual users only in exceptional cases. Assigning roles to user groups and managing effective user privileges by adding to or removing users from those groups reduces the number of role mappings and simplifies maintenance.

 

Ownership

Each resource can have a dedicated owner. The resource owner can be a single user or a single user group. When a user creates a new resource, such as a page, the user automatically becomes the initial owner of that resource. For non-private resources, which are resources accessible by those people having been granted access to the resource, ownership provides the same set of allowed actions as the Manager role type. For private resources, which are resources accessible only by the owner of the resource, ownership provides the same set of allowed actions as the Privileged User role type plus the allowance to delete the resource. So in the case of both non-private and private resources, these allowed actions include the ability to delete the resource.Private resources can only be owned by users, not by user groups. It is not possible to define roles on private resources, and resource ownership cannot be inherited.

Use the XML configuration interface or the Resource Permissions portlet to change the owner of a resource.

 

Private pages

A private page can be accessed only by its owner. Privileged Users (users assigned a role of type Privileged User) can explicitly create new private pages that are accessible only by themselves. Additionally, a Privileged User on a non-private page can personalize the page and create new private pages underneath it. Customizing a non-private page usually creates a private copy of the corresponding non-private page. Any changes that a Privileged User makes to a non-private page are not accessible by other users.

Private pages cannot be controlled by an external security manager. Access control for private pages is always internally controlled by WebSphere Portal.

 

Traversal support

Users with role assignments on resources of type Page or URL Mapping do get the implicit permission to navigate to those resources. These users are guaranteed the ability to navigate through all parent resources of those resources. Users only see the title of those resources, while the corresponding resource content (for example the portlets on the page) remains inaccessible unless those users have further role assignments granting them normal access to those resources.

 

Related information