Deciding Between Groups and Roles

The functionality of the groups and roles mechanisms overlap somewhat. Both mechanisms have advantages and disadvantages. Generally, the roles mechanism is designed to provide frequently required functionality more efficiently. Because the choice of a grouping mechanism influences server complexity and determines how clients process membership information, you must plan your grouping mechanism carefully. To decide which mechanism is more suitable, you need to understand the typical membership queries and management operations that are performed.

Advantages of the Groups Mechanism

Groups have the following advantages:

• Static groups are the only standards-based grouping mechanism. Static groups are therefore interoperable with most client applications and LDAP servers.

• Static groups are preferable to roles for enumerating members.

  If you only need to enumerate members of a given set, static groups are less costly. Enumerating members of a static group by retrieving the member attribute is easier than recovering all entries that share a role. In Directory Server, significant performance improvements have been made for large multi-valued attributes. Equality matching and modify operations on these attributes are greatly improved, specifically in relation to static groups. Membership testing for group entries has also been improved. These improvements remove some of the previous restrictions on static groups, specifically the restriction on group size.

  Directory Server also provides group membership directly in user entries, with the isMemberOf operational attribute. This feature applies to static groups only but includes nested groups. For more information, see Managing Groups in Oracle Fusion Middleware Administration Guide for Oracle Directory Server Enterprise Edition.

• Static groups are preferable to roles for management operations such as assigning and removing members.

  Static groups are the simplest mechanism for assigning a user to a set or removing a user from a set. Special access rights are not required to add the user to the group.

  The right to create the group entry automatically gives you the right to assign members to that group. This is not the case for managed and filtered roles. In these roles, the administrator must also have the right to write the nsroledn attribute to the user entry. The same access right restrictions also apply indirectly to nested roles. The ability to create a nested role implies the ability to pull together other roles that have already been defined.

• Dynamic groups are preferable to roles for use in filter-based ACIs.

  If you only need to find all members based on a filter, such as for designating bind rules in ACIs, use dynamic groups. Although filtered roles are similar to dynamic groups, filtered roles trigger the roles mechanism and generate the virtual nsRole attribute. If your client does not need the nsRole value, use dynamic groups to avoid the overhead of this computation.

• Groups are preferable to roles for adding or removing sets into or from existing sets.

  If you want to add a set to an existing set, or remove a set from an existing set, the groups mechanism is simplest. The groups mechanism presents no nesting restrictions. The roles mechanism only allows nested roles to receive other roles.

• Groups are preferable to roles if flexibility of scope for grouping entries is critical.

  Groups are flexible in terms of scope because the scope for possible members is the entire directory, regardless of where the group definition entries are located. Although roles can also extend their scope beyond a given subtree, they can only do so by adding the scope-extending attribute nsRoleScopeDN to a nested role.

Advantages of the Roles Mechanism

Roles have the following advantages:

• Roles are preferable to dynamic groups if you want to enumerate members of a set and find all sets of which a given entry is a member. Static groups also provide this functionality with the isMemberOf attribute.

  Roles push membership information out to the user entry where this information can be cached to make subsequent membership tests more efficient. The server performs all computations, and the client only needs to read the values of the nsRole attribute. In addition, all types of roles appear in this attribute, allowing the client to process all roles uniformly. Roles can perform both operations more efficiently and with simpler clients than is possible with dynamic groups.

• Roles are preferable to groups if you want to integrate your grouping mechanism with existing Directory Server functionality such as CoS, Password Policy, Account Inactivation, and ACIs.

  If you want to use the membership of a set “naturally” in the server, roles are a better option. This implies that you use the membership computations that the server does automatically. Roles can be used in resource-oriented ACIs, as a basis for CoS, as part of more complex search filters, and with Password Policy, Account Inactivation, and so forth. Groups do not allow this kind of integration.

Restricting Permissions on Roles

Be aware of the following issues when using roles:

• The nsRole attribute can only be assigned by the roles mechanism. While this attribute cannot be assigned or modified by any directory user, it is potentially readable by any directory user. Define access controls to keep this attribute from being read by unauthorized users.

• The nsRoleDN attribute defines managed role membership. You need to decide whether users can add or remove themselves from the role. To keep from modifying their own roles, you must define an ACI to that effect.

• Filtered roles determine membership through filters that are based on the existence or the values of attributes in user entries. Assign the user permissions of these attributes carefully to control who can define membership in the filtered role.