This document is a draft-in-progress for discussion by and contribution
from members of MACE-Dir.
Groups Implementer’s Guide
Abstract: This document offers recommendations to institutions embarking on the implementation of groups in the Enterprise Directory.
1. Introduction
Many institutions of higher education have successfully deployed some
form of a directory service containing information about key people constituents
(faculty, staff, students, alumni, affiliates) and are leveraging the directory
as an information provider to directory-enabled applications and consumer
systems. For many sites, the next step with directories will be to populate
group information in the directory. The intent of this document is to provide
practical advice to directory architects and application developers who
are deploying group-based solutions for access control, messaging, customization,
etc. via the enterprise directory. The previously published document "Practices
in Directory Groups" [1], in which the concepts and principles referred
to in this document are discussed with great clarity, should be considered
required reading before going further.
2. The Planning Process
Most directory architects will have given much consideration to the
issues related to populating groups in the directory with an appreciation
for the many uses of groups in terms of authorization, messaging, and customization.
Nonetheless, an individual institution’s decision to allocate resources
to a groups deployment may very likely be driven by some immediate and
pressing need – e.g., we can’t roll out the portal until we have groups
defined. The challenge for directory architects is to strive for that delicate
balance between a pure abstract design and a more pragmatic one that defers
to reality as dictated by immediate application requirements and institutional
needs. That said, the implementation plan and design should address the
requirements of the specific application(s) driving the project, but should
also consider the collective needs, concrete and envisioned, of the multitude
of applications and systems that can make use of group definitions now
and in the future.
2.1 General Recommendations
The recommendations set forth in this document are based on the work of several institutions of Higher Ed who are at various stages in the deployment of groups at their respective institutions. While the factors that play into the numerous decisions that need to be made along the way vary widely from site to site, there are nonetheless some general principles that planners should keep in mind.
Keep it Simple. Do not build in sophisticated features that will compromise the performance and flexibility of the implementation. While it is important to consider all the various groups that may need to be defined in the directory, it is not necessary to populate them from day one.
Keep it flexible. To the extent possible, try not to rely too heavily on vendor-specific features and capabilities of the directory server in use. This does not mean you should not take advantage of useful features in your DSA of choice, e.g. the referential integrity plugin in iPlanet, but consider the implications for your implementation if you were to consider migrating to another platform. Similarly, try to avoid hinging your groups deployment on specific application requirements that will not be extensible to other applications and that will require rearchitecting the solution if the original application is replaced.
Watch this space. MACE-Dir is closely following the work of groups deployments in Higher Ed and working with industry representatives to be able to make recommendations to sites working with groups in the directory.
Plan. Even though you should not try to deliver an implementation that meets every possible need, actual and perceived, for groups in the directory, you should try to consider the myriad uses for groups to avoid any crucial oversight that will send you back to the drawing board.
Test. Test for performance. Test for security. Test for usability.
Consider a pilot group if appropriate to ensure the envisioned needs were
the actual ones.
2.2 Information Gathering
During the planning process, most sites will encounter the same set
of complex issues that will require informed decision-making by planners.
These "knots", or decision points, are introduced in this section and discussed
in painful detail in the following one. There are no easy answers or blanket
recommendations. Weighing the various factors (application needs/requirements/capabilities,
directory server limitations/capabilities, and institutional processes/policies/requirements)
that feed into the many decisions is a black art which may result in tightly
crossed fingers as implementation progresses.
2.2.1 Applications
A suggested starting point for a project to deploy groups in the directory is to inventory existing applications and systems, either home grown or purchased, that could make use of groups definitions. The concrete requirements and capabilities of existing and soon-to-be-deployed applications with respect to groups in the directory will be one of the chief determinants in how groups are implemented. Examples of common applications would be:
Web Servers: granting access to web pages based on group membership.
Calendaring products: Sharing calendar data with members of a given
group.
Group Messaging: Using a group as an email distribution list.
Portals/Course Management systems: Customizing display and features
based on group membership.
Once this inventory is complete, an exploration into the specific requirements and capabilities in support of groups for each application should be undertaken. Among the questions that need to be answered are:
Answering these questions will call out the many decision points that
will need to be tackled along the way. Specific application requirements
will play a large role in determining how groups are represented, created,
and maintained in the directory. If there is a critical application that
will leverage the deployment of groups in the directory, it is imperative
that its requirements be well laid out prior to the design stage. Implementers
will very likely find themselves in the position of having applications
with differing requirements concerning groups deployment and may very well
have to implement multiple solutions to the same problem.
2.2.2 Group Creation and Maintenance Tools
How groups will be created and maintained in the directory is another important area to consider. Presumably, most sites have a set of automated tools that collect data about users from source systems of record and feed that data into the enterprise directory. Groups whose membership is defined based on some institutional piece of data would most likely be created and updated in conjunction with this process. For example, if a site has a set of scripts for processing course registration updates fed from a student registration system, then it would be reasonable to tie into this process for maintaining the membership of a course group.
Other important issues to consider are:
Each directory server has its own set of capabilities and restrictions regarding groups. For example, some directory servers (iPlanet, Novell) support dynamic groups whereas others do not. Some servers have a limit on the number of members of a static group. Others may not have strictly enforced requirements or limits, but may offer recommendations regarding performance. All these factors need to be considered when embarking on a deployment. Also take into consideration how likely it is that you will continue with this particular directory server. If there is a movement afoot to consider migrating to another directory server, be wary of investing in specific capabilities of the product currently in use. Similarly, do not let limitations of the product in use force you into poor design choices if it is likely that you will be switching to another vendor.
3. Decision Points
The following issues are the ones that have the most potential to stymie directory architects in their groups deployment. As said earlier, there are no easy answers or blanket recommendations here. Many of the decisions involve weighing the tradeoffs between performance, flexibility, consistency with other implementations, and institutional needs. The important point is that the decision process be informed and that directory architects understand the risks, tradeoffs, ramifications, and possible consequences of their decisions.
There are several ways of representing group information in the directory, each with its own advantages and disadvantages. Bear in mind that it might, and very likely will, make sense to use different types of group representation for different types of groups. A site might chose to define all groups created automatically based on some known piece of data (enterprise groups, e.g. all members of a given course) as dynamic groups and groups created manually (e.g. personal groups or delegated admin groups) as static groups. Furthermore, the same group may be represented in two different ways in the directory. Consider a site with the both the need to maintain many static groups and to quickly and easily determine all the groups a user is a member of. To meet these needs, it may be reasonable to both define the group as a static group and to use forward references on user entries to indicate groups they are a member of. Below we consider the different types of group representation and under what circumstances they might be selected.
A dynamic group is one whose membership is computed dynamically by evaluating an ldap url or search filter. We will assume for this discussion that we are talking about a group with an object associated with it in the directory. For groups whose membership is determined by some attribute stored in person objects in the directory, dynamic groups are an attractive choice at first glance. There is no need to maintain membership lists, which for sites who need to maintain many large groups such as "all students", "all active users", "all staff", can consume significant disk space and introduce considerable replication traffic. Dynamic groups are typically far easier to maintain. When a user is added to the system he/she may automatically be a member of several groups based on specific attribute values. There is no need to maintain logic to add the user to groups or to update group objects as data about the user changes; the changes are automatic as a result of adding, modifying, or deleting attributes that determine group membership dynamically. Because of this, dynamic groups go a long way towards solving the problem of referential integrity as well (see Section 3.9).
There are some very compelling reasons, then, to consider using dynamic groups for enterprise groups. On the other hand, dynamic groups are not such a good choice for groups whose membership is maintained manually, e.g. myFriends, ChessClub, NTAdministrators, etc. For groups like this there is typically a need to specify a general-purpose ACL to control who can make modifications to the group (e.g. only users whose DNs are in the groupOwner attribute can modify the group). For dynamic groups, modifying group membership would entail modifying attributes on individual entries which is a difficult if not impossible task to legislate. Another drawback to dynamic groups is that they offer no easy way of determining all the groups a given user is a member of. If you have applications that exert this requirement, consider using static groups or using forward references via isMemberof in conjunction with dynamic groups.
Perhaps the most practical reason not to employ dynamic groups is quite simply the lack of support for them in purchased applications. There are very few applications today that ship with support for dynamic groups. Many applications will, however, make authorization determinations based on an ldap url or search filter; the functionality is the same, but the ease of use is not. Consider having to tell dozens of Web administrators the filters required to restrict access based on departmental membership vs. telling them to supply the department name or number in the group name field.
Many off-the-shelf applications support static groups only and this will probably be the most compelling reason for going with static groups. Static groups are groups whose membership is enumerated via a membership attribute which is multi-valued and contains the DNs of member objects, typically people. Most directory servers ship with objectclasses of groupOfNames, whose members are specified in the member attribute and/or groupOfUniqueNames, whose members are specified in the uniqueMember attribute. We suggest you use groupofUniqueNames if your vendor applications include support for it or (even better) if they allow you to specify what objectclasses and attributes should be used in determining group membership.
For performance reasons, many directory servers have a suggested or hard-coded limit on the number of members allowed in a static group. It is critical that you determine if such limits or recommendations are in place for your directory server and factor that in. For example, some sites work around Active Directory’s current restriction of a maximum of 5000 members in a group by nesting groups. (Nested groups introduce their own set of complications; see section 3.8). Even if there are no recommendations or restrictions concerning the number of members in a group, it is prudent to consider how applications will be accessing group membership and the impact on performance. At the very least, be sure to index appropriately – an equality index on the membership attribute is a must.
Another factor to consider when implementing static groups is referential integrity, ensuring that group membership is updated appropriately with individual user status changes. (See section 3.9) Drop/Add, termination, and departmental transfers are just a few of the changes in a user’s status that may affect their membership in groups. With dynamic groups, many of these changes are reflected automatically as attributes on the user’s entry are modified. Some directory servers, notably iPlanet, include tools for implementing referential integrity. These are generic in nature and may not be sufficient to reflect institutional practice. If you are using static groups, the utilities you develop to maintain them may need to incorporate some mechanism for ensuring referential integrity. Alternatively, consider writing a utility that generates group membership listings and ensures that the members of each group are still active and meet the criteria for group membership.,
A forward reference, similar in spirit to a dynamic group, is the assignment of an attribute on a user’s entry indicating the groups that user is a member of. Consider using the attribute isMemberOf under the following circumstances:
3.1.4 Spatially Defined Groups
A spatially defined group is one whose members are located in a given
branch of the directory. Given the trend toward flat directory structures,
it is likely that groups of this nature would be broad categories of users,
e.g. people, affiliates, applicants, etc. Spatially defined groups are
similar to dynamic groups in that membership can be determined by evaluating
an ldap url or filter. If you have structured your directory in such a
way that there are branches of users based on some common criteria, you
are probably already making some group-type determinations based on entry
location.
The decision around where to place groups in the directory will hinge primarily on two issues: privacy and group maintenance. If your privacy requirements are relatively straightforward and a simple access control policy is appropriate for all your groups, then consider creating a "Groups" branch in your directory and populating all groups in this branch. If on the other hand, there is a need for varying access control requirements for different types of groups, then it would be prudent to take a more granular approach.
Personal groups, in particular, will probably have privacy requirements different from enterprise groups. These groups may need to be hidden from enterprise applications making access control or other determinations based on group membership. Locating personal groups under the group owner’s person entry is an effective way of hiding them from such processes. This placement also facilitates maintenance, as when a user’s entry is removed from the directory, all the groups he/she owned are removed as well. However, this type of approach is predicated on the assumption that personal groups are truly personal and are of value only to the owner. In reality, many personal groups (e.g. Project-related groups, informal clubs) are of interest to all the members of the groups and the group’s usefulness will persist in the absence of its owner. Unless you have a policy to remove all a user’s groups when the user is removed, there is not much to be gained from this approach as opposed to setting up a separate branch for personal groups or defining them with a custom objectclass and setting ACLs accordingly.
Application requirements will have to be consulted as well. Most applications
will allow you to specify a search base for looking up groups. Some will
allow more granular control and allow you to specify more than one base
and what order to search in. Well-behaved applications will also allow
you to specify a "service DN" to bind as when consulting group information.
That is, the application will bind as a given user to whom special access
rights to group info have been granted in the directory. This allows a
directory administrator greater control in configuring which groups the
application will be able to see when making group-based determinations.
Alas, there are vendors who do not provide such flexibility which may lead
to placement of groups required by a given application in its own branch
of the directory. Ultimately, to meet the differing security and privacy
needs of various applications,implementers might find it unavoidable to
create separate branches for different categories of groups.
It is generally agreed that group names should be meaningful and indicate something about their membership. Groups that are created and maintained automatically by institutional data feeds should have a name descriptive of the membership criteria, e.g. the name of a department, a course ID, etc. This may require some manual effort up front in the cases where there is no formulaic method of computing a name (e.g Deans, ChairPersons, etc.). The assumption is that somewhere down the road a user will be performing some administrative function for granting access and will not want to enter a cryptic group id to do so.
A chief concern for sites implementing personal groups is the issue of namespace collision. The most common approach to dealing with this is to use a unique identifier, typically userid, in the name of the group. For instance, at Boston College, all personal groups are prefixed by ‘userid.’; e.g. smith.myfriends and jones.myfriends. At CMU they are prefixed by "cmuname:". This approach may have privacy implications if your personal groups are publicly visible and you choose a name-based identifier as a component of the personal group name. Forewarned is forearmed. Another possibility to avoid namespace collision is to create personal groups under the owner’s person entry (see Section 3.2).
Another factor to consider when considering naming conventions is the consumer systems that this information may be replicated to. Those systems or applications may have restrictions in place concerning length of names and allowed characters that should be factored in up front if possible.
There are two separate but related contexts for privacy with respect to groups. One concerns the privacy of the group itself as an entity and to what applications, systems, and services its existence should be known. The other concerns the privacy of the members of the group itself and under what circumstances, if any, their membership in a given group should be revealed.
Once again, simple is best. Consider a single groups branch to which anonymous access is denied and access is granted selectively via service DNs to those applications that require it. However, some applications will only bind anonymously when consulting the directory for group information. A possible workaround to this, if the DSA supports it, is to specify access control that only allows for anonymous access to the groups branch from the IP address(es) of the server hosting the application(s). Alternatively, if the application in question allows you to specify the filter to be used in finding groups, consider using a custom objectclass for the groups of interest to the application in question. A different level of access control could be set on group objects with this objectclass ensuring that the application in question can access the groups it needs to without compromising the security of others. Of course, this level of application configuration may not always be possible. Furthermore, there may be a need to allow the general public to locate a group in the directory to retrieve information about it. For instance, groups that are representative of clubs and other organizations may have phone book data about them that should be available to the general public. In this case, creating a groups branch and securing it with a general purpose access control policy may not be sufficient. Setting a privacy attribute on the group object that indicates it should be hidden from anonymous access may be sufficient to respect the privacy of the group for a phone book type application, but may have the undesired effect of hiding it from applications who need to access group info for access control information.
[incomplete]
3.5 Synchronization/Replication across Environments
[to be written]
3.6 Group Creation and Maintenance
[to be written]
3.6.1 What Groups to Create [to be written]
3.6.3 Aging/Expiring groups
[to be written]
3.7 Group-enabled messaging
[to be written]
If the concept of groups is to model collections of people then it doesn’t take very long before we start thinking about the concept of groups within groups, which can be seen in all but the simplest of organization trees. For example, assume you have a group which consists of all the people who are affiliated with the School of Computer Science. Next assume you want to create a group that represents everyone in the College of Arts and Sciences. You would likely simply add the School of Computer Science group into the College of Arts and Sciences group (along with groups for the other schools).
This sort of thought processes is highly logical and maps directly to how we would think about such groups. It does not however really convey what we are trying to express, which is that the College group should be a union of the membership of each of the School groups within that college. A first glance it would seem these two concepts, groups within groups and union of groups, should be synonymous; however problems soon arise.
3.8.1 Problems with Nested Groups
The largest problem arises when there are other attributes, besides membership, associated with groups such as privacy information (who may view the group and/or its members, for example) or contact information for the group. Assume that groups have a simple flag on them that determines if they are visible to the public or not (via some group viewing program). Now re-examine the example given above. If the School group has its flag set to invisible and the College group has its flag set to visible what membership will you see? Does the school’s or the college’s flag take precedence? As you can imagine, as more of these types of attributes are associated with a group, and as you begin seeing groups within groups within groups, etc., the question of which attributes are "inherited" or which take precedence becomes exponentially more complicated.
Another problem with nested groups is how to represent and manage them. The iPlanet directory, for example, has special object classes for representing groups and special plugins for managing them. These plugins ensure that you do not create things like cyclic groups (i.e. group A contains group B, group B contains group C, and group C contains group A). This capability is attractive, however reliance on a directory server’s specific features may make migrating to a new server a difficult task and may require application rewriting. If your DSA provides no such protection mechanism, then the utilites you develop to create and maintain groups will have to have logic to prevent cyclically nested groups. Applications will require special logic for dealing with nested groups.
3.8.2 Alternative Solutions
Given the problems associated with nested groups, discussing alternative solutions makes sense. Two such alternatives are presented here. The first alternative is to simplify your groups. The biggest problem listed above comes from tagging on non-membership attributes with the group. If you can use a simple group definition which includes nothing but membership listing and a group name then this problem goes away. At that point you can probably safely use nested groups.
The second alternative works if your goal is to be able to generate unions, intersections and/or complements of group memberships, which is the functionality most people are after when they begin considering nested groups. Looking at the problem in this way it becomes obvious that what you really want to do is perform basic set math on the memberships of groups. The LDAP protocol has no provisions for this functionality, therefore it must be done outside the actual directory. Consider creating a library which performs these group math operations and distributing it to your programmers .
Since the library is something you will likely write yourself it can do almost anything you want, however here are some basic features that have been helpful at other universities. First, the basic set math functions listed above; unions, intersections and complements. In the case of group math the complement can be thought of as the result of group A subtracted from group B such that only members of group B which are not in group A are in the result. Second, it is important to represent your arguments in the same manner as your result. This means that if the result of your union method is a set then the method should take as arguments two sets, not something like LdapResultSets. This allows for method calls to be chained so that you can model more complex rules such as all those in groups A and B but not those in groups C and D.
The ability to represent this type of logic becomes an extremely powerful authorization mechanism for those applications using the group math library. No longer do the services need to be tied to a static list of people that can use it, or tied to a small set of attributes.
3.8.3 When there is no other way
So the group math library gives you a lot of flexibility and helps
you create some powerful applications, however, there are times when nested
groups are going to be required. There are usually two instances when this
is the case. First, there may be legacy applications which have come to
depend on them. Second, you may have a purchased application which requires
them. If either of these are the case you’ll likely need to support nested
groups. Here are some tips for doing so.
First and foremost, be wary of using DSA-specific functions unless you plan on staying with the same DSA for the foreseeable future. Using these functions can lock you into the DSA and make switching to another one very difficult. However, if you are planning to stick with the same DSA for an extended period of time, a choice not all that uncommon, using those DSA specific functions can be used to speed development and lessen the logic which needs to be in your applications.
Second, give developers a standard library to work with your groups. This library should encompass the rules and policies around your groups. For example, if you don’t allow cyclic groups in your directory then the library should ensure this. If you do allow cyclic groups this library should be able to correctly traverse them, visiting each group only once.
3.9 Referential Integrity
[to be written]
3.10 Group Math
[to be written]
It is generally agreed that group math operations should be performed
by some intelligence that mediates between the application and the actual
groups in the directory (see Appendix A, Grouper; discussion of VT’s Group
math support).
4. Summary
[to be written]
5. References
[1] Tom Barton, "Practices in Directory Groups", http://middleware.internet2.edu/dir/groups/rpr-nmi-edit-mace_dir-groups_best_practices-1.0.html
6. Acknowledgements
Thanks to members of MACE-Dir for their input into this document.
7. Author Information
Eileen Shepard
Information Technology
Boston College
Eileen@bc.edu