Fine-grained administrative security

In releases prior to WebSphere Application Server version 6.1, users granted administrative roles could administer all of the resource instances under the cell. WebSphere Application Server is now more fine-grained, meaning that access can be granted to each user per resource instance.

For example, users can be granted configurator access to a specific instance of a resource only (an application, an application server or a node). Users cannot access any other resources outside of the resources assigned to them. The administrative roles are now per resource instance rather than to the entire cell. However, there is a cell-wide authorization group for backward compatibility. Users assigned to administrative roles in the cell-wide authorization group can still access all of the resources within the cell.

To achieve this instance-based security or fine-grained security, resources that require the same privileges are placed in a group called the administrative authorization group or authorization group. Users can be granted access to the authorization group by assigning to them the required administrative role.

Fine-grained administrative security can also be used in single-server environments. Various applications in the single server can be grouped and placed in different authorization groups. Therefore, there are different authorization constraints for different applications. Note that the server itself cannot be part of any authorization group.

Fine-grained administrative security is available using wsadmin only. However, you can assign users and groups to the adminsecuritymanager role on the cell level through wsadmin scripts and the administrative console. Using the adminsecuritymanager role, you can assign users and groups to the administrative user roles and administrative group roles. However, an administrator cannot assign users and groups to the administrative user roles and administrative group roles including the adminsecuritymanager role. See Administrative roles for more details.

When fine grained administrative security is used, users granted this role can manage authorization groups. See Administrative roles and naming service authorization for detailed explanations of all administrative roles. There are several administrative security commands that can be used to create authorization groups, map resources to authorization groups, and to assign users to administrative roles within the authorization groups. Following are some examples:

• Create a new authorization group:

  $AdminTask createAuthorizationGroup {-authorizationGroupName authGroup1}

• Deleting an authorization group:

  $AdminTask deleteAuthorizationGroup {-authorizationGroupName groupName}

• Add resources to an authorization group:

  $AdminTask addResourceToAuthorizationGroup
  {-authorizationGroupName groupName -resourceName Application=app1}

• Remove resources from an authorization group:

  $AdminTask removeResourceFromAuthorizationGroup 
  {-authorizationGroupName groupName -resourceName Application=app1}

• Add user IDs to roles in an authorization group:

  $AdminTask mapUsersToAdminRole {-authorizationGroupName groupName
  -roleName administrator -userids user1}

• Add group IDs to roles in an authorization group:

  $AdminTask mapGroupsToAdminRole {-authorizationGroupName groupName
  -roleName administrator -groupids group1}

• Remove user IDs from roles in an authorization group:

  AdminTask removeUsersFromAdminRole {-authorizationGroupName
  groupName -roleName administrator -userids user1}

• Remove group IDs from roles in an authorization group:

  $AdminTask removeGroupsFromAdminRole {-authorizationGroupName
  groupName -roleName administrator -groupids group1}

Resources that can be added to an authorization group You can add only resource instances of the following types to an authorization group:

• Cell

• Node

• ServerCluster

• Server

• Application

• NodeGroup

If a resource instance is not one of the types listed above, its parent resource will be used.

A resource instance can only belong to one authorization group. However, there is a containment relationship among resource instances. If a parent resource belongs to a different authorization group than that of its child resource instance, the child resource instance implicitly will belong to multiple authorization groups. You cannot add the same resource instance to more than one authorization group.

The following diagram shows the containment relationship among resource instances:

The privileges required for actions on resource instances depend on two factors:

• The authorization group of the administrative resource instance. If a user is granted access to an authorization group, all of the resource instances in that group will be included.

• The containment relationship of the resource instance. If a user is granted access to a parent resource instance, all of the children resource instances will be included.

The privileges required to access various administrative resource instances are shown in the following table:

Resource	Action	Required roles
Server	Start, stop, runtime operations	Server-operator, node-operator, cell-operator
Server	New, delete	Node-configurator, cell-configurator
Server	Edit configuration	Server-configurator, node-configurator, cell-configurator
Server	View configuration, runtime status	Server-monitor, node-monitor, cell-monitor
Node	Restart, stop, sync	Node-operator, Cell-operator
Node	Add, delete	Cell-configurator
Node	Edit configuration	Node-configurator, cell-configurator
Node	View configuration, runtime status	Node-monitor, cell-monitor
Cluster	Start, stop, runtime operations	Cluster-operator, cell-operator
Cluster	New, delete	Cell-configurator
Cluster	Edit configuration	Cluster-configurator, cell-configurator
Cluster	View configuration, runtime status	Cluster-monitor, cell-monitor
Cluster member	Start, stop, runtime operations	Server-operator, cluster-operator, node-operator, cell-operator
Cluster member	New, delete	Node-configurator, cell-configurator
Cluster member	Edit configuration	Server-configurator, cluster-configurator, node-configurator, cell-configurator
Cluster member	View configuration, runtime status	Server-monitor, cluster-monitor, node-monitor, cell-monitor
Application	All operations	Refer to the section "Deployer roles" in Administrative roles.
Node, cluster	Add, delete	Cell-configurator

The server-operator role is the operator role of the authorization group to which the server instance is part of. Similarly, the node-operator role is in the operator role of the authorization group to which the node instance is part of.

Fine-grained administrative security is only available for wsadmin users. It is not available for administrative console users. To log in to the administrative console, a user should be granted a monitor role at the cell level at minimum. However, to login using wsadmin, a user should be granted a monitor role for any authorization group.

If you log in to the administrative console as a cell-level administrator, adminsecuritymanager, deployer, operator, monitor or configurator, you can perform all of the operations that the role allows you to do. However, if you want to give users access only to specific authorization groups or permissions to non-cell authorizations groups, use wsadmin.

Related concepts

Related Reference