WebSphere Application Server extends the Java 2 Platform, Enterprise Edition (J2EE) security role-based access control to protect the product administrative and naming subsystems.
Administrative console
Four administrative roles are defined to provide degrees of authority needed to perform certain WebSphere Application Server administrative functions from either the administrative console or the system management scripting interface. The authorization policy is only enforced when global security is enabled. The four administrative security roles are defined in the following table:
Role | Description |
Monitor | An individual or group that uses the monitor
role has the least amount of privileges. A monitor can complete the following
tasks:
|
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 day-to-day 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 run time 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:
|
When WebSphere Application Server global security is enabled, the administrative subsystem role-based access control is enforced. The administrative subsystem includes security server, user registry, and all the Java Management Extensions (JMX) MBeans. When security is enabled, both the administrative console and the administrative scripting tool require users to provide the required authentication data. Moreover, the administrative console is designed so the control functions that display on the pages are adjusted according to the security roles that a user has. For example, a user who has only the monitor role can see only the non-sensitive configuration data. A user with the operator role can change the system state.
When WebSphere Application Server for z/OS global security
is enabled, the administrative subsystem role-based access control is enforced.
The administrative subsystem includes security server, user registry, and
all the Java Management Extensions (JMX) MBeans. When security is enabled,
both the administrative console and the administrative scripting tool require
users to provide the required authentication data. Moreover, the administrative
console is designed so the control functions that display on the pages are
adjusted according to the security roles that a user has. For example, a user
who has only the monitor role can see only the non-sensitive configuration
data. A user with the operator role can change the system state.
WebSphere Application Server for z/OS security customization dialogs prime the administrative subsystem to accept the MVS identities of all started WebSphere system tasks (controllers, servants, and so on) as WebSphere administrators and to accept the configured WebSphere administrator identity.
If
an LDAP or Custom Registry is specified, you must ensure that customization
provided to facilitate using Local OS is removed. You must delete pre-configured
WebSphere Configuration Group and Administrator identity from the console
group and console users respectively.
SAF authorization for administrative roles
The value of the com.ibm.security.SAF.authentication setting controls whether SAF EJBROLE profiles or the console settings are used to control access to administration profiles rather than the console users. With SAF authorization any values in the console users and console groups are ignored.
When SAF authorization is selected, WebSphere Application
Server for z/OS servers in the cell do not have to use the same security name
(enabled with PQ81586). Instead, all WebSphere Application Server for z/OS
processes (as well as the default administrative user IDs) are configured
to a WebSphere configuration group as part of customization. This customization
process grants the Console Group administrative role to this WebSphere configuration
group.
(When SAF authorization
is chosen, no server restart is needed to authorize additional users or groups.)
WebSphere authorization for administrative roles
If WebSphere authorization (rather than SAF authorization) is used to restrict access to J2EE roles, WebSphere Application Server for z/OS automatically maps the server identity specified when enabling global security to the administrative role. Also, when global security is enabled, WebSphere Application Servers on z/OS run under the server identity that is defined under the active configured user registry configuration. Although it is not shown on the administrative console and in other tools, a special Server subject is mapped to the administrator role. This is why the WebSphere Application Server run-time code, which runs under the server identity, requires authorization to execute run-time operations. If no other user is assigned administrative roles, you can log into the administrative console or to the wsadmin scripting tool using the server identity to perform administrative operations and to assign other users or groups to administrative roles.
A special configuration is not
required to enable the server identity (as specified) when enabling global
security for administrative use because the server identity is automatically
mapped to the administrator role (enabled with PQ81586)
You can add or remove users and groups to or from the administrative roles from the WebSphere Application Server administrative console. However, a server restart is required for the changes to take effect. A best practice is to map a group, rather than specific users, to administrative roles because it is more flexible and easier to administer. By mapping a group to an administrative role, adding or removing users to or from the group occurs outside of WebSphere Application Server and does not require a server restart for the change to take effect.
Administrative roles
In addition to mapping users or groups, you can map a special-subject to the administrative roles. A special-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 has at least been authenticated. The Everyone special subject means that anyone, authenticated or not, can perform the action, as if security is not enabled.
When enabling security, you can assign one or more users and groups to administrative roles. For more information, see Assigning users to naming roles. However, before assigning users to naming roles, configure the active user registry. User and group validation depends on the active user registry. For more information, see Configuring user registries.
Naming service authorization
CosNaming security offers increased granularity of security control over CosNaming functions. CosNaming functions are available on CosNaming servers such as the WebSphere Application Server. They affect the content of the WebSphere Application Server name space. There are generally two ways in which client programs result in CosNaming calls. The first is through the JNDI interfaces. The second is with CORBA clients invoking CosNaming methods directly.
Four security roles are introduced :
When you
configure a local OS user registry to user with WebSphere Application Server
for z/OS, there are some additional considerations. Refer to Configuring user registries and Steps for selecting a local OS registry for more information.
If you specify an LDAP or a custom registry, you must remove local OS customization
by deleting the pre-configured WebSphere configuration group and administrator
identity from the console group. Then delete the console users.
Additionally, a Server special-subject is assigned to all the four CosNaming roles by default. The Server special-subject provides a WebSphere Application Server server process, which runs under the server identity, access to all the CosNaming operations. Note that the Server special-subject does not display and cannot be modified through the administrative console or other administrative tools.
No special configuration is required
to enable the server identity (as specified) when enabling global security
for administrative use because the server identity is automatically mapped
to the administrator role (enabled with PQ81586) .
Users, groups, or the special subjects AllAuthenticated and Everyone can be added or removed to or from the naming roles from the WebSphere Application Server administrative console at any time. However, a server restart is required for the changes to take effect. (Note that when SAF Authorization is chosen, no server restart is needed to authorize additional users or groups.) A best practice is to map groups or one of the special-subjects, rather than specific users, to naming roles because it is more flexible and easier to administer in the long run. By mapping a group to a naming role, adding or removing users to or from the group occurs outside of WebSphere Application Server and does not require a server restart for the change to take effect.
Note that when System Authorization
Facility (SAF) authorization is selected, you do not need to restart the server
to authorize additional users or groups (enabled with PQ81586).
The CosNaming authorization policy is only enforced when global security is enabled. When global security is enabled, attempts to do CosNaming operations without the proper role assignment result in an org.omg.CORBA.NO_PERMISSION exception from the CosNaming Server.
Although the ability exists to greatly restrict access to the name space by changing the default policy, unexpected org.omg.CORBA.NO_PERMISSION exceptions can occur at run time. Typically, J2EE applications access the name space and the identity they use is that of the user that authenticated to WebSphere Application Server when they access the J2EE application. Unless the J2EE application provider clearly communicates the expected Naming roles, use caution when changing the default naming authorization policy.