Skip to Content.
Sympa Menu

grouper-dev - group membership singleton pairs suggestion

Subject: Grouper Developers Forum

List archive

group membership singleton pairs suggestion


Chronological Thread 
  • From: Kathryn Huxtable <>
  • To: Grouper Dev <>
  • Subject: group membership singleton pairs suggestion
  • Date: Wed, 2 Apr 2008 14:00:14 -0500

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



Archive powered by MHonArc 2.6.16.

Top of Page