Grouper Developers Forum

[Tom Barton <>]

Grouper design call, Wednesday, 9 Mar 2005, 1200EST (1700Z), 60 minutes

   +1-866-411-0013 (toll free US/Canada Only), or
   +1-800-392-6130 (alternate toll free US/Canada Only)
   +1-734-615-7474 (Non-US/CA, non-toll free, no dialout)
   http://edial.internet2.edu/call/0109331 for SIP
   PIN: 0109331 (followed by "#")


blair's 3 emails to grouper-dev earlier this morning form the basis for 
today's discussion. You might want to queue those up when joining the call.

agenda:

1. Internet2 Intellectual Property Framework 
<http://members.internet2.edu/intellectualproperty.html>

2. approve past minutes, AI status, agenda bash

3. finalize what's in & out for 0.5.1 & nail down the date

4. discussion of ins & outs for 0.6 & 0.6.x & nail down the date for 
0.6. Aim to finalize on our next conference call.

5. API changes

6. review any new AIs

Tom

--- Begin Message ---

• From: Tom Barton <>
• To:
• Subject: Re: [grouper-users] First thoughts on an LDAP provisioner for Grouper
• Date: Sat, 15 Jan 2005 12:00:33 -0600
• List-archive: <https://mail.internet2.edu/wws/arc/grouper-users>
• List-id: <grouper-users.internet2.edu>

Keith,

I think you've captured the essential actions of an LDAP provisioning connector, except for creating and deleting group objects. Comments on further potential functional requirements follow.

An underlying assumption here, one presumably warranted by the choice of namespace(s) for subjectIDs, is that subjectIDs of many subjects can somehow be mapped to LDAP DNs of member objects, and likewise, some group naming element can be mapped into DNs of group objects. You may need to think through whether the provisioning connector should use the Subject Interface to translate subjectIDs to DNs of member and group objects.

The provisioning connector will need to help maintain this mapping by creating or deleting groups in LDAP in addition to patching the membership lists of groups that should remain. Some attribute or naming component of the LDAP group objects created by the provisioning connector will need to be maintained based upon the group naming element used for this mapping. For example, you might use the group's 'guid' (returned by GrouperGroup.id) as the value of a 'fooEduGrouperGuid' attribute on maintained group objects, use its 'stem' to determine a location in the DIT in which to create the group object, and use its 'extension' as the group object's 'cn' attribute.

For those subjects whose isMemberOf values you maintain, you obviously have their LDAP DNs, and so you can also maintain the member or uniquemember attribute of group objects for those subjects, in addition to or instead of maintaining hasMember. This would make static group membership accessible to a large base of installed software.

The provisioning connector might also need to maintain some representation in LDAP of, or otherwise variantly behave depending on, (1) each group's access privileges (especially READ and VIEW), and (2) each group's stem and extension. That is, the privilege model used to maintain the Groups Registry may need some presentation in LDAP. This could take a variety of forms. Here's a few that come immediately to mind, just to illustrate that there's a wide range of possibilities here:

a. create group object in a location in the DIT that depends on the group's READ and VIEW priv lists or on its stem,

b. direct expression of VIEW and/or READ privilege holders in 'fooEduGroupView' and 'fooEduGroupRead' attributes on group objects which list the DNs of other objects having those privs, and which LDAP ACLs can use to enforce corresponding access privileges,

c. provisioning connector skipping groups whose access privs or naming attributes fail to match some configured filter.

And as observed several years ago in the "Practices in Directory Groups" paper, there may need to be several 'isMemberOf' type of attributes, one for each "privacy class" of who can READ the corresponding membership. A site might take this approach so that native ACLs in their LDAP directory can selectively expose isMemberOf style of membership information. This type of arrangement can benefit from a well thought out set of prviacy classes to be used both for assigning READ privilege in the Groups Registry and for mediating access in LDAP. Several different isMemberOf type attributes are used to express the membership in groups belonging to each of the several privacy classes in the site's deployment.

This plurality of 'isMemberOf' type attributes might take one of two forms:

a. a suite of different attributes residing in member objects, for example, 'isMemberOf1', ..., 'isMemberOfN', which are referenced by ACLs enforcing each privacy class, or

b. as 'isMemberOf' attributes in different subentries of member objects, each of which have additional attributes used by LDAP ACLs to mediate access. For example:

dn: <DN of member object>

dn: cn=PrivacyClass1, <DN of member object>
fooEduGroupPrivacyClass: 1
isMemberOf: <multivalued list of group identifiers>

...

dn: cn=PrivacyClassN, <DN of member object>
fooEduGroupPrivacyClass: N
isMemberOf: <multivalued list of group identifiers>

And if that well thought out and smallish set of privacy classes mentioned above isn't going to be in the picture, you could go crazy with the subentry approach, allocating one subentry for each membership, naming each subentry using the group's guid, and placing the list of DNs of objects with READ privilege in a 'fooEduGroupRead' attribute.

(It should now be clear why Grouper uses a relational database for the Groups Registry!!)

Lastly, I think that your approach of iterating over all subjects and all groups would indirectly ensure that referential integrity is maintained within the LDAP directory, at least under the assumption that all subjects and groups in the Groups Registry also appear in the LDAP directory. If not, or if some of the subtleties I mentioned above are in play, it might be necessary for the provisioning connector to explicitly maintain referential integrity.

Tom

Keith Hazelton wrote:

Here are my initial approaches to a possbile LDAP provisioner that maps Grouper information into an LDAP server. I'm hoping that Walter will come up with a provisioning framework that supercedes or incorporates anything useful here. Comments welcome.

To provision grouper information into LDAP in a periodic diff mode:

- Iterate over subjects
- Compute subject's effective memberships
- Read subject's isMemberOf values from target LDAP server
(fast&cheap)
- Compute diffs in isMemberOf value list from the two sources
- Construct & execute ldapmodify to update LDAP & remove diffs
If populating hasMember, too:

- Iterate over groups
- Compute group's direct and effective members
- Read group's hasMember values from target LDAP server
- Compute diffs in hasMember value list from the two sources
- Construct & execute ldapmodify to update LDAP & remove diffs

--- End Message ---