Grouper Developers Forum

[Kathryn Huxtable <>]

Yes, the namespace approach scopes well and maps naturally onto what  
(I think) people are likely to want to do.

-K

On Apr 28, 2008, at 3:00 PM, Michael R. Gettes wrote:

> I am in favor of the schema-less approach and what you describe
> is the namespace managed approach i have been advocating for
> some time.  +1 to this idea.
>
> /mrg
>
> On Apr 28, 2008, at 7:58, Owen Cliffe wrote:
> > Apologies Tom, I forgot to forward this answer to the list, a  
> > slightly
> > amended version follows:
> >
> >
> > -------- Original Message --------
> > Subject: Re: Fwd: [grouper-dev] ldappc
> >
> > Tom Barton wrote:
> > > I see. And rather than using the group objectclass to distinguish  
> > > groups
> > > that "belong" to Ldappc, perhaps it could be useful to mark them  
> > > in some
> > > other attribute (eduInternet2LdappcInstanceId maybe, especially
> > > recognizing that some sites wish to run multiple instances of  
> > > Ldappc,
> > > each "owning" their own slice of the grouper db).
> >
> > I think a custom attribute would be a sensible default way of
> > segregating provisioned LDAP groups between different ldappc
> > provisioning instances (we already use this technique with grouper  
> > group
> > attributes  to simplify the process of synchronizing external group  
> > data
> > into grouper).  However as you say later there are going to be cases
> > where people are unable or reluctant to add extra schemas (we have  
> > this
> > problem with our AD setup).
> >
> > Perhaps one approach would be to use a custom attribute/schema by
> > default  but  then also
> > allow users to manually specify the set of groups to compare with an
> > LDAP base, filter and scope.  That way users with more unusual setups
> > should be catered for (with the caveat that the user would need to  
> > make
> > sure that the sets of groups managed  by each instance were  
> > disjoint).
> > That way users could seperate instances by objectClass, ou, or even  
> > by
> > cn.  An extreme example might be different ldappcs which provision
> > different grouper stems into a flat hierarchy into the same DN: one
> > provisions root:stem1:...  and matches/deletes groups with
> > cn=root:stem1:* and another provisions root:stem2:... and matches  
> > groups
> > with  cn=root:stem2:*.
> >
> > Notionally each LDAPPC provisioning "session" then contains:
> > - A grouper search of  groups/stems to provision
> > - *An LDAP search of which groups to manage/delete
> > - A binding from grouper/ldap groups for the above groups with an
> > assumption that the binding will produce ldap groups which match the
> > LDAP search and that no other provisioning sessions will produce LDAP
> > groups which match the LDAP search.
> >
> > Any such changes might open up the possibility of provisioning  
> > conflicts
> > but so long as  users are made aware of the risks of mis-configuring
> > provisioning  I think the extra flexibility would be beneficial.
> >
> > As an aside, I might be wrong but I didn't notice a way of binding an
> > LDAP group
> > attribute statically for generated groups (only from an existing  
> > grouper
> > group attribute), If one could say have a binding in the config   
> > for all
> > provisioned
> > groups which set "arbitraryAttributeX=arbitraryValueY" on groups  
> > which
> > were provisioned that might be a useful generalisation of the
> > eduInternet2LdappcInstanceId you suggest above.
> >
> > > Of course, you probably only get full value from Ldappc if the DSA's
> > > schema is extended, the way things are now.
> > Agreed, however we really appreciated the ability to use ldappc  
> > without
> > having to extend our group schema (we don't use  eduPerson inside our
> > LDAP either).
> >
> >
> > Regards,
> > --Owen
> > --
> > Owen Cliffe                    Systems & Networks Administrator
> > Bath University Computer Services            University of Bath
> > Tel: 01225 386047