Fine-grained administrative security
In releases prior to WebSphere® Application Server version 6.1, users granted administrative roles could administer all of the resources under the cell. WebSphere Application Server is now more fine-grained, meaning that access can be granted to each user per resource.
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 in a single-server environment.
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.
When fine grained administrative security is used, users granted the adminsecuritymanager role can manage authorization groups. See Administrative roles and naming service authorization for detailed explanations of all administrative roles.
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.
- 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
- Cell
- Node
- ServerCluster
- Server
- Application
- NodeGroup
If a resource is not one of the types previously listed, its parent resource will be used.
A resource can only belong to one authorization group. However, there is a containment relationship among resources. If a parent resource belongs to a different authorization group than that of its child resource, the child resource implicitly will belong to multiple authorization groups. You cannot add the same resource to more than one authorization group.
The following diagram shows the containment relationship among resources:
- The authorization group of the administrative resource. If a user is granted access to an authorization group, all of the resources in that group will be included.
- The containment relationship of the resource. If a user is granted access to a parent resource, all of the children resources will be included.
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.
| 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 administrative security in 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.
Example: Using fine-grained security.
The following scenarios describe the use of fine-grained administrative security, particularly the new deployment role.
Deployment role scenario 1.In the following scenario, there are four applications configured on server S1, as shown in the following table. Each application must be isolated so that the administrator of one application cannot modify another application. Assume that only user1 can manage application A1, user2 can manage applications A2 and A3, and only user3 can manage application A4.
One example is an Application Service Provider (ASP), where a single application server can have multiple vendor applications. In this instance the server administrator is responsible for installing all of the vendor applications. Once applications are installed, each vendor can manage their own application without interfering with other vendor's applications.
| Application | Server | Node |
|---|---|---|
| A1 | S1 | N1 |
| A2 | S1 | N1 |
| A3 | S1 | N1 |
| A4 | S1 | N1 |
We can configure authorization groups as shown in the following diagram:
In the diagram, application A1 is in authorization group G1, applications A2 and A3 are in authorization group G2, and application A4 is in authorization group G3.
A deployer role is assigned from authorization group G1 to user1, from authorization group G2 to user2, and from authorization group G3 to user3.
Consequently, user1 can perform all of the operations on application A1, user2 on applications A2 and A3, and user3 on application A4. Since all applications share the same server, we cannot put the same server on all authorization groups. Only a cell-level administrator can install an application. After the installation of an application is complete, the deployer of each application can modify their own. To start and stop the server, cell-level administrative authority is required. This type of scenario is useful in an ASP environment.
Deployment role scenario 2.In the following scenario, a group of applications require the same administrative roles to one server. In this example, applications A1 and A2 are related applications, and can be administrated by one set of administrators. They are running on the same server (S1). Applications A3 and A4 require a different set of administrators, and are running on servers S2 and S3 respectively.
| Application | Server | Node |
|---|---|---|
| A1 | S1 | N1 |
| A2 | S1 | N1 |
| A3 | S2 | N2 |
| A4 | S3 | N3 |
Each developer must be able to modify the configuration for their server, and they must be able to install their application onto that server. They also must be able to start and stop the server as well as the application on the server.
Developers also must be able to configure the server so that they can debug any problems they run into. They must have the ability to update or modify the application being developed. The administrative authorization group for this developer includes at least one server and any applications that the developer installs on that server.
In the following example, developers of authorization group G1 have a new application (A11). They can install and target that new application only on servers within authorization group G1. Also, they can place that new application in their authorization group (G1).
In this scenario, the customer is an ASP. They have their own customers to whom they provide application serving function. They want to enable their customers to administer and monitor their applications, but not to see or administer applications for different customers. In this example, however, the ASP has internal staff administrators whose job it is to maintain the servers.
This internal ASP staff administrator might need to move an application from one server to another to ensure that an application remains available. The internal ASP staff administrator should be able to stop and start the servers and to change their configuration.
In contrast, the ASP customer administrator should not be able to stop or start servers. However, the ASP customer administrator should be able to update their applications running on those servers. The administrative authorization group for the internal ASP administrator can be the whole cell or can include a subset of servers, nodes, clusters and applications. The administrative authorization group for the customer administrator only includes those applications that the customer has paid to have served by this ASP.
When updating the configuration repository, run the admin scripts from the deployment manager so that the fine grain admin security rules will be in effect when admin scripts are run from the deployment manager side.
The following diagram contains a scenario where two different customers have two different types of applications, and can manage their own applications. However, the servers and nodes on which the applications are running are isolated from their customers. The servers and nodes can only be maintained by the internal administrators. In addition, the customers cannot target their applications on a different server. This can only be performed by the internal administrator or internal deployers.
In this scenario, the customer is a large global company. The company's nodes and servers are organized so as to provide application serving for different regions (or alternatively, different lines of business). They want representatives from the different regional areas to be able to monitor and administer the nodes and servers associated with that region. However, they do not want the regional administer to be able to effect any node and server associated with a different region.
The administrative authorization group for each regional representative includes the nodes, servers, clusters and applications associated with that region.
For example, consider a company that provides multiple services, such as a financial institution that provides services like credit card accounts, brokerage accounts, banking accounts, or travel accounts. Each of these services can be separate applications, and the administrator for each of these applications must also be different. The following figure shows one way to configure such a system:
The following figure shows how the resources in such a system can be grouped to isolate administrators from each other:
Note that the nodes are not part of any authorization group. Therefore, a trade application administrator cannot stop a server on any of the nodes, and is prevented from stopping a travel application.
The same system can be configured in another way as follows:
The following figure shows how the resources in such a system can be grouped to isolate administrators from each other: