Administrative Console Security



WAS extends role-based access control to the console. If global security is enabled, four administrative security roles are defined...

Role Description
monitor Least privileged where a user can view the WAS configuration 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, such as starting or stopping services.
administrator Operator plus configuration privilege and the permission required to access sensitive data including the server password, LTPA password, LTPA, keys, and so on.

The administrative subsystem includes security server, user registry, and all the JMX MBeans.

The server identity is automatically mapped to the administrative role. Users and groups can be added later. A server restart is required for the changes to take effect.

You can map a special-subject to the administrative roles. A special-subject is a generalization of a particular class of users.

Special-subject Description
AllAuthenticated User making the request has to be authenticated.
Everyone Anyone, authenticated or not, can perform the action, as if security is not enabled.
Server Not shown on the administrative console or other tools. The server identity is assigned to the administrative role by default.
The administrative security policy can perform the following...

  1. Change server ID and server password
  2. Enable or disable global security
  3. Enforce or disable Java 2 Security
  4. Change the LTPA password or generate keys
  5. Assign users and groups to administrative roles

Configure the active user registry before assign users and groups to roles.


CosNaming security

There are generally two ways client programs can call CosNaming servers: JNDI and CORBA clients. Security roles available for the calls include...

CosNamingRead Users can query of the WAS name space, using, for example, the JNDI lookup method. The special-subject Everyone is the default policy for this role.

CosNamingWrite Users can perform write operations such as JNDI bind, rebind, or unbind, and CosNamingRead operations. The special-subject AllAuthenticated is the default policy for this role.

CosNamingCreate Users can create new objects in the name space through such operations as JNDI createSubcontext and CosNamingWrite operations. The special subject AllAuthenticated is the default policy for this role.

CosNamingDelete Users can destroy objects in the name space, for example using the JNDI destroySubcontext method and CosNamingCreate operations. The special-subject AllAuthenticated is the default policy for this role.

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 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 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 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.