Assembla ticket #30 | Author | Created on 26 Feb 2013 16:19
Provide a read only, filterable view of the key events that happened in the system.
Audit entry should contain: timestamp, user (if present) who triggered action; subject (user, if present); tags; action; group context (if applicable); details as free form string.
user fields should have displayed name and entityId stored
group should have path and displayed name stored
We need to have a separate table for storing the events, perhaps with additional dictionary mini tables to allow for fast filtering. Data in this table should be disconnected with the rest of the schema, i.e. no relations, records are set in stone.
API to retrieve the filtered list of events. Filtering as defined below in UI part.
We need to have an lightweight and async mechanism (internal API) to produce audit events from engine and higher level endpoints code.
In console a view allowing to browse audit log. Classic Grid with events, plus possibility to filter them by: tags, action, user, subjectm date range.
In future we may add capability to see some of the audited events in upman or in home.
The initial set of audited events can be small and include:
creation & disposal of a login session (tags: Authn)
creation & removal of entity (tags: Users)
creation & removal of identity (tags: Users)
creation & removal of group (tags: Groups)
creation, update and removal of credential definition (tags: Authn)
Assembla ticket #30 | Author | Created on 26 Feb 2013 16:19
Provide a read only, filterable view of the key events that happened in the system.
Audit entry should contain: timestamp, user (if present) who triggered action; subject (user, if present); tags; action; group context (if applicable); details as free form string.
user fields should have displayed name and entityId stored
group should have path and displayed name stored
We need to have a separate table for storing the events, perhaps with additional dictionary mini tables to allow for fast filtering. Data in this table should be disconnected with the rest of the schema, i.e. no relations, records are set in stone.
API to retrieve the filtered list of events. Filtering as defined below in UI part.
We need to have an lightweight and async mechanism (internal API) to produce audit events from engine and higher level endpoints code.
In console a view allowing to browse audit log. Classic Grid with events, plus possibility to filter them by: tags, action, user, subjectm date range.
In future we may add capability to see some of the audited events in upman or in home.
The initial set of audited events can be small and include:
creation & disposal of a login session (tags: Authn)
creation & removal of entity (tags: Users)
creation & removal of identity (tags: Users)
creation & removal of group (tags: Groups)
creation, update and removal of credential definition (tags: Authn)