Portal Roles
Overview
With v5.0 of WebSphere Portal, access control is based on roles, which combine a set of permissions with a specific WebSphere Portal resource (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.
WebSphere Portal role types include:
Role Type Permissions Administrator Unrestricted access on resources. Can create, configure, and delete resources. Can change the access control configuration. Security Administrator Create and delete role assignments on resources for which one has at least the Delegator role. Minimum role assignments: Delegator@Principal + Security_Administrator@Resource + RoleType@ResourceDelegator Assign users/groups to roles on resources for which one has at least the Security Administrator role. Minimum role assignments: Delegator@Principal + Security_Administrator@Resource + RoleType@ResourceThe Delegator role should be assigned on user/group or virtual resources. Having the Delegator role on other resources, such as specific portlets, is not useful.
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 View portal content, customizing portlets and pages, and creating new private pages. User View portal content. For example, viewing a specific page. No role assigned Cannot interact with resource.
Role hierarchy
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.
Role Mappings and WSRP services
When security is not enabled in the Producer portal, anonymous users need the role mappings to access the remote portlets accordingly. Anonymous users can access and use the portal without authenticating with user IDs and passwords. When security is enabled in the Producer portal, the appropriate role mappings must be defined for the user who represents the Consumer portal.
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, Penelope, is a member of the Operations group. You can give Penelope Editor access to the Market News Page and all pages underneath this page by granting the Editor@Market News Page role to the Operations group. All members of the Operations group implicitly acquire the Editor@Market News page role. All members of the Operations 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 Operations 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 Penelope has the Administrator@Market News Page role, and the USA Market News Page is a child of the Market News Page, Penelope 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 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 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 Penelope 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), Penelope 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 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
WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.
Tivoli is a trademark of the IBM Corporation in the United States, other countries, or both.