Dynamic and Static Groups in Oracle Internet Directory, 2 of 4

About Groups

Oracle Internet Directory enables you to assign and manage membership in two types of groups--namely, static groups and dynamic groups. Each type of group suited for a different purpose.

This section contains these topics:

Static Groups

A static group is one whose entry contains a list of members that you explicitly administer.

A static group requires you to explicitly administer its membership. For example, if a member changes his name, then you need to change that user's DN for each group he belongs to. For this reason, a static group is best suited for a group whose membership is unlikely to change frequently. Moreover, because a static group contains a list of member DNs, its footprint in the directory increases with the membership list. For this reason, it is best suited for a group whose entries take up relatively less space in the directory.

Schema Elements for Creating Static Groups

When you create the entry for this kind of group, you associate it with either the groupOfNames or groupOfUniqueNames object class.

Each of these object classes has a multivalued attribute for storing the names of group members. To assign a user as a member of a group, you add the DN of each member to the respective multivalued attribute. Conversely, to remove a member from a group, you delete the member's DN from the respective attribute. In the groupOfNames object class, this multivalued attribute is member, and, in the groupOfUniqueNames object class, it is uniqueMember.

Dynamic Groups

A dynamic group is one whose membership, rather than being maintained in a list, is computed on the fly, based on rules and assertions you specify. For example, suppose that you want to send an e-mail to all users in the ou=americas naming context. To do this, you create a dynamic group in which you specify ou=americas as the naming context of interest. You further specify that you want only e-mail addresses returned. When the e-mail application queries the directory for that particular group, the directory server computes the membership dynamically and returns the corresponding list of e-mail addresses.

To use another example, suppose you want to send an e-mail to all employees who report to a manager named Anne Smith. In this case, you do not specify a naming context, as in the previous example. Instead, you create a dynamic group specifying that you want to retrieve the e-mail addresses of all employees reporting to Anne Smith. As in the previous example, when the e-mail application queries the directory for that particular group, the directory server computes the membership dynamically and returns the corresponding list of e-mail addresses.

Note:
in this example, the e-mail application specifies that the directory server is to read the specific attributes of the members--rather than the membership lists. It does this by passing the control 2.16.840.1.113894.1.8.5.
Also, when querying for the groups that a user belongs to, the application can direct that dynamic groups, in addition to static groups, be queried. For this to happen, it passes the control 2.16.840.1.113894.1.8.7. If this control is not passed, then only static groups are queried.

See Also:
Chapter 7, "The C API for Oracle Internet Directory" in Oracle Internet Directory Application Developer's Guide

Schema Elements for Creating a Dynamic Group

When you create a dynamic group, you begin as when creating a static group--that is, you associate its entry with either the groupOfNames or groupOfUniqueNames object class. You then associate that object class with the auxiliary object class orclDynamicGroup. This auxiliary object class has various attributes in which you specify one of two methods for dynamically computing the membership of the group.

The two methods are:

Using the labeledURI attribute

When using this method, the directory server performs a typical search based on the hierarchy of the DIT. It requires you to provide a value for one of the attributes of the orclDynamicGroup object class, namely labeledURI. In this attribute, you specify the base of the query, the filters, and any required attributes. For example, suppose that you have entered the following value for the labeledURI attribute:

labeledURI:ldap://host name/"ou=MyOrganizationalUnit,o=MyCompany,c=US"??sub" 
(objectclass=person)

When you use this method, a search for the entry returns entries for all members of the group.

See Also:
The LDAP URL Format (Request for Comments 2255). T. Howes, M. Smith, December 1997; available on the World Wide Web at http://www.ietf.org for more information about how LDAP URLs are to be represented--as, for example, in the labeledURI attribute.

Using a CONNECT BY assertion

Unlike the previous method, this method relies not on the hierarchy of the DIT, but on attributes that implicitly connect entries to each other, regardless of their location in the DIT. For example, the manager attribute connects the entries of employees with those of their managers, and this connection applies regardless of the location of the employee entries in the DIT. This method uses a CONNECT BY clause in which you specify the attribute to use for building the hierarchy--for example, manager--and the starting value for such a hierarchy--for example, cn=Anne Smith.

More specifically, to use this method, you specify in the orclDynamicGroup object class a value for each of the single-valued attributes in Table 9-1.

Table 9-1 orclDynamicGroup Attributes for "Connect By" Assertions

Attribute	Description
`orclConnectByAttribute`	The attribute that you want to use as the filter for the query--for example, `manager`
`orclConnectByStartingValue`	The DN of the attribute you specified in the `orclConnectByAttribute` attribute--for example, Anne Smith

For example, to retrieve the entries of all employees who report to Anne Smith in the MyOrganizational Unit in the Americas, you would provide values for these attributes as follows:

orclConnectByAttribute=manager
orclConnectByStartingValue=

"cn=Anne Smith,ou=MyOrganizationalUnit,o=MyCompany,c=US"

You can also develop an application specifying that you want the values for a particular attribute--for example, the email attribute--of all the members.

See Also:
Oracle Internet Directory Application Developer's Guide for more information about how to develop applications that retrieve values for particular attributes

Hierarchies

Hierarchies can be either explicit or implicit.

In explicit hierarchies, the relationship is determined by the location of the entry in the DIT--for example, Group A may reside higher in the DIT than Group B.

In implicit hierarchies, the relationship between entries is determined not by the location in the DIT, but by the values of certain attributes. For example, suppose that you have a DIT in which the entry for John Doe is at the same level of the hierarchy as Anne Smith. However, suppose that, in the entry for John Doe, the manager attribute specifies Anne Smith as his manager. In this case, although their locations in the DIT are at an equal level, their rankings in the hierarchy are unequal because Anne Smith is specified as John Doe's manager.

Note:
If you create a hierarchical group, be sure that it is truly hierarchical. For example, in a true hierarchy, Group A can be a member of Group B, but Group B cannot at the same time be a member of Group A. Because the latter relationship is cyclical, a search for the members of Group A fails.
In a query based on an implicit hierarchy, the client can specify in the search request the control 2.16.840.1.113894.1.8.3. The filter in this query specifies the attribute used to build the implicit hierarchy. For example, (manager=cn=john doe,o=foo) specifies the query for all people reporting directly or indirectly to John Doe. The implicit hierarchy is based on the manager attribute. The base of the search is ignored for such queries.

See Also:
Chapter 7, "The C API for Oracle Internet Directory" in Oracle Internet Directory Application Developer's Guide

Querying Group Entries

An application can query either kind of group to do the following:

List all members of a group
List all groups of which a user is a member
Check to see if a user is a member of a particular group

In addition, you can query dynamic groups, but not static ones, for whatever member attributes you specify.

When to Use Each Kind of Group

When deliberating about which kind of group to use, you need to weigh the ease of administration against higher performance. For example, dynamic groups provide for easier administration, but cause a decrease in performance. Table 9-2 lists some things to consider when deliberating whether to use static or dynamic groups.

Table 9-2 Static and Dynamic Group Considerations

Consideration	Static Groups	Dynamic Groups
Ease of administration	More difficult to administer if group memberships are large and change frequently	Easier to use, especially when group memberships are large and change frequently
Performance	Higher level of performance because you explicitly administer the membership list	Decreased level of performance because memberships are computed on the fly
Size of footprint in the directory	Larger footprint depending on the size of group memberships	Small footprint regardless of size of group memberships