The Java™ Platform, Enterprise Edition (Java EE) role-based authorization concept is extended to protect the WebSphere® Application Server administrative subsystem.
A number of administrative roles are defined to provide degrees of authority that are needed to perform certain administrative functions from either the Web-based administrative console or the system management scripting interface. The authorization policy is only enforced when administrative security is enabled. The following table describes the administrative roles:
|Monitor||An individual or group that uses the monitor
role has the least amount of privileges. A monitor can complete the
|Configurator||An individual or group that uses the configurator
role has the monitor privilege plus the ability to change the WebSphere Application Server configuration.
The configurator can perform all the daily configuration tasks. For
example, a configurator can complete the following tasks:
|Operator||An individual or group that uses the operator
role has monitor privileges plus ability to change the runtime state.
For example, an operator can complete the following tasks:
|Administrator||An individual or group that uses the administrator
role has the operator and configurator privileges, plus additional
privileges that are granted solely to the administrator role. For
example, an administrator can complete the following tasks:
Important: An administrator cannot map users and groups to the administrator roles without also having the adminsecuritymanager role.
|iscadmins||This role is only available for administrative
console users, not for wsadmin users. Users who are granted this role
have administrator privileges for managing users and groups in the
federated repositories. For example, a user of the iscadmins role
can complete the following tasks:
|Deployer||Users granted this role can complete both configuration actions and runtime operations on applications. See the Deployer role section for more details.|
|Admin Security Manager||You can assign users and groups to the Admin Security Manager role on the cell level through wsadmin scripts and the administrative console. Using the Admin Security Manager 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 Admin Security Manager role. See the Admin Security Manager role section for more details.|
|Auditor||Users granted this role can view and modify
the configuration settings for the security auditing subsystem. For
example, a user with the auditor role can complete the following tasks:
The server ID that is specified and the administrative ID, if specified, when enabling administrative security is automatically mapped to the administrator role.
Users and groups can be added or removed from administrative roles using the WebSphere Application Server administrative console by a user given the appropriate authority. The Primary administrative user name must be used to log on to the administrative console to change the administrative user and group roles other than the auditor role. Only a user with the auditor role can change the auditor user and group roles. When security auditing is initially enabled, the Primary administrative user is also given the auditor role, and can manage all of the administrative user and group roles including the those in the auditor role. A best practice is to map a group or groups, rather than specific users, to administrative roles because it is more flexible and easier to administer.
In addition to mapping user or groups, a special-subject can also be mapped to the administrative roles. A special-subject subject is a generalization of a particular class of users. The AllAuthenticated special subject means that the access check of the administrative role ensures that the user making the request is at least authenticated. The Everyone special subject means that anyone, authenticated or not, can perform the action, as if security was not enabled.
A user that is granted a deployer role can complete all of the configuration and runtime operations on an application. A deployer role can be subsets of both configurator and operator roles. However, a user granted a deployer role cannot configure or operate any other resources, such as a server, node.
When fine-grained administrative security is used, only a user granted a deployer role to an application can configure and operate that application.
Cell-level configurators can configure applications. Cell-level operators can also operate (start and stop) applications. However, a user granted a deployer role at cell level can also complete configuration and operation on all applications.
|Operation||Required Roles ( Any one)|
|Install application||Cell-configurator, target-deployer|
|Uninstall application||Cell-configurator, application-deployer, target-deployer|
|List application||Cell-monitor, application-monitor|
|Edit, update and redeploy application||Cell-configurator, application-deployer|
|Export application||Cell-monitor, application-monitor|
|Start or stop application||Cell-operator, application-deployer|
- Specifies the configurator role at cell level.
- Specifies the deployer role for the application that is being managed.
- Specifies the deployer role for all servers or clusters for which
an application is targeted. If you have a target-deployer role, you
can install a new application on the target. However, to edit or update
the installed application, you must be included in the authorization
group of the installed application-deployer.
The target-deployer cannot explicitly start or stop a new application. However, when a target-deployer starts a server on a target, all of the applications that have their auto-start attribute set to yes are started when the server starts.
It is recommended that the application-deployer set this attribute to true if the application-deployer does not want the application to be started by the target-deployer.
Admin Security Manager role
The Admin Security Manager role separates administrative security administration from other application administration.
By default, serverId and adminID, if specified, are assigned to this role in the cell level authorization table. This role implies a monitor role. However, an administrator role does not imply the Admin Security Manager role.
|Map users to administrative roles for cell level||Only the Admin Security Manager of the cell|
|Map users to administrative roles for an authorization group||Only the Admin Security Manager of that authorization group or the Admin Security Manager of the cell|
|Manage authorization groups, create, delete, add resource to an authorization group, or remove resource from an authorization group or list||Only the Admin Security Manager of the cell|
The auditor role separates security auditing administration from administrative security and other application administration.
The auditor role was added to allow distinct separation of the authority of an auditor from the authority of the administrator. The auditor role can be granted to administrators to combine their authority. When security is first enabled, the auditor role is assigned to the primary administrator. If in your situation the separation of authority is required, administrators can remove the auditor role from themselves and assign the auditor role to other users.
A fine grained security for the auditor role is not implemented, which results in the auditor role requiring the monitor role. This process allows the auditor to read but not modify the panels managed by the administrator. The auditor has full authority to read and modify the panels associated with the security auditing subsystem. The administrator will have the monitor role for those panels, however, the administrator cannot modify those panels.