Administrative console and naming service authorization

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 called wsadmin. The authorization policy is only enforced when global security is enabled. The four administrative security roles are defined in the following table:administrative roles that are available through the administrative console and wsadmin

Role Description
Monitor An individual or group that uses the monitor role has the least amount of privilages. A monitor can complete the following tasks:
View the WebSphere Application Server configuration.
View the current state of the Application Server.

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:
Create a resource.
Map an application server.
Install and uninstall an application.
Deploy and application.
Assign users and groups-to-role mapping for applications.
Set up Java 2 security permissions for applications.
Customize the Common Secure Interoperability Version 2 (CSIv2), Security Authentication Service (SAS), and Secure Sockets Layer (SSL) configurations.

Operator An individual or group that uses the operator role has the monitor privileges plus ability to change the run time state. For example, an operator can complete the following tasks:
Stop and start the server.
Monitor the server status in the administrative console.

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:
Modify the server user ID and password.
Map users and groups to the administrator role.
Configure authentication and authorization mechanisms.
Enable or disable global security.
Enable or disable Java 2 security.
Change the Lightweight Third Party Authentication (LTPA) password and generate keys.

When global security is enabled, the administrative subsystem role-based access control is enforced. The administrative subsystem includes the security server, the 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.

If a Lightweight Directory Access Protocol (LDAP) or custom registry is specified, ensure that customization provided to facilitate using Local OS is removed. After an LDAP or custom registry is used, the configured server identities are used for work executed by the system instead of by the started task identities. You must delete pre-configured WebSphere Application Server configuration group and administrator identities from the console group and console users respectively.

Administrative roles

When global security is enabled, WebSphere Application Servers 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. The WebSphere Application Server run-time code, which runs under the server identity, requires authorization to 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 WebSphere Application Server global security
Enforce or disable Java 2 Security
Change the LTPA password or generate keys
Assign users and groups to administrative roles

The server identity that is specified when you enable global security is automatically mapped to the administrative role. 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.

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.

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.

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. 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. Four security roles are introduced :

CosNamingRead
CosNamingWrite
CosNamingCreate
CosNamingDelete

The roles have authority levels from low to high:

CosNamingRead: You can query the WebSphere Application Server name space, using, for example, the JNDI lookup method. The special-subject, Everyone, is the default policy for this role.
CosNamingWrite: You 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: You 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: You 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 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.

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

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, WebSphere Application Server 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 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.

Related concepts
Authorization technology

Searchable topic ID: csec_adminconsole

Role	Description
Monitor	An individual or group that uses the monitor role has the least amount of privilages. A monitor can complete the following tasks: View the WebSphere Application Server configuration. View the current state of the Application Server.
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: Create a resource. Map an application server. Install and uninstall an application. Deploy and application. Assign users and groups-to-role mapping for applications. Set up Java 2 security permissions for applications. Customize the Common Secure Interoperability Version 2 (CSIv2), Security Authentication Service (SAS), and Secure Sockets Layer (SSL) configurations.
Operator	An individual or group that uses the operator role has the monitor privileges plus ability to change the run time state. For example, an operator can complete the following tasks: Stop and start the server. Monitor the server status in the administrative console.
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: Modify the server user ID and password. Map users and groups to the administrator role. Configure authentication and authorization mechanisms. Enable or disable global security. Enable or disable Java 2 security. Change the Lightweight Third Party Authentication (LTPA) password and generate keys.