Grouper Developers Forum

[Tom Barton <>]

To re-stir this topic in preparation for the upcoming call, here are 
some points and questions about the auditing proposal.

1. Notifications & PIT (point in time audit data). You posit a 
notification architecture that's centered around the database and its 
record of changes. An alternative is for each API instance producing a 
change to emit a notification of that change. That can work provided all 
API instances share a common serialization scheme, ie, a way so that 
recipients of their notifications can order them correctly. A way to do 
that is to grab a serial number from the DB, ie, reduce the 
architectural dependence on the DB to just that one function. Did you 
consider an approach along these lines and reject it? What are the pros 
and cons of the two approaches?

2. Although doing PIT and User Auditing in the DB may be easy, I wonder 
about the difficulty of re-integrating a logical group management action 
from its DB-level effects. Could you (or someone) illustrate how this 
would proceed in a couple of particular cases? Eg, how would you tell 
that an indirect membership was removed due to an action taken by 
$Subject at $Time?

3. I completely understand the considerable value of using triggers from 
the perspective of performance. However, this raises the prospect of 
limiting the set of RDBMS products (and their revs) supported by 
Grouper. Quite aside from whether that's a good course to take from the 
Marketing perspective, what would implementing that type of support 
realistically mean to us as a development team? Eg, in January 2011 
would we find ourselves under pressure to continue grouper's support of 
older revs of Oracle and SQL Server, older than those running in 
production at each developer's campus? Would that mean that we must run 
a series of revs of each supported RDBMS to test against? Would there be 
licensing costs the Grouper Project would need to underwrite if we're 
not piggy-backing on the license held by some developer's campus? Any 
other operating costs (servers, space, sys admin time to keep the 
required suite of RDBMS-revs running)?

Tom

Chris Hyzer wrote:
> OK, we are focusing on getting 1.4 out the door (so much so that my work 
> is done, and Im thinking about 1.5 J ).  Anyways, I did a proof of 
> concept of an easy auditing solution (auditing would be 1.5), and wrote 
> a small doc.  We don’t have to spend a lot of time discussing now, and I 
> wont be doing more work on it anytime soon, but we can mull it over in 
> the next few weeks and see if we like the idea or can come up with 
> something better…  J
>
>  
>
> https://wiki.internet2.edu/confluence/display/GrouperWG/Auditing
>
>  
>
> Feel free to leave comments on the wiki page, or if you aren’t allowed, 
> email me and I can add them for you
>
>  
>
> Regards,
>
> Chris
>
>