Naming roles

The Java™ 2 Platform, Enterprise Edition (J2EE) role-based authorization concept is extended to protect the CosNaming service.

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 name space. Generally two ways are acceptable in which client programs result in CosNaming calls. The first is through the Java Naming and Directory Interface (JNDI) methods. The second is CORBA clients invoking CosNaming methods directly.

The following security roles exist. However, the roles have an authority level from low to high as shown in the following list. The list also provides the security-related interface methods for each role. The interface methods that are not listed are either not supported or not relevant to security.
CosNamingRead
Users who are assigned the CosNamingRead role can do queries of the name space, such as through the JNDI lookup method. The EVERYONE special-subject is the default policy for this role. However, it is recommended that you secure naming read operations by specifying the ALL_AUTHENTICATED special subject so that only authenticated users can perform a read or lookup. Changing the special subject from EVERYONE to ALL_AUTHENTICATED might have an impact on your existing applications. However, when the resources are protected, you can specify access for the same users who previously had access.
Table 1. CosNamingRead role packages and interface methods . The following table lists the CosNamingRead role packages and interface methods:
Package Interface methods
javax.naming
  • Context.list
  • Context.listBindings
  • Context.lookup
  • NamingEnumeration.hasMore
  • NamingEnumeration.next
org.omg.CosNaming
  • NamingContext.list
  • NamingContext.resolve
  • BindingIterator.next_one
  • BindingIterator.next_n
  • BindingIterator.destroy
CosNamingWrite
Users who are assigned the CosNamingWrite role can do write operations (such as JNDI bind, rebind, or unbind) plus CosNamingRead operations. As a default policy, Subjects are not assigned this role.
Table 2. CosNamingWrite role packages and interface methods . The following table lists the CosNamingWrite role packages and interface methods:
Package Interface methods
javax.naming
  • Context.bind
  • Context.rebind
  • Context.rename
  • Context.unbind
org.omg.CosNaming
  • NamingContext.bind
  • NamingContext.bind_context
  • NamingContext.rebind
  • NamingContext.rebind_context
  • NamingContext.unbind
CosNamingCreate
Users who are assigned the CosNamingCreate role are allowed to create new objects in the name space through JNDI createSubcontext operations plus CosNamingWrite operations. As a default policy, Subjects are not assigned this role.
Table 3. CosNamingCreate role packages, interface methods . The following table lists the CosNamingCreate role packages, interface methods:
Package Interface methods
javax.naming Context.createSubcontext
org.omg.CosNaming NamingContext.bind_new_context
CosNamingDelete
Users who are assigned the CosNamingDelete role can destroy objects in the name space, for example byusing the JNDI destroySubcontext method and CosNamingCreate operations. As a default policy, Subjects are not assigned this role.
Table 4. CosNamingDelete role packages and interface methods . The following table lists the CosNamingDelete role packages and interface methods:
Package Interface methods
javax.naming Context.destroySubcontext
org.omg.CosNaming NamingContext.destroy
Important: The javax.naming package applies to the CosNaming JNDI service provider only. All of the variants of a JNDI interface method have the same role mapping.
If the caller is not authorized, the packages listed in the previous tables exhibit the following behavior:
javax.naming
This package creates the javax.naming.NoPermissionException exception, which maps NO_PERMISSION from the CosNaming method invocation to NoPermissionException.
org.omg.CosNaming
This package creates the org.omg.CORBA.NO_PERMISSION exception.

Users, groups, or the ALL_AUTHENTICATED and EVERYONE special subjects can be added or removed to or from the naming roles from the WebSphere Application Server administrative console at any time. However, you must restart the server 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.

If a user is assigned a particular naming role and that user is a member of a group that is assigned a different naming role, the user is granted the most permissive access between the role that is assigned and the role the group is assigned. For example, assume that the MyUser user is assigned the CosNamingRead role. Also, assume that the MyGroup group is assigned the CosNamingCreate role. If the MyUser user is a member of the MyGroup group, the MyUser user is assigned the CosNamingCreate role because the user is a member of the MyGroup group. If the MyUser user is not a member of the MyGroup group, is assigned the CosNamingRead role.

The CosNaming authorization policy is only enforced when administrative security is enabled. When administrative 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, each CosNaming function is assigned to one role only. Therefore, users who are assigned the CosNamingCreate role cannot query the name space unless they also are assigned the CosNamingRead role. In most cases, a creator needs three roles assigned: CosNamingRead, CosNamingWrite, and CosNamingCreate. The CosNamingRead and CosNamingWrite roles assignment for the creator example have been included in CosNamingCreate role. In most 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, doing so might result in unexpected org.omg.CORBA.NO_PERMISSION exceptions at runtime. Typically, J2EE applications access the name space and the identity is that of the user that authenticated to WebSphere Application Server when he J2EE application is accessed. Unless the J2EE application provider clearly communicates the expected naming roles, fully consider changing the default naming authorization policy.