Access Control Administration
This topic describes concepts that are related to administering WebSphere Portal access control.
To administer access control, use the Resource Permissions, User and Group Permissions, and Manage Users and Groups portlets. See the portlet help documents for detailed information about administrative tasks that are related to access control.
Initial Access Control Settings
The WebSphere Portal installation uses a dedicated administrative user. This user is a member of the group wpsadmins by default. The following table describes the initial access control settings:
User or Group Role The administrative user identified during the installation Administrator@Portal <wpsadmins> Administrator@Portal All Authenticated Users User@ the following portlet applications:
- Edit page content and layout
- Concrete Properties Web Application
- Appearance Web Application
- Set Permissions Portlets
Privileged User@ the following page:
- My Portal
- Welcome
- Information Portlet Application
User@ the following pages:
- Page Properties
- Organize Favorites
- Page Customizer
A user always has the permissions that are associated with the User, Editor, and Privileged User role types on itself. There is no explicit role assignment for these permissions. They are a part of the administration policy.
WebSphere Portal Administrator and Security Administrator
The Administrator@Portal and Security Administrator@Portal roles contain a special permission that is not available to any other role. This permission allows the Administrator or Security Administrator to make arbitrary changes to the access control configuration of all resources that are internally managed by the portal. The Administrator and Security Administrator can create and delete roles, role assignments, and role blocks. To change the access control configuration for resources that are externally managed, have the Administrator@External Access Control or the Security Administrator@External Access Control role.Delegated Administration
WebSphere Portal supports delegated access control administration. An administrator is a user who is authorized to modify the access control configuration by changing role assignments and creating or deleting role blocks. Administrators can delegate specific subsets of their administrative privileges to other users or groups. These users or groups can in turn delegate subsets of their privileges to additional users and groups. The delegated administration policy determines how users are permitted to delegate their privileges.Delegated Administration Policy
The delegated administration policy defines which role assignments are necessary in order to perform specific changes to the access control configuration.
The general policy for creating or deleting role assignments is as follows: A user U can create or delete a role assignment for a specific user or group UG to a role identified by role type RT and resource R in either of the following cases:
- All of the following criteria are met:
- U has the Security Administrator@R or Administrator@R role
- U has the RT@R role
- U has the Delegator@UG, Security Administrator@UG, or Administrator@UG role.
- U has the Administrator@Portal or Security Administrator@Portal role
For example, in order to assign a group to the role type on a resource, you must have at least the Delegator@Group + Security_Administrator@Resource + RoleType@Resource roles.
Note: The Security Administrator@Portal and Administrator@Portal roles allow users to make unrestricted changes to the access control configuration of resources that are under internal portal control. Users also need the Administrator@External Access Control role or the Security Administrator@External Access Control role in order to change the access control configuration for resources that are externally controlled by a security manager such as Tivoli Access Manager.
The general policy for creating or deleting role blocks is as follows: A user U can create or delete a role block on a specific resource R and a role type RT in either of the following cases:
- Both of the following criteria are met:
- U has the Security Administrator@R or Administrator@R role
- U has the RT@R role
- or if U has the Security Administrator@Portal or Administrator@Portal role.
Example of the delegated administration policy
Mary needs the authority to delete Hans from the Editor@Market News Page role. Hans is a member of the Marketing group.
She can do this if all of the following conditions are true:
- Mary is either Security Administrator@Market News Page or Administrator@Market News Page. She can acquire this role through an explicit role assignment, through an Administrator or Security Administrator role assignment on a parent resource, or by belonging to a group that has the appropriate role assignment.
- Mary is at least Editor@Marketing News Page since Hans will be deleted from the Editor role type.
- Mary has a Delegator@Marketing Group role. Mary cannot delete arbitrary users or groups from the Editor@Market News Page role. She can delete only those users and groups for which she has a Delegator role. Because Hans is a member of the Marketing group, Mary has a Delegator role for Hans.
Changing user profiles and group membership information
WebSphere Portal Version 5.0.2 changes the default behavior for modifying user profiles, changing group membership information, and other sensitive operations that require access to users and groups.
Roles assignments on user groups no longer include permissions on nested subgroups. To obtain permissions on a user, have a role assignment on a group to which the user directly belongs.
For example, suppose there are two user groups, the Sales Group and the Marketing group. The Marketing group is a nested subgroup of the Sales group. Mary is a direct member of the Marketing group.
- WebSphere Portal Version 5.0 default behavior: The Editor@Sales Group role allows a user to modify Mary's user profile
- WebSphere Portal Version 5.0.2 default behavior: The Editor@Sales Group role allows a user to modify Mary's user profile only if Mary is also a direct member of the Sales group
Roles that are assigned to user groups are still propagated to nested subgroups. For example, if the Sales group has the Editor@Market News Page role, then by default Mary still inherits that role assignment.
To revert to the WebSphere Portal Version 5.0 default behavior, modify the <wp_root>/shared/app/config/services/AccessControlDataManagementService.properties file by adding the following text in a new line:
accessControlDataManagement.enableTargetResourceGroupInheritance=true
See also
- Roles
- Resources
- Access Rights
- Access management scenarios
- Manage Users and Groups
- Resource Permissions portlet
- User and Group Permissions portlet
- Manage User Groups portlet