HP-UX Directory Server 8.1 deployment guide

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.2 Deciding 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