Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] Re: [signet-dev] Proposal for ldappc provision scoping behavior

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] Re: [signet-dev] Proposal for ldappc provision scoping behavior

Chronological Thread 
  • From: Kathryn Huxtable <>
  • To: "Michael R. Gettes" <>
  • Cc: Tom Barton <>, Grouper Dev <>,
  • Subject: Re: [grouper-dev] Re: [signet-dev] Proposal for ldappc provision scoping behavior
  • Date: Mon, 11 Aug 2008 16:38:42 -0500

And I agree with Michael on this. I don't necessarily think that a "hacky" approach is all that problematic if it's a simple prefix string. And not supplying a prefix would lead to the current behavior. -K

On Aug 11, 2008, at 4:36 PM, Michael R. Gettes wrote:

Yes, multiple COmanage instances all pointing at the same
directory. This is a useful scenario as I see it.


On Aug 11, 2008, at 17:34, Tom Barton wrote:

Michael R. Gettes wrote:
Your reflection (view) is reasonable if you only consider
things like group or permission objects going into a directory
but if you think about my person entry having attributes also
showing membership or privilege then I think your position
fails - there is only one person object representing you
so how will you manage multiple chefs cooking YOU?!?!?!
LDAPPC in the past properly handled groups in my entry
with the handling of IsMemberOf but it failed on the
eduPersonEntitlement. If this problem is fixed, then
I agree - as I noted in my response - the group and
permission objects should be in their own portion of
the tree - largely for reasons of access control at the
directory level.

My advice is to not configure multiple ldappc instances to all handle the same membership attribute (ie, using ldappc's "- memberships" parameter). Can you think of a scenario in which it is required to do so, ie, in which having a single ldappc instance provision all -memberships does not meet needs?


Archive powered by MHonArc 2.6.16.

Top of Page