Network Deployment (Distributed operating systems), v8.0 > Reference > Developer detailed usage information
Naming roles
The 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 WAS. 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 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.
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.
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.
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.
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
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 AllAuthenticated and Everyone special subjects can be added or removed to or from the naming roles from the console at any time. However, 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 WAS 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 WAS, 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 in above have been included in CosNamingCreate role. In most cases, WAS 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 WAS 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.
Authorization technology
Authorizing access to resources
Use naming