Grouper Developers Forum

["GW Brown, Information Systems and Computing" <>]

I think we need to be very clear on what we are trying to achieve with 
auditing since it impacts greatly on our approach.

Tom B. has suggested that we use reliable (guaranteed) auditing as a way of 
recording changes such that these changes can be used to drive potentially 
less reliable notifications. Effectively, if a notification fails it might 
be reconstructed / queried for by a ‘listener’ system. So, in Java, we will 
have a representation of a change which can be ‘serialised’ to the audit 
database. It should then be possible to re-constitute the Java 
representation of the change from the data in the audit database.

As I understand it auditing goes beyond who did what and when within 
Grouper. It may also be necessary to know, at any point in time, who was a 
member of a group or who had a particular privilege for a group. This was 
an important requirement for Steve Langella when discussing the future Grid 
Grouper to control access to Grid resources. It has also come up in 
discussions at Bristol.

I think that it ought to be possible to work backwards (or forwards from a 
known snapshot) to determine exactly how a group looked at a point in time. 
So, even if we don’t provide the tools to do that just now the audit logs 
should contain sufficient information to make it possible.

I am also uncomfortable with the idea of using the file system to store 
changes largely because the API can easily be run in different JVMs on 
different machines which would need to mount the same file system and be 
properly configured.

I originally suggested LOBs because big and nested membership changes might 
exceed varchar2 implementations. Many changes would fit easily into a 
standard varchar2 so an alternative would be to split larger changes across 
multiple varchar2 fields - variable according to the database 
implementation. This would also make it easier to query data. A site could 
write a tool to ‘export’ the changes as files if they prefer to use find / 
grep.

I agree we need to be careful to ensure that saving audit information 
doesn’t adversely affect performance. Auditing should be optional and we 
will need to profile +- auditing to see what impact it does have.

Gary

--On 30 May 2008 15:18 -0400 Chris Hyzer 
<>
 wrote:

> I was thinking of the auditing could be used to see who did what when
> from where.
>
>
>
> So, not considering the use of this for systems to stay in sync with
> grouper, it would be one table and the columns could be something like:
>
>
>
> log_id,
>
> timestamp,
>
> subject_id_who_made_change,
>
> source_id_who_made_change,
>
> act_as_subject_id_who_made_change,
>
> act_as_source_id_who_made_change,
>
> ip_address_of_person_who_made_change,
>
> category (e.g. group),
>
> action (insert),
>
> description (e.g. group created with name 'whatever:whatever' and
> description 'this is the des...' and friendly name 'Whatever stem:
> Whatever Group'),
>
> system (prod_ui, test_web_service, my_gsh),
>
> object_id (group_id),
>
> optional_field,
>
> optional_field2
>
>
>
> Note that the behind the scenes changes to the registry might not need to
> be added (e.g. that GrouperAll was added as a member).  Its more just
> what users / clients do from an external perspective...
>
>
>
> I agree that the table would need to auto-delete some old records, since
> these grow large.  So I would think that recreating the point in time
> wont be possible (or are we planning on working backwards?)  right?
>
>
>
> I think a requirement should be that this thing should be gentle on
> system performance.  If we are writing files, storing multiple rows, etc
> it might take a performance hit...
>
>
>
> Also, from an architecture perspective, I am all that keen on storing
> local files.  If you wanted a hot/standby redundancy setup, now the disk
> is involved, instead of the DB...
>
>
>
> Regards,
>
> Chris
>
>
>
>
>
> From: 
>
>  
> [mailto:]
>  On Behalf Of Tom
> Zeller
> Sent: Friday, May 30, 2008 2:50 PM
> To: Grouper Dev; 
>
> Subject: [grouper-dev] changelog implementation sketch
>
>
>
> Howdy folks,
>
>
>
> Based on our discussions of hooks+notifications and correspondence from
> TomB, I have sketched a changelog implementation :
>
>
>
> https://wiki.internet2.edu:443/confluence/x/lVw
>
>
>
> It's rough in places (and perhaps just plain wrong in others), some ideas
> I scraped from the list and some I just cooked up; it however represents
> my allotted time so far.
>
>
>
> Your comments are appreciated.
>
>
>
> TomZ



----------------------
GW Brown, Information Systems and Computing