Each role has members, entries that possess the role. Members can be specified either explicitly (meaning each entry contains an attribute associating it with a role) or dynamically (by creating a filter that assigns entries to roles according to an attribute contained in the entry). How role membership is specified depends on the type of role. There are three types of roles:

•Managed roles create an explicit, enumerated list of members. Managed roles are added to entries using the nsRoleDN attribute.

•Filtered roles assign entries to the role depending on the attribute contained in each entry by specifying an LDAP filter. Entries that match the filter are said to possess the role.

•Nested roles create roles that contain other roles. The roles nested within the parent role are specified using the nsRoleDN attribute.

4.3.2Deciding between roles and groups

Both methods of grouping entries have advantages and disadvantages. Roles reduce client-side complexity at the cost of increased server complexity. With roles, the client application can check role membership by searching the nsRole attribute. From the client application point of view, the method for checking membership is uniform and is performed on the server side.

Dynamic groups, from an application point of view, offer no support from the server to provide a list of group members. Instead, the application retrieves the group definitions, then runs the filter. For static groups, the application must make sure the user is part of a particular UniqueMember attribute value. The method for determining group membership is not uniform.

Managed roles can do everything that static groups can do, while filtered roles can filter and identify members as dynamic groups do.

Even though roles are easier to use, more flexible, and reduce client complexity, they do so at the cost of increased server complexity. Determining role membership is more resource intensive because the server does the work for the client application.

4.3.3 About class of service

A class of service (CoS) shares attributes between entries in a way that is invisible to applications. With CoS, some attribute values may not be stored with the entry itself. Instead, they are generated by class of service logic as the entry is sent to the client application.

For example, the directory contains thousands of entries that all share the common attribute facsimileTelephoneNumber. Traditionally, to change the fax number required updating each entry individually, a large job for administrators that runs the risk of not updating all entries. With CoS, the attribute value can be generated dynamically. The facsimileTelephoneNumber attribute is stored in one location, and each entry retrieves its fax number attribute from that location. For the application, these attributes appear just like all other attributes, despite not actually being stored on the entries themselves.

Each CoS is comprised of the several entries in the directory:

•The CoS definition entry identifies the type of CoS. It is stored as an LDAP subentry below the branch it affects.

•The template entry contains a list of the shared attribute values. Changes to the template entry attribute values are automatically applied to all the entries sharing the attribute.

The CoS definition entry and the template entry interact to provide attribute values to their target entries, the entries within their scope. The value they provide depends upon the following:

•The entry's DN (different portions of the directory tree might contain different CoS).

•A service class attribute value stored with the entry.The absence of a service class attribute can imply a specific default CoS.

4.3 Grouping directory entries

49