WebSphere Application Server Network Deployment, Version 6.0.x     Operating Systems: AIX, HP-UX, Linux, Solaris, Windows

Naming roles

The Java 2 Platform, Enterprise Edition (J2EE) role-based authorization concept has been extended to protect the WebSphere 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 WebSphere Name Space. There are generally two ways in which client programs will result in CosNaming calls. The first is through the JNDI interfaces. The second is CORBA clients invoking CosNaming methods directly.

The following security roles exist: CosNamingRead, CosNamingWrite, CosNamingCreate, and CosNamingDelete. However, the roles have authority levels 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 have been assigned the CosNamingRead role are allowed to do queries of the WebSphere Name Space, such as through the Java Naming and Directory Interface (JNDI) "lookup" method. The special-subject Everyone is the default policy for this role.
    Table 1. 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 have been assigned the CosNamingWrite role are allowed to do write operations such as JNDI "bind", "rebind", or "unbind", plus CosNamingRead operations. The special-subject AllAuthenticated is the default policy for this role.
    Table 1. 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 have been assigned the CosNamingCreate role are allowed to create new objects in the Name Space through such operations as JNDI "createSubcontext", plus CosNamingWrite operations. The special-subject AllAuthenticated is the default policy for this role.
    Table 1. CosNamingCreate role packages, interface methods
    Package Interface methods
    javax.naming Context.createSubcontext
    org.omg.CosNaming NamingContext.bind_new_context
  • CosNamingDelete. And finally users who have been assigned CosNamingDelete role can destroy objects in the Name Space, for example using the JNDI "destroySubcontext" method, as well as CosNamingCreate operations. The special-subject AllAuthenticated is the default policy for this role.
    Table 1. 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 JNDI CosNaming 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 throws the javax.naming.NoPermissionException exception, which maps NO_PERMISSION from the CosNaming method invocation to NoPermissionException.
org.omg.CosNaming
This package throws the org.omg.CORBA.NO_PERMISSION exception.

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 anytime. 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 an 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 has been assigned a different naming role, the user will be granted the most permissive access between the role he was assigned and the role his group was assigned. For example, assume that user MyUser has been assigned the CosNamingRead role. Also, assume that group MyGroup has been assigned the CosNamingCreate role. If MyUser is a member of MyGroup, MyUser will be assigned the CosNamingCreate role because he is a member of MyGroup. If MyUser were not a member of MyGroup, he would be assigned the CosNamingRead role.

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 will 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 will not be 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. This has been changed in the release. The CosNamingRead and CosNamingWrite roles assignment for the creator example in above have been included in 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 previous one.

Although the ability exist to greatly restrict access to the Name space by changing the default policy, doing so may result in unexpected org.omg.CORBA.NO_PERMISSION exceptions 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 they access the J2EE application. Unless the J2EE application provider clearly communicates the expected Naming roles, care should be taken when changing the default naming authorization policy.

Reference topic    

Terms of Use | Feedback

Last updated: Mar 17, 2005 4:28:29 AM CST
http://publib.boulder.ibm.com/infocenter/ws60help/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/rsec_nameroles.html

© Copyright IBM Corporation 2002, 2005. All Rights Reserved.
This information center is powered by Eclipse technology. (http://www.eclipse.org)