1. Dynamic Groups requirements from Brown University are pretty simple:
We'll need the ability to define a dynamic group based on more or less arbitrary ldap query patterns on people objects in the People OU. A couple examples:
(&(objectClass=inetorgperson)(Type=student))
(&(objectClass=inetorgperson)(primaryaffiliation=clinical faculty)(mailstop=1117))
So a very broad filter set that allows admins in Crowd to define a group based on an ldap filter starting at a particular ou would be useful.
2. Nested Groups requirements from Brown University are much more complicated and essential:
At Brown, we have a highly nested ldap group schema for 30,000 persons and 12,000 groups on a SunOne directory server. We manage our ldap schema entirely outside of Confluence, so no person, group, or role management is necessary or desired in Confluence or Crowd. Confluence will consume centrally provisioned user and group objects, and, if possible, we want to automatically provision a Confluence space for each of the 12,000 groups. As an example, consider the courses use case:
Say the course offering Computer Science 101 for 2nd semester 2007 has 2 sections, with base groups of faculty, TAs, matriculants, auditors, etc., plus other groups derived from the base groups.
Generically:
Base groups:
ou=groups.courses.department.course_number.year.semester.section.[faculty,tas,matriculants,auditors,designers, guests]
Derived groups:
ou=Groups.courses.department.course_number.year.semester.section.instructors = faculty & TAs
ou=Groups.courses.department.course_number.year.semester.section.students = matriculants & auditors
etc.
Sample data:
CS 101 1st semester 2007, section 1:
courses.cs.101.2007.1.01.faculty
courses.cs.101.2007.1.01.matriculants
courses.cs.101.2007.1.01.auditors
courses.cs.101.2007.1.01.instructors (facutly & tas as unique members)
courses.cs.101.2007.1.01.students (matriculants & auditors as unique members)
CS 101 1st semester 2007, section 2:
courses.cs.101.2007.1.02.faculty
courses.cs.101.2007.1.02.matriculants
courses.cs.101.2007.1.02.auditors
courses.cs.101.2007.1.02.instructors (facutly & tas as unique members)
courses.cs.101.2007.1.02.students (matriculants & auditors as unique members)
CS 101 2nd semester 2007, section 1:
courses.cs.101.2007.2.01.faculty
courses.cs.101.2007.2.01.matriculants
courses.cs.101.2007.2.01.auditors
courses.cs.101.2007.2.01.instructors (facutly & tas as unique members)
courses.cs.101.2007.2.01.students (matriculants & auditors as unique members)
CS 101 2nd semester 2007, section 2:
courses.cs.101.2007.2.02.faculty
courses.cs.101.2007.2.02.matriculants
courses.cs.101.2007.2.02.auditors
courses.cs.101.2007.2.02.instructors (facutly & tas as unique members)
courses.cs.101.2007.2.02.students (matriculants & auditors as unique members)
CS 103 1st semester 2007, section 1:
courses.cs.103.2007.1.01.faculty
courses.cs.103.2007.1.01.matriculants
courses.cs.103.2007.1.01.auditors
courses.cs.103.2007.1.01.instructors (facutly & tas as unique members)
courses.cs.103.2007.1.01.students (matriculants & auditors as unique members)
CS 103 1st semester 2007, section 2:
courses.cs.103.2007.1.02.faculty
courses.cs.103.2007.1.02.matriculants
courses.cs.103.2007.1.02.auditors
courses.cs.103.2007.1.02.instructors (facutly & tas as unique members)
courses.cs.103.2007.1.02.students (matriculants & auditors as unique members)
etc...
All objects in the schema are ous except the terminal members of the tree, which are groups of unique members. The base groups (faculty, matriculants, auditors, etc.) have persons as unique members, and the derived groups (instructors, students, etc.) have groups as unique members.
So by 'nested groups,' we have long branches of ous leading to groups of people and groups of subgroups. We need to be able to assign permissions to a Confluence object to all child members of any point of the schema. For example, there may be a Confluence space for all members of CS 101 in the 1st semester of 2007, so we'll need to grant access to that space by assigning all users in the ou, from the ou level (groups.courses.cs.101.2007.1), so that any new children of that ou, be they new ous or new groups or new person objects are automatically included in the ou as soon as they show up in ldap.
Additionally, allowing a filter or wild card will be essential for some operations. For example:
Read permission: courses.cs.101.2007.1 (all members of all groups in cs 101 1st semester 2007)
Write permission: courses.cs.101.2007.1.*.instructors (instructors of cs 101 1st semester 2007
So the derived group of instructors for all sections of a course can write to an object, while students can read only.
So this raises the question of forward references, since that would be a person-based means of looking up the various groups. I can imagine a design where Crowd or Confluence base permissions on a person attribute value in the form of ou=People.uid.memberOf=courses.cs.101.2007.1.*. This may be OK for runtime use (am I a member of group x), but I think it will be more efficient in the administration side to reverse the query and allow administrators to browse the ldap tree to find the correct node, with an option of listing members of the selected set, or at least the number of users. We may or may not wind up implementing forward references for all groups. We would prefer the flexibility to not, but we could work with that as a requirement.
As if you need this to be more complicated, having an unfettered view of the ldap schema is not desired. There are groups and ous within the ldap schema that must remain private--both their membership as well as their existance, in some cases. Let's assume these will be labeled by acls in the ldap server, but that any interface that lists the schema will need to gracefully handle a case where a group may be listed, but its members may not be listable by the application.
Alternatively, there is a simpler use case of residential dorms, which are sometimes defined as groups of physical buildings. So a schema for this use case would be:
groups.dorms.cluster.building.floor.room
Sample data:
groups.dorms.undergrad_east.foo.1.112
groups.dorms.undergrad_east.foo.2.212
groups.dorms.undergrad_east.foo.3.couch
groups.dorms.undergrad_east.bar.1.guest12
groups.dorms.west.grad12.11.1141
Abundantly. Thanks for taking the time to draw out the diagrams. It made your question very easy to understand
Yep! That's the primary use-case.