Fine-grained admin security


In releases prior to WAS version 6.1, users granted admin roles could administer all of the resource instances under the cell. WAS 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 appserver or a node). Users cannot access any other resources outside of the resources assigned to them. The admin 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.

Nodes prior to WAS V6.1 in a mixed cell environment are filtered out of resource mapping.

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

Fine-grained admin 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 in a single-server environment.

We can assign users and groups to the adminsecuritymanager role on the cell level through wsadmin scripts and the admin console. Using the adminsecuritymanager role, we can assign users and groups to the admin user roles and admin group roles.

When fine grained admin security is used, users granted the adminsecuritymanager role can manage authorization groups. See Administrative roles and naming service authorization for detailed explanations of all admin roles.

An administrator cannot assign users and groups to the administrative user roles and admin group roles, including the adminsecuritymanager role. See Administrative roles for more details.

There are several admin security commands that can be used to create authorization groups, map resources to authorization groups, and to assign users to admin roles within the authorization groups. Following are some examples using wsadmin:

Resources that can be added to an authorization group

We can add only resource instances of the following types to an authorization group:

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

Keystore management requires a user to have cell-level administrative privileges because they are created and managed at the cell level. Fine-grained security access to a specific resource does not allow management of the associated keystores.

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.

To use fine-grained admin security in the admin 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 we log in to the admin console as a cell-level administrator, adminsecuritymanager, operator, monitor or configurator, we can perform all of the operations that the role allows you to do. However, if we want to give users access only to specific authorization groups or permissions to non-cell authorizations groups, use wsadmin.



Subtopics


New Administrative Authorization Group
Administrative Authorization Group collection

 

Related concepts


Fine-grained admin security in heterogeneous and single-server environments
Administrative roles and naming service authorization
Role-based authorization

 

Related tasks


Create a fine-grained admin authorization group
Edit a fine-grained admin authorization group

 

Related


Administrative roles
Example: Using fine-grained security