Authorization groups in heterogeneous environments

We can use fine-grained administrative security in heterogeneous environments for nodes created on different versions of the product, and applications grouped and placed in different authorization groups. WebSphere support of heterogeneous systems enables the Dmgr node to run at the currently installed version of WebSphere, while other nodes run at lower versions of WebSphere that are compatible with the currently installed version. Any resource instance that is not part of a Version 6.1 or higher node cannot be added to an authorization group.

Fine-grained administrative security in a heterogeneous environment has the following requirements:

• Only nodes running WAS v9.0 can be part of an authorization group.
• Only servers running in a WAS v9.0 node can be part of an authorization group.
• Only applications targeted on servers running on WAS v9.0 can be part of an authorization group.
• If a cluster spans nodes of multiple releases, it cannot be part of an authorization group.
• If a cluster spans nodes of multiple releases, none of its members can be part of an authorization group.
• If an application is targeted on a cluster that spans multiple releases, that application cannot be part of an authorization group.

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 administrative resource is removed from the authorization group. In this instance, the administrative resource belongs to the cell-level authorization group.

• The administrative resource is removed from the configuration. In this instance, the administrative resource does not exist in the configuration, but still exists in the authorization group. Remove this administrative resource from the authorization group.

After the administrative resource is removed from the authorization group, the administrative authorizer runtime must be notified using the AuthorizationManager refreshAll MBean method.

The refreshAll command must be invoked after AdminConfig.save() and sync nodes. For example:

JACL:

set agBean [$AdminControl queryNames type=AuthorizationGroupManager,process=dmgr,*]
$AdminControl invoke &agBean refreshAll

JYTHON:

set agBean AdminControl.queryNames('type=AuthorizationGroupManager,process=dmgr,*')
AdminControl.invoke(agBean, 'refreshAll')

The server restart is no longer needed.

Each application server in the cell will be refreshed automatically when the refreshAll command is issued to the AuthorizationGroupManager MBean in the deployment manager or an administrative agent. All registered servers will be notified.

Related:

Configure authorization groups

Role-based authorization

Administrative roles