Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] Action Items: Grouper Call 7-July-2010

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] Action Items: Grouper Call 7-July-2010

Chronological Thread 
  • From: Scott Koranda <>
  • To: Jim Fox <>
  • Cc: Shilen Patel <>, Tom Barton <>, Grouper Dev <>
  • Subject: Re: [grouper-dev] Action Items: Grouper Call 7-July-2010
  • Date: Tue, 13 Jul 2010 10:47:11 -0500


> 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.  

I think you are assuming that a point-in-time audit is only
being used for some type of cybersecurity investigation.

We want to use point-in-time auditing to determine the
preclise list of members of a particular group on a particular
day in order to determine the author list for scientific
papers written by our collaboration.

> 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.

It has meaning for our use case.

If you were a member of our collaboration (a composite group)
on a specific day then you get your name on the paper. If you
were not then your name is not on the paper.

My users care very deeply about authorship and so want a
precise and easy mechanism for point-in-time auditing.

> 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.

We will be using Grouper's database as the single source for
membership information and expect that it will deterministic
given our use model.

I cannot comment on how the flattened tables do or do not
support our use case. I just wanted to voice what appears to
be a different desired use case for point-in-time auditing.



Archive powered by MHonArc 2.6.16.

Top of Page