Fine-grained admin security in heterogeneous and single-server environments
Fine-grained admin security can be used in heterogeneous or single-server environments with some restrictions.
Fine-grained admin security in a heterogeneous environment
In WAS V 6.0, heterogeneous systems are supported. Specifically, a dmgr node can run in WAS V6.0, some nodes can run WAS V 6.0, and other nodes can run WAS V5.x. In WAS V7.0, nodes are available for WAS Vs 5.x, 6.0, and V7.0.
Because all of the configurations that are done in dmgr node are always of WAS V7.0 or higher, fine-grained admin security can be enforced when configuring resources that belong to earlier releases. However, run-time code for versions lower than V7.0 cannot enforce fine-grained admin security. Therefore, any resource instance not part of a WAS V7.0 node cannot be added to an authorization group.
Fine-grained administrative security in a heterogeneous environment has the following restrictions:
- Only nodes that are running WAS V7.0 can be part of an admin authorization group.
- Only servers that are running in a WAS V7.0 node can be part of an admin authorization group.
- Only applications that are targeted on servers running on WAS V7.0 can be part of an admin authorization group.
- If a cluster spans nodes of multiple releases, it cannot be part of an administrative authorization group.
- If a cluster spans nodes of multiple releases, none of its members can be part of an admin authorization group.
- If an application is targeted on a cluster that spans multiple releases, that application cannot be part of an admin authorization group.
Fine-grained admin security in a single-server environment
You can also use fine-grained admin security in a single-server environment. Various applications in the single server can be grouped and placed in different authorization groups. Therefore, different authorization constraints might exist for different applications.
Life cycle of fine-grained admin resource
An administrative resource that was once part of an authorization group continues to be part of that authorization group until one of the following events occurs:
- The admin resource is removed from the authorization group. In this instance, the admin resource belongs to the cell-level authorization group.
- The admin resource is removed from the configuration. In this instance, the admin resource does not exist in the configuration, but still exists in the authorization group. Remove this admin resource from the authorization group.
After the admin resource is removed from the authorization group, the admin authorizer runtime must be notified by using the AuthorizationManager refreshAll MBean method.
The refreshAll command must be invoked after AdminConfig.save() and sync nodes. For example: JACL:
// get AuthorizationGroup Mbean wsadmin> set agBean [$AdminControl queryNames Type=AuthorizationGroupManager,process=dmgr,*]JYTHON:
// get AuthorizationGroup Mbean wsadmin> set agBean [$AdminControl queryNames Type=AuthorizationGroupManager,process=dmgr,*]
Related concepts
Fine-grained admin security
Role-based authorization
Related
Administrative roles
Example: Using fine-grained security