Admin console and naming service authorization
Overview
WAS extends J2EE security role-based access control to protect administrative and naming subsystems. The administrative subsystem includes a security server, a user registry, and JMX MBeans.
Authorization policy is enforced after global security is enabled.
Four administrative roles are available:
monitor Least privileged. User can view the configuration info and current state. configurator Monitor privilege plus the ability to change the WAS configuration. operator Monitor privilege plus the ability to change the run-time state, including the ability to start or stop services. administrator Operator plus configuration privilege and the permission required to access sensitive data including the server and LTPA passwords, LTPA, keys, and so on. Console control functions are displayed based on security roles assigned to the user who is logged into the console. For example, a user who has only the monitor role only can see non-sensitive configuration data. A user with the operator role would have options available on GUI pages to change the system state.
The server identity specified when enabling global security is automatically mapped to the administrative role. Users and groups can be added or removed to or from the administrative roles from the WAS Web-based 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 in the long run. By mapping a group to an administrative role, adding or removing users to or from the group occurs outside of WAS and does not require a server restart for the change to take effect.
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 no security were enabled.
When global security is enabled, WAS run under the server identity that is defined under the active 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 WAS 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. Because the server identity is assigned to the administrative role by default, the administrative security policy requires the administrative role to perform the following operations:
- Change server ID and server password
- Enable or disable WAS global security
- Enforce or disable Java 2 Security
- Change the LTPA password or generate keys
- Assign users and groups to administrative roles
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 Configure user registries.
Naming service authorization
CosNaming security controls CosNaming functions served up by CosNaming servers running within the WAS container.
There are generally two ways in which client programs result in CosNaming calls.
- JNDI interfaces.
- CORBA clients invoking CosNaming methods directly
Four security roles available:
Additionally, a Server special-subject is assigned to all the four CosNaming roles by default. The Server special-subject provides a WAS 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.
Users, groups, or the special subjects AllAuthenticated and Everyone can be added or removed to or from the naming roles from the WebSphere Web-based administrative console at any time. However, a server restart is required for the changes to take effect. 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 WAS 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.
In WAS Version 4.0.2, each CosNaming function is assigned to only one role. Therefore, users who are assigned the CosNamingCreate role cannot query the name space unless they have also been assigned CosNamingRead. And in most cases a creator needs to be assigned three roles: CosNamingRead, CosNamingWrite, and CosNamingCreate. The CosNamingRead and CosNamingWrite roles assignment for the creator example are included in the CosNamingCreate role. In most of the cases, WAS administrators do not have to change the roles assignment for every user or group when they move to this release from a previous one.
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 WAS 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.
Assigning users to naming roles
Configure user registries
WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.