Fine-grained administrative security
In releases prior to WAS version 6.1, users granted administrative 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 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 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 the #rsecadminroles__adsecmanrole section 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 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 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
Fine-grained administrative security in heterogeneous and single-server environments
Administrative roles and naming service authorization
Role-based authorization
Related Reference
Administrative roles
Example: Using fine-grained security