Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] beta testing real-time provisioning ?

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] beta testing real-time provisioning ?


Chronological Thread 
  • From: Tom Zeller <>
  • To:
  • Subject: Re: [grouper-dev] beta testing real-time provisioning ?
  • Date: Thu, 12 Jan 2012 11:55:33 -0600

>> >>  dn : cn=groupA,ou=groups
>> >>  member: cn=memberA,ou=people
>> >>  member: cn=memberB,ou=people
>> >>  member: cn=groupB,ou=people
>> >
>> > Why still have cn=groupB as member of cn=groupA, if you already
>> > included all of cn=groupB's members in cn=groupA?
>>
>> For humans or applications that may be interested in the hierarchical
>> structure of group memberships. Not a convincing argument, hence my
>> survey.
>
> OK, but those people would only see the hierarchical structure of the
> groups themselfs (not the memberships derived from that), since all
> members of groupB will appear to be (direct/immediate) members of
> groupA, when in fact they're not. So this might even lead to more
> questions down the road.
> cheers,

I think SCIM decided to use "type" meta-data to describe whether a
membership was "direct" or "indirect". An "indirect" membership is
considered to be read-only from the perspective of the viewer. I do
not know how to represent SCIM in ldap, however, although someone is
supposed to be working on the binding. Perhaps an ldap representation
of the depth of a membership would be interesting work for mace-dir to
figure out, edu[In]DirectMember or whatever. Maybe prefix values with
a sort-order, e.g. member: {0} directMember, {1} indirectMember, {2}
secondCousin.

Even so, the binary (zero or infinity, direct or indirect) notion of
memberships is two-dimensional (tall vs spikey), where actual
memberships have a path, as in the social graph (bushy), which varies
with time, so going down the road is 4 dimensional, at least.

Thinking of memberships as a 4 dimensional nodal graph might help
discover memberships that a particular node _should_ have, based on
proximity or strength of nearby links or somesuch.

TomZ



Archive powered by MHonArc 2.6.16.

Top of Page