Grouping Directory Data and Managing Attributes

The directory information
tree organizes entries hierarchically. This hierarchy is a type of grouping
mechanism. The hierarchy is not well suited for associations between dispersed
entries, for organizations that change frequently, or for data that is repeated
in many entries. Directory Server groups and roles offer more flexible
associations between entries. The class of service (CoS) mechanism enables
you to manage attributes so that the attributes are shared between entries.
This sharing is done in a way that is invisible to applications.

Static, Dynamic, and Nested Groups

Directory Server distinguishes between two main kinds of groups;
static groups and dynamic groups. Nested groups and mixed groups

Although groups may identify members anywhere in the directory, the
group definitions themselves should be located under an appropriately named
node such as ou=Groups. This makes them easy to find, for
example, when defining access control instructions (ACIs) that grant or restrict
access when the bind credentials are members of a group.

Static Groups

Static groups explicitly name their member entries. For example, a group
of directory administrators would name the specific people who formed part
of that group, as shown in the following illustration.

The following LDIF extract shows how the members of this static group
would be defined.

Dynamic Groups

Dynamic groups specify a filter and all entries that match the filter
are members of the group. These groups are dynamic because membership is defined
each time the filter is evaluated.

Imagine, for example, that all management employees and their assistants
were situated on the 3rd floor of your building, and that the room number
of each employee commenced with the number of the floor. If you wanted to
create a group containing just the employees on the third floor, you could
use the room number to define just these employees, as shown in the following
illustration.

The following LDIF extract shows how the members of this dynamic group
would be defined.

Nested Groups

Nested groups use the DN of another group as the uniqueMember attribute of a static or dynamic group to place groups
inside other groups. Directory Server also supports mixed groups, that
is groups that reference individual entries, static groups, and dynamic groups.

Imagine for example that you wanted a group containing all directory
administrators, and all management employees and their assistants. You could
use a combination of the two groups defined earlier to create one nested group,
as shown in the following illustration.

The following LDIF extract shows how the members of this nested group
would be defined.

Nested groups are not the most efficient grouping mechanism. Dynamic
nested groups incur an even greater performance cost. To avoid these performance
problems, consider using roles instead.

Managed, Filtered, and Nested Roles

Roles are an entry grouping
mechanism. Roles enable you to determine role membership as soon as an entry
is retrieved from the directory. Each role has members,
or entries that possess the role. As with groups, you can specify role members
explicitly or dynamically.

Directory Server supports the following three types of roles:

Managed roles. Explicitly
assign a role to member entries.

Filtered roles. Automatically
make entries members if the entries match a specified LDAP filter. In this
way, the role depends on the attributes contained in each entry.

Nested roles. Enable you
to create roles that contain other roles.

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.

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.

Managing Attributes With Class of Service

The Class of
Service (CoS) mechanism allows attributes to be shared between entries. Like
the role mechanism, CoS generates virtual attributes on the entries as the
entries are retrieved. CoS does not define membership, but it does allow related
entries to share data for coherency and space considerations. CoS values are
calculated dynamically when the values are requested. CoS functionality and
the various types of CoS are described in detail in the Sun Java System Directory Server Enterprise Edition 6.2 Reference.

The following sections examine the ways in which you can use the CoS
functionality as intended, while avoiding performance pitfalls:

CoS generation always impacts performance. Client applications
that search for more attributes than they actually need can compound the problem.

If you can influence how client applications are written, remind
developers that client applications perform much better when looking up only
those attribute values that they actually need.

Using CoS When Many Entries Share the Same Value

CoS provides substantial benefits for relatively low cost when you need
the same attribute value to appear on numerous entries in a subtree.

Imagine, for example, a directory for MyCompany, Inc. in which every
user entry under ou=People has a companyName attribute.
Contractors have real values for companyName attributes
on their entries, but all regular employees have a single CoS-generated value, MyCompany, Inc., for companyName. The following
figure demonstrates this example with pointer CoS. Notice that CoS generates companyName values for all permanent employees without overriding
real, not CoS-generated, companyName values stored for
contractor employees. The company name is generated only for those entries
for which companyName is an allowed attribute.

Figure 4–3 Generating CompanyName With Pointer
CoS

In cases where many entries share the same value, pointer CoS works
particularly well. The ease of maintaining companyName for
permanent employees offsets the additional processing cost of generating attribute
values. Deep directory information trees (DITs) tend to bring together entries
that share common characteristics. Pointer CoS can be used in deep DITs to
generate common attribute values by placing CoS definitions at appropriate
branches in the tree.

Using CoS When Entries Have Natural Relationships

Consider an enterprise directory in which every employee has a manager.
Every employee shares a mail stop and fax number with the nearest administrative
assistant. Figure 4–4 demonstrates
the use of indirect CoS to retrieve the department number from the manager
entry. In Figure 4–5, the mail stop
and fax number are retrieved from the administrative assistant entry.

Figure 4–4 Generating DepartmentNumber With
Indirect CoS

In this implementation, the manager’s entry has a real value for departmentNumber, and this real value overrides any generated value.
Directory Server does not generate attribute values from CoS-generated
attribute values. Thus, in the Figure 4–4 example,
the department number attribute value needs to be managed only on the manager's
entry. Likewise, for the example shown in Figure 4–5, mail stop and fax number attributes need to be managed
only on the administrative assistant’s entry.

Figure 4–5 Generating Mail Stop and Fax Number With Indirect
CoS

A single CoS definition entry can be used to exploit relationships such
as these for many different entries in the directory.

Another natural relationship is service level. Consider an Internet
service provider that offers customers standard, silver, gold, and platinum
packages. A customer’s disk quota, number of mailboxes, and rights
to prepaid support levels depend on the service level purchased. The following
figure demonstrates how a classic CoS scheme enables this functionality.

Figure 4–6 Generating Servic-Level Data With Classic CoS

Avoiding Excessive CoS Definitions

Directory Server optimizes CoS when one classic CoS definition entry
is associated with multiple CoS template entries. Directory Server does
not optimize CoS if many CoS definitions potentially apply. Instead, Directory Server checks
each CoS definition to determine whether the definition applies. This behavior
leads to performance problems if you have thousands of CoS definitions.

This situation can arise in a modified version of the example shown
in Figure 4–6. Consider an Internet
service provider that offers customers delegated administration of their customers’
service level. Each customer provides definition entries for standard, silver,
gold, and platinum service levels. Ramping up to 1000 customers means creating
1000 classic CoS definitions. Directory Server performance would be affected
as it runs through the list of 1000 CoS definitions to determine which apply.
If you must use CoS in this sort of situation, consider indirect CoS. In indirect
CoS, customers’ entries identify the entries that define their class
of service allotments.

When you start approaching the limit of having different CoS schemes
for every target entry or two, you are better off updating the real values.
You then achieve better performance by reading real, not CoS-generated values.