Roles
In WebSphere Portal V5.0, access control is based on roles. A role combines a set of permissions with a specific WebSphere Portal resource. This set of permissions is called a role type. Roles are denoted as RoleType@Resource. For example, the Editor role type combined with the Market News Page results in the role Editor@Market News Page.
Make sure that there is always at least one user with the Administrator@Portal role. If no user has this role, the portal will be inoperable.
The following table describes WebSphere Portal role types.
| Role Type | Permissions |
|---|---|
| Administrator | Unrestricted access on resources. This includes creating, configuring, and deleting resources. Administrators can also change the access control configuration. |
| Security Administrator | Create and deleting role assignments on resources. The Security Administrator role on a resource allows you to assign principals for which you have at least the Delegator role type to roles on that resource, provided that you also have the necessary role type on that resource. For example, in order to assign a principal to a role on a resource, have at least the Delegator@Principal + Security_Administrator@Resource + RoleType@Resource roles. No access to the resource. |
| Delegator | Assigning principals (users and groups) to roles on resources for which you have at least the Security Administrator role and other appropriate role types. For example, in order to assign a principal to a role on a resource, you must have at least the Delegator@Principal + Security_Administrator@Resource + RoleType@Resource roles. The Delegator role should be assigned on principals or virtual resources. Having the Delegator role on other resources, such as specific portlets, is not useful. No access to the resource. |
| Manager | Create new resources and configuring and deleting existing resources that are used by multiple users. |
| Editor | Create new resources and configuring existing resources that are used by multiple users. |
| Privileged user | Viewing portal content, customizing portlets and pages, and creating new private pages. |
| User | Viewing portal content. For example, viewing a specific page. |
| No role assigned | Cannot interact with resource. |
Role hierarchy
As the following figure illustrates, roles are organized in a hierarchy. Each role type contains all permissions 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.
Users and User Groups
Roles are assigned to users and groups that are contained in the user registry. Roles can be assigned in any of three ways:
- Explicitly assigned by someone with the necessary authorization, such as the portal administrator.
- 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. Roles on a resource automatically apply to all children of that resource by default.
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 by a portal administrator.
Assign roles to individual users only in exceptional cases. Assigning roles to groups reduces the number of role mappings and simplifies maintenance.
Inheritance
WebSphere Portal resources are part of a hierarchy. By default, each resource in the hierarchy inherits the role assignments of its parent resource. This inheritance reduces the administration overhead. When you assign a group to a role on a parent resource, the group automatically acquires that same role for all child resources.
For example, suppose that a user, Mary, is a member of the Sales group. You can give Mary Editor access to the Market News Page and all pages underneath this page by granting the Editor@Market News Page role to the Sales group. All members of the Sales group implicitly acquire the Editor@Market News page role. 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. So, members of the Sales group automatically inherit the role Editor@USA Market News Page.
Inheritance through the resource hierarchy can be blocked at any level to provide more granular access control.
Inheritance behavior changes when resources are externalized. If a resource is externalized, and its parent resource remains internalized, then the external resource no longer inherits role assignments from the internalized parent resource. Externalized resources can only:
- Inherit role assignments from other external resources
- Propagate role assignments to other external resources
Internalized resources cannot inherit role assignments from or propagate role assignments to externalized resources.
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 distributing role assignments to child resources. Visualize this as inserting a block below the resource.
A role block is tied to a specific resource and a specific role type. For example, an inheritance block on the Editor role type and 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.
Role blocks cannot be used to prevent inheritance of Administrator and Security Administrator role types. 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.
All role types (including the Administrator and Security Adminstrator 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 the Market News page is controlled internally by WebSphere Portal access control, and the USA Market News Page is controlled externally by 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 Marker News page unless a role block is used.
Ownership
Each resource can have a single dedicated owner. The resource owner can be a user or a group. When a user creates a new resource, such as a page, the user automatically becomes the owner of that resource. For public resources, ownership provides the same set of permissions as the Manager role type. For private resources, ownership provides the same set of permissions as the Privileged User role type plus permission to delete the resource. These permissions include the ability to delete the resource.
Resource ownership cannot be inherited. Use the 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 on a public page can personalize the page and create new private pages underneath it. Customizing a public page usually creates a private copy of the corresponding public page. Any changes that a Privileged User makes to a public page are not accessible to 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 roles on resources that exist towards the bottom of the
resource hierarchy can always navigate
to these resources. Users with no roles on parent resources can still see
the navigation entities on these parent resources, so these users can access resources that are lower in the hierarchy.
Users cannot view the content of any resources for which they have no roles.
Traversal support is provided for pages and URL mappings.
See also