Groups are often used to control access to resources or to target communications. Group attributes, memberships and privileges may change at any time with potentially important consequences, so simply knowing how a group last changed is insufficient to investigate why, for example, an individual lost access to a resource. Grouper 1.5 and above provides an audit log of high level user actions which allows administrators to understand the history of groups, group types and stems. Audit entries may be queried by object or the subject responsible for a change.
High level actions are audited. For example if a group is deleted, all of the related memberships and privileges for that group are deleted as well. But there will only be one audit entry for the group delete.
For user auditing, the following fields are stored for each user audit entry:
- Audit type
- Audit action
- Act as member id (if the caller is acting as someone else)
- Context id (associates transactions in the registry)
- Created on timestamp
- Description (paragraph) of change
- Env name (configured in grouper.properties)
- Grouper engine (GSH, UI, WS, etc)
- Grouper version
- Logged in member id
- Server host
- User IP address
- Query count (counts queries in one action for performance profiling)
- Server user name
For each action various additional data is stored, e.g. if a group was created, then the group id, group name, etc are stored
You can import/export auditing data, but this is a different file than the normal Grouper export file, with the same command. You will see two different XML files.
More information on user auditing, including gsh commands. is available.
The user audit log can be queried using the Grouper UI. Slides illustrating the UI functionality are also available.
Here is a movie(xvid codec required) demoing user auditing. Note this is from April 2009 and might be a little dated.