Filter audit data
The audit configuration (in conf/audit.json) includes a filter parameter that lets you specify what should be logged, per event topic. The information that is logged can be filtered in various ways.
The following excerpt of a sample audit.json file shows the filter element for the activity log:
"eventTopics" : {
"authentication" : { },
"access" : { },
"activity" : {
"filter" : {
"actions" : [
"create",
"update",
"delete",
"patch",
"action"
]
},
...
}To configure audit filtering in the admin UI, select Configure > System Preferences > Audit. Scroll down to Event Topics, and click the pencil icon next to the event that you want to filter. The filter tabs, Filter Actions, Filter Fields, Filter Script, and Filter Triggers, correspond to the filtering capabilities discussed here.
Filter by action
The filter actions list enables you to specify the actions that are logged, per event type. This filter is essentially a fields filter (as described in Filter by Field Value) that filters log entries by the value of their actions field.
The following configuration specifies that the actions create, update, delete, patch, and action should be included in the log, for the activity audit event topic.
"eventTopics" : {
...
"activity": {
"filter" : {
"actions" : [
"create",
"update",
"delete",
"patch",
"action"
]
},
...
}
}The list of actions that can be filtered into the log depend on the event type. The following table lists the actions that can be filtered, per event type.
| Event Type | Actions | Description |
|---|---|---|
Activity and Configuration |
|
When an object is read by using its identifier. By default, read actions are not logged. Note that due to the potential result size in the case of read operations on |
|
When an object is created. |
|
|
When an object is updated. |
|
|
When an object is deleted. |
|
|
When an object is partially modified. (Activity only.) |
|
|
When a query is performed on an object. By default, query actions are not logged. Note that, due to the potential result size in the case of query operations on |
|
|
When an action is performed on an object. (Activity only.) |
|
Reconciliation and Synchronization |
|
When a target object is created. |
|
When a target object is deleted. |
|
|
When a target object is updated. |
|
|
When a link is created between a source object and an existing target object. |
|
|
When a link is removed between a source object and a target object. |
|
|
When the synchronization situation results in an exception. For more information, see Synchronization situations and actions. |
|
|
When the target object is ignored; that is, no action is taken. |
|
Authentication and Access |
|
No actions can be specified for the authentication or the access log event type. |
Filter by field value
You can add a list of filter fields to the audit configuration, that lets you filter log entries by specific fields. For example, you might want to restrict the reconciliation or audit log so that only summary information is logged for each reconciliation operation. The following addition to the audit.json file specifies that entries are logged in the reconciliation log only if their entryType is start or summary.
"eventTopics" : {
...
"activity" : {
"filter" : {
"actions" : [
"create",
"update",
"delete",
"patch",
"action
],
"fields" : [
{
"name" : "entryType",
"values" : [
"start",
"summary"
]
}
]
}
}
...
},
...To use nested properties, specify the field name as a JSON pointer. For example, to filter entries according to the value of the authentication.id, you would specify the field name as authentication/id.
Filter with a script
Apart from the audit filtering options described in the previous sections, you can use a JavaScript or Groovy script to filter what is logged. Audit filter scripts are referenced in the audit configuration file (conf/audit.json), and can be configured per event type. The following sample configuration references a script named auditfilter.js, which is used to limit what is logged in the reconciliation audit log:
{
"eventTopics" : {
...
"recon" : {
"filter" : {
"script" : {
"type" : "text/javascript",
"file" : "auditfilter.js"
}
}
},
...
}The request and context objects are available to the script. Before writing the audit entry, IDM can access the entry as a request.content object. For example, to set up a script to log just the summary entries for mapping managed users in an LDAP data store, you could include the following in the auditfilter.js script:
(function() {
return request.content.entryType == 'summary' &&
request.content.mapping == 'systemLdapAccounts_managedUser'
}());The script must return true to include the log entry; false to exclude it.
Filter by trigger
You can add a filter and `triggers list to the audit configuration, that specifies the actions that will be logged for a specific trigger. For example, the following addition to the audit.json file specifies that only `createupdate actions are logged for in the activity log, for an activity that was triggered by a recon.
"eventTopics" : {
"activity" : {
"filter" : {
"actions" : [
...
],
"triggers" : {
"recon" : [
"create",
"update"
]
}
...If a trigger is provided, but no actions are specified, nothing is logged for that trigger. If a trigger is omitted, all actions are logged for that trigger. Only the recon trigger is implemented. For a list of reconciliation actions that can be logged, see Synchronization Actions.