Grouper Developers Forum

["Michael R. Gettes" <>]

This is still not clear to me.  Exactly what kinds of queries don't
respond well?  I was pointed to your previous posts and I didn't see
any examples of exactly what you were trying to do and the problems  
seen.
I remain curious.  Especially with statements like:

"but we found the directory server does not like large numbers of  
multi-valued attributes"

/mrg

On Apr 3, 2008, at 9:44, Steve Edgar wrote:
> We form the cn a bit differently, in that we do not use the source  
> name, and use ID and group name.  If ...
>
>
>
> ... was a member of ...
>
> example:admin:it:staff
>
> We'd get ...
>
>         cn: 
> :admin:it:staff
>         hasMember: 
>
>         isMemberOf: example:admin:it:staff
>        cornelledugroupreadpriv=GrouperAll
>
> I also write a small static group entry, which does contain any  
> group members, in a separate branch for each group.  This allows a  
> quick response to the query "list all groups".  There, I also write  
> an LDAP URL for each group, in hopes of supporting dynamic groups  
> for vendor apps.
>
> An unknown is compatibility with vendor apps.  If the vendor app  
> allows the specification of a search, singleton pairs should work.   
> We've hooked up Bedework with success.  If the vendor app supports  
> dynamic groups, I think that will work, but it is untested.  If the  
> vendor app only support static groups, you are hosed.
>
> Another trade off with singleton pairs is provisioning time.  It is  
> slower than static groups, because you have to touch a lot of entries.
>
> I've got a few classes whipped together which provision singleton  
> pairs, using the same algorithm used by LDAPpc.  It's crude, but  
> works, and is enough for us to test with.
>
> We looked into singleton pairs because of limitations we found with  
> existing directory schema when trying to get fast query response  
> times, scalable support for private groups, and support for very  
> large groups.  Singleton pairs is the only thing we've found so far  
> which does all 3 of these.
>
> Static groups easily allows scalable private groups, but we found  
> the directory server does not like large numbers of multi-valued  
> attributes.  Query response time decreases as static group size  
> increases.  Very large groups (over about 85K members if you are  
> using EPPN entries), will not load, are super slow.
>
> Using isMemberOf under uid entries allows for fast query response  
> times, but we do not have a scalable way to allow for private  
> groups.  If someone knows a good way to do this, we are quite  
> interested.
>
> We are not all that keen on singleton pairs, but it may be our best  
> alternative for providing a fast, secure, simple and consistent  
> AuthZ solution.
>
> -- Steve.
>
> On Apr 2, 2008, at 11:31 PM, Michael R. Gettes wrote:
>
> > Frankly, i don't get it.
> >
> > /mrg
> >
> > On Apr 2, 2008, at 3:00 PM, Kathryn Huxtable wrote:
> >
> > > 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