WebSphere Application Server extends the Java 2 Platform, Enterprise Edition (J2EE) security role-based access control to protect the product administrative and naming subsystems.
Four administrative roles are defined to provide the degrees of authority that are needed to perform certain WebSphere Application Server administrative functions from either the administrative console or the system management scripting interface called wsadmin. The authorization policy is only enforced when global security is enabled. The following table describes the administrative roles:
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 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:
Note: An administrator cannot map users and groups to the administrator
roles.
|
When global security is enabled, the administrative subsystem role-based access control is enforced. The administrative subsystem includes the security server, the administrative console, the wsadmin scripting tool, and all the Java Management Extensions (JMX) MBeans. When administrative 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 you are changing registries, make sure you remove the information that pertains to the previously configured registry for console users and console groups.
WebSphere Application Server for z/OS security customization dialogs prime the administrative subsystem to accept the MVS identities of all the started WebSphere Application Server system tasks (for example, controllers, servants, and so on) as WebSphere administrators and the configured administrator identity. If a federated repository, a standalone Lightweight Directory Access Protocol (LDAP) registry, or a standalone custom registry is specified, the configured server identities are used for work that is run by the system instead of for work that is run by the started task identities.
When enabling security, you can assign one or more users and groups to naming 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.
Special subject
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 is at least authenticated. The Everyone special subject means that anyone, authenticated or not, can perform the action as if security is not enabled.
CosNaming security offers increased granularity of security control over CosNaming functions. CosNaming functions are available on CosNaming servers such as the WebSphere Application Server. These functions affect the content of the WebSphere Application Server name space. Generally, you have two ways in which client programs result in CosNaming calls. The first is through the Java Naming and Directory Interface (JNDI) call. The second is with common object request broker architecture (CORBA) clients invoking CosNaming methods directly.
When you configure a local OS user registry with WebSphere Application Server for z/OS, factors require some additional considerations. Refer to Selecting a user registry and Configuring local operating system user registries for more information. If you specify an LDAP or a custom registry, you must remove local OS customization by deleting the preconfigured WebSphere Application Server configuration group and administrator identity from the console group and delete the console users.
A Server special-subject is assigned to all of the four CosNaming roles by default. The Server special-subject provides a WebSphere Application Server process, which runs under the server identity, to access all the CosNaming operations. The Server special-subject does not display and cannot be modified through the administrative console or other administrative tools.
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.
Configuration is not required to enable the server identity (as specified) when enablingglobal security for administrative use because the server identity is automatically mapped to the administrator role. 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. When SAF Authorization is chosen, a server restart is not 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.
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 runtime. Typically, J2EE applications access the name space and the identity they use is that of the user that authenticated to WebSphere Application Server when accessing the J2EE application. Unless the J2EE application provider clearly communicates the expected naming roles, use caution when changing the default naming authorization policy.