WAS v8.5 > Secure applications > Authorizing access to resources

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. WAS is now more fine-grained, meaning that access can be granted to each user per resource.

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 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 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 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 dmgr console. Using the adminsecuritymanager role, we 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.

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. Examples using wsadmin:

Resources that can be added to an authorization group

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

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. We cannot add the same resource to more than one authorization group.

The following diagram shows the containment relationship among resources:

The privileges required for actions on resources depends 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.

Privileges required to access various administrative resources. The privileges required to access various administrative resources 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 administrative security in the dmgr 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 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.

It is not recommended to have an application in one group and its target server in another group. However, not always possible. It is common to have many applications on one server. It is still sometimes necessary to isolate the administration of applications running on the same server.

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.

Deployment role scenario 1 applications.

This table lists the Deployment role scenario 1 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.

Deployment role scenario 2 applications.

This table lists the Deployment role scenario 2 applications.

Application Server Node
A1 S1 N1
A2 S1 N1
A3 S2 N2
A4 S3 N3

Scenarios that can be applied directly in customer environments.

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 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 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).

ASP environment scenario.

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 the customer has paid to have served by this ASP.

When updating the configuration repository, run the admin scripts from the deployment manager so 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.

Regional organization scenario.

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


Subtopics


Related concepts:

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


Related


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


Reference:

Administrative roles


+

Search Tips   |   Advanced Search