Assign users to naming roles

WebSphere Application Server extended J2EE security role based access control to protect the WebSphere Application Server naming subsystem. 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 make CosNaming calls. The first is through the JNDI interfaces. The second is CORBA clients invoking CosNaming methods directly.

Four security roles are introduced: CosNamingRead, CosNamingWrite, CosNamingCreate, and CosNamingDelete. The names of the four are the same as those in WebSphere Application Server Advanced Edition v4.0.2. However, the roles now have authority level from low to high as follows:

• CosNamingRead. Users who are assigned the CosNamingRead role can query the WebSphere Application Server Name Space. The special subject Everyone is the default policy for this role.

• CosNamingWrite. Users who are assigned the CosNamingWrite role can perform write operations such as JNDI bind(), rebind(), or unbind(), in addition to the CosNamingRead operations. The special subject AllAuthenticated is the default policy for this role.

• CosNamingCreate. Users who are assigned the CosNamingCreate role can create new objects in the Name Space with operations such as JNDI createSubcontext(), in addition to the CosNamingWrite operations. The special subject AllAuthenticated is the default policy for this role.

• CosNamingDelete. Users who are assigned the CosNamingDelete role can destroy objects in the Name Space with operations such as JNDI destroySubcontext(), in addition to the 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 allows a WebSphere Application Server server process, which runs under the server identity, to have access to all the CosNaming operations. Note that the Server special subject is not displayed and cannot be modified through the administrative console nor other administrative tools.

Users, groups, or the special subjects AllAuthenticated and Everyone can be added to or removed from the Naming roles from the WebSphere administrative console. For the changes to take effect, stop and restart the application server. 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. When you update a group, you do not need to restart the application server.

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 a org.omg.CORBA.NO_PERMISSION exception from the CosNaming Server.

In WebSphere Application Server Version 4.0.2, each CosNaming function is assigned to only one role. Therefore, users who have been assigned CosNamingCreate role are not able to query the Name Space unless they have also been assigned CosNamingRead. In most cases, a creator would need to be assigned three roles: CosNamingRead, CosNamingWrite, and CosNamingCreate. In WebSphere Application Server Version 5, all three of these roles are included in the CosNamingCreate role. In most of the cases, you do not need to change the role assignments for every user or group when you migrate to Version 5.

You can restrict access to the Name space by changing the default policy. However, doing so may result in unexpected org.omg.CORBA.NO_PERMISSION exceptions at runtime. Typically, J2EE applications access the Name space and the identity they use is that of the user that authenticated to WebSphere when they access the J2EE application. Unless the J2EE application provider clearly communicates the expected Naming roles, it is recommended that you do not change the default naming authorization policy.

To assign users to naming roles, perform these steps:

1. Start the administrative console.

2. In the administrative console, expand Environment --> Naming. Click CORBA Naming Service Users or CORBA Naming Service Groups. For additional information on user and group settings, see these topics:

   • Console users settings
   • CORBA Name Service users settings
   • Console groups settings
   • CORBA Name Service groups settings

3. Perform the necessary tasks:

   • To add a user or a group, click Add on the Console users or Console groups panel.
   • To add a new administrative user, specify a user identity in the user text box and highlight one administrative role, and then click OK. If there is no validation error, the specified user is displayed with the assigned security role. To add a new administrative group, specify a group name or select the EVERYONE or ALLAUTHENTICATED special subject, and then click OK. If there is no validation error, the specified group or special subject is displayed with the assigned security role.
   • To remove a user or group assignment, click Remove on the Console user or Console group panel. On the user or group panel, click the check box for the user or group that you want to remove, and then click OK.
   • To manage the set of users or groups to be displayed, expand the filter folder on the right side panel, and modify the filter text box. For example, setting the filter to "user*" displays only users with the "user" prefix.

4. After you make your changes, save the configuration.