Sun Java System Directory Server Enterprise Edition 6.1 Deployment Planning Guide

Grouping Directory Entries 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.

These entry grouping and attribute management mechanisms are described in detail in Chapter 8, Directory Server Groups and Roles, in Sun Java System Directory Server Enterprise Edition 6.1 Reference and in Chapter 9, Directory Server Class of Service, in Sun Java System Directory Server Enterprise Edition 6.1 Reference.

This section provides an overview of the grouping mechanisms that is sufficient to design an administrative strategy. It does not explain how the mechanisms work or how to set them up.

The section is divided into the following topics:

Static and Dynamic Groups

Directory Server distinguishes between two types of groups:

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:

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:

Advantages of the Roles Mechanism

Roles have the following advantages:

Restricting Permissions on Roles

Be aware of the following issues when using roles:

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.1 Reference.

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

Note –

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 8–6 Generating CompanyName With Pointer CoS

Figure shows the CompanyName attribute generated 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

CoS also provides substantial data administration benefits when directory data has 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 8–7 demonstrates the use of indirect CoS to retrieve the department number from the manager entry. In Figure 8–8, the mail stop and fax number are retrieved from the administrative assistant entry.

Figure 8–7 Generating DepartmentNumber With Indirect CoS

Figure shows the DepartmentNumber attribute generated
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 8–7 example, the department number attribute value needs to be managed only on the manager's entry. Likewise, for the example shown in Figure 8–8, mail stop and fax number attributes need to be managed only on the administrative assistant’s entry.

Figure 8–8 Generating Mail Stop and Fax Number With Indirect CoS

Figure shows Mail Stop and Fax Number attributes generated
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 8–9 Generating Servic-Level Data With Classic CoS

Figure shows service level data generated with Classic

One CoS definition might be associated with multiple CoS template entries.

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 8–9. 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.