Grouper Developers Forum

[Kathryn Huxtable <>]

We didn't get a chance to talk about this during the conference call  
today, but I wanted to get some more input.

Cornell has suggested an option for storing group memberships in LDAP  
wherein the memberships would be stored as two-tuples, rather as they  
are in the database. Cornell has their own attributes for this, but I  
think we could just use eduMember.

So, e.g. if there's a user in the example source, gmettes, who is a  
member of the group example:admin:it:staff, there would be an entry in  
a branch of LDAP of the form:

        cn: example-gmettes-example:admin:it:staff
        hasMember: uid=gmettes, ou=people, dc=example, dc=edu
        isMemberOf: example:admin:it:staff

This would create as many objects in this branch of LDAP as there are  
membership tuples, which could get large, but the individual objects  
stay very small. It shouldn't complicate or increase the size of the  
indices at all. The "cn" attribute needs to be constructed of the  
unique attributes of the tuple to avoid collisions.

This would be an advantage if, as Cornell does, you have a group with  
more than 100,000 members. It scales very well provided that your LDAP  
implementation has no silly object limit. (I think Sun Directory  
server's licensing does have such a limit, but it's not a software  
limit. Does anyone know about Oracle's Sleepycat implementation, which  
is used by both Sun and OpenLDAP? Does it perform badly if there are  
Avogadro's Number of objects (not literally, of course)?)

On the other hand, it's possible that off the self applications won't  
deal with this.

Personally, I prefer memberships to groups, but which is used at my  
former institution was conditioned by what application was being used  
and what its requirements were.

What do people think?

-K