Grouper Users - Open Discussion List

[Tom Barton <>]

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