Grouper Developers Forum

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

--On 04 February 2009 16:56 -0500 Chris Hyzer 
<>
 wrote:

> At this point here are my issues regarding auditing, transactions, and
> context ids:
>
>
>
> 1.       I have the tables created and hibernated for user-auditing.  The
> cols (maybe not all, but a good sample), are here under audit type table,
> and audit entry table.  Let me know if something doesn't look ok
>
> https://wiki.internet2.edu/confluence/display/GrouperWG/Auditing
I wonder if we should have a context table which has:
1) the context id
2) an audit type and / or label
3) all the stuff from the audit table which doesn't change within a single 
context i.e.
- loggedInMemberId
- envLabel
- grouperEngine
- grouperVersion
- serverHost
- userIpAddress

Someone creating an arbitrary transaction (including in GSH) should either 
be able to reference custom audit types, or at least label the context.

actAsMemberId could potentially change within a teansaction and each 
audited action within a context may have its own audit type.

> 2.       For the user auditing and context ids, I need some threadlocal
> space to keep the id and if the caller is auditing (if so, inner calls
> shouldn't audit, if not, inner calls should audit).  I want to use the
> hibernateSession transaction callbacks (natural place for it since the
> auditing needs to be in a transaction anyways).  Here are the changes
> required for people using the callbacks (shouldn't be many).  We also
> have a GrouperTransaction callback that I could also expose this to:
>
> FROM:
> public Object callback(HibernateSession hibernateSession) {
>
>
>
> TO (hibernate handler bean will tell you if caller is auditing, give you
> context id, etc):
>
> public Object callback(HibernateHandlerBean hibernateHandlerBean)
>
>     throws GrouperDAOException {
>
>   HibernateSession hibernateSession =
> hibernateHandlerBean.getHibernateSession();
>
>
>
> FROM:
>
> HibernateSession.callbackHibernateSession(GrouperTransactionType.READ_WRI
> TE_OR_USE_EXISTING, new HibernateHandler()
>
>
>
> TO (false means caller is not auditing, so inner calls should, true would
> be opposite):
> HibernateSession.callbackHibernateSession(GrouperTransactionType.READ_WRI
> TE_OR_USE_EXISTING, false, new HibernateHandler()
>
>
> Note: If there is a case where the outer transaction doesn't need a
> contextId, then we need another param or an overload or something…  GSH
> transactions might be a reason, but GSH transactions are different and
> wont get contextid's anyways
>
>
>
> 3.       I think we should drop the created_by and modified_by cols in
> the grouper tables (e.g. grouper_groups and grouper_stems), since these
> will be maintained in the user auditing.  The user auditing will tell you
> who the logged_in user is, who the act_as user is, etc.  I think the
> created_by and modified_by is just who the grouperSession belongs to, so
> it might even be meaningless.  Does anyone use these, or does anyone
> object?  Oh yeah, I need to update those in memberChangeSubject calls
> potentially when merging subjects…
Did we say auditing would be optional...
> 4.       Speaking of, I want to use member_uuid for the created_by and
> modified_by in the audit record.  Is it a reasonable assumption that
> everyone logging in to the UI or WS is a subject resolvable by subjectId
> or subjectIdentifier???  If they don't have a grouper_members record, I
> will add them.
I believe the API will create a Member for anyone who logs in.
> 5.       I think we can drop the loader log table and use the audit log
> table instead.  Would anyone be sad about that decision.  I picture
> having web services to query the logs, and the UI potentially, so if
> there were fewer tables, then we would get that functionality in all of
> the logs
>
> 6.       I have everything working for a group type add to do the user
> auditing correctly.  It has been pretty time consuming, more than I
> originally thought, so bear with me, but it will take some time to crank
> this out for all grouper operations (similar to hooks).
>
>
>
> Thanks,
>
> Chris
>
>
>
>
>
>
>
>
>
> From: Emily Eisbruch 
> [mailto:]
> Sent: Wednesday, February 04, 2009 3:59 PM
> To: Grouper Dev
> Subject: [grouper-dev] Action Items: Grouper Call 4-Feb-09
>
>
>
>
> New Action Items
>
>
>
> [AI] (Everyone) will send to the list ideas on DB tables & triggers for
> audit / notification / as complete solutions / as infrastructure.
>
> https://wiki.internet2.edu/confluence/display/GrouperWG/Auditing
>
>
>
> [AI] (Chris) will email the group regarding auditing, transactions, and
> context IDs.
>
>
>
> Carry Over Action Items
>
>
>
> [AI] TomZ will send to the list a summary of the strands in the group's
> discussion on notification.
>
> https://wiki.internet2.edu/confluence/display/GrouperWG/LDAPPC+Next+Steps
>
>
>
> [AI] Chris will update the wiki page on auditing and notification.
>
> https://wiki.internet2.edu/confluence/display/GrouperWG/Auditing
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Emily Eisbruch, Technology Transfer Analyst
>
> Internet2
>
>
>
> office: +1734-352-4996 | mobile +1-734-730-5749
>
>
>
> Spring 2009 Internet2 Member Meeting
>
> April 27-29, Arlington, Virginia
>
> events.internet2.edu/2009/spring-mm/



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