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.
- 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 theALL_AUTHENTICATED
special subject so that only authenticated users can perform a read or lookup. Changing the special subject fromEVERYONE
toALL_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
- javax.naming
- This package creates the
javax.naming.NoPermissionException
exception, which mapsNO_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.