Grouper Developers Forum

[Jim Fox <>]

> https://spaces.internet2.edu/display/GrouperWG/Flat+Memberships+Design

> > The assumption is that consumers may want to know about membership 
> > changes at a flattened level.

I could make an assumption that most consumers would want to know
the direct changes -- not flattened.  Presently openldap, AD,
and Google support nested groups.  I can't see any reason we'd
flatten memberships of groups exported to any of them.  Is there
a survey somewhere that suggests grouper users are clamoring for
flat memberships?  If there are, let those who need them suffer
the overhead.

> > we would use the same flattened representation for point in time audit

This at least doubles the space used by the flat tables, as they now 
have audit entries as well as flat table entries.  So adding the 100.000
member group as a member causes 200,000 inserts.  And when that group is 
removed as member we get 100,000 deletes and 100,000 inserts.  

The utility of the flat table as an audit tool seems overrated to
me for a couple of reasons.  A detailled point-in-time audit is rare
enough that a bit of complexity and computation would be acceptable.
An investigator probably wants the specific group that someone
was added to or removed from -- not just the resultant effective
membership.  

The very idea that a member is added to or removed from a group at
some specific time is pre-relativistic.  It does not have meaning in
our modern, cloudy world.  Applications obtain membership information
from a variety of official and legitimate sources, downstream ldap
directories, exported google groups, SAML assertions, and others.
Each of these views represents a valid membership -- and each
will be different for some time after a change to the registry.
The entire set of memberships might take a few seconds or a day
to synchronize.  So there is a time before which an entity is not
in a group; a period when the entity maybe is, maybe is not; and
a time after which the entity is in a group.  It all depends on
the client's viewpoint.


> > When the change log daemon processes an immediate membership
> > add, it runs a query to find memberships that are in the
> > grouper_memberships_all_v view and that are not in the flattened
> > memberships table.

If I add, say Bob, to my group and then, before your change daemon
comes along I remove Bob from my group, does the flat audit table
correctly show Bob's brief effective memberships?


Jim