Use Policies to Filter Audit Data

In addition to event-based filtering, you can use policies to select the specific information to include in the audit logs. By default, IDM safelists fields that are safe to log. To include or exclude additional fields or values, edit conf/audit.json:

Note

Although you can't edit the default safelist, IDM processes the safelist before the blocklist, so any items added to excludeIf override their safelist status:

"filterPolicies" : {
    "value" : {
        "excludeIf" : [ ],
        "includeIf" : [ ]
    }
} 
  • To specify data to exclude from audit logs, use the excludeIf property.

    • To exclude an entire field, use the field property.

    • To exclude a field that contains a specific value, use the value property.

  • To specify data to include in custom audit event logs, use the includeIf property.

    Note

    This setting has no effect on default audit event topics.

  • /_id

  • /timestamp

  • /eventName

  • /transactionId

  • /trackingIds

  • /userId

  • /client

  • /server

  • /http/request/secure

  • /http/request/method

  • /http/request/path

  • /http/request/headers/accept

  • /http/request/headers/accept-api-version

  • /http/request/headers/content-type

  • /http/request/headers/host

  • /http/request/headers/user-agent

  • /http/request/headers/x-forwarded-for

  • /http/request/headers/x-forwarded-host

  • /http/request/headers/x-forwarded-port

  • /http/request/headers/x-forwarded-proto

  • /http/request/headers/x-original-uri

  • /http/request/headers/x-real-ip

  • /http/request/headers/x-request-id

  • /http/request/headers/x-requested-with

  • /http/request/headers/x-scheme

  • /request

  • /response

  • /roles

  • /_id

  • /timestamp

  • /eventName

  • /transactionId

  • /trackingIds

  • /userId

  • /runAs

  • /objectId

  • /operation

  • /changedFields

  • /revision

  • /status

  • /message

  • /passwordChanged

  • /context

  • /provider

  • /_id

  • /timestamp

  • /eventName

  • /transactionId

  • /trackingIds

  • /userId

  • /principal

  • /entries

  • /result

  • /provider

  • /method

  • /_id

  • /timestamp

  • /eventName

  • /transactionId

  • /trackingIds

  • /userId

  • /runAs

  • /objectId

  • /operation

  • /changedFields

  • /revision

  • /_id

  • /action

  • /ambiguousTargetObjectIds

  • /entryType

  • /eventName

  • /exception

  • /linkQualifier

  • /mapping

  • /message

  • /messageDetail

  • /reconAction

  • /reconciling

  • /reconId

  • /situation

  • /sourceObjectId

  • /status

  • /targetObjectId

  • /timestamp

  • /trackingIds

  • /transactionId

  • /userId

  • /_id

  • /action

  • /eventName

  • /exception

  • /linkQualifier

  • /mapping

  • /message

  • /messageDetail

  • /situation

  • /sourceObjectId

  • /status

  • /targetObjectId

  • /timestamp

  • /trackingIds

  • /transactionId

  • /userId

  1. From the navigation bar, click Configure > System Preferences.

  2. On the System Preferences page, click the Audit tab.

    The Audit Filter Policy area displays the policies that exist in conf/audit.json.

  3. Make changes in the Audit Filter Policy area, and click Save.

A typical use case for filtering audit data by policy is to keep personally identifiable information (PII) out of the logs. To exclude a specific field from the audit logs, add the field to the filterPolicies element, as follows:

"filterPolicies" : {
    "value" : {...}
    "field" : {
        "excludeIf" : [
            "/eventTopic/objectURI"
        ]
    }
}

Consider the following entry in a sample activity log, showing a change in telephone number for user bjensen:

{
  "transactionId": "e14ee7fb-7eb5-47c2-bf72-adbc3a648241-7054",
  "timestamp": "2017-11-02T12:19:29.396Z",
  "eventName": "activity",
  "userId": "openidm-admin",
  "runAs": "openidm-admin",
  "operation": "PATCH",
  "before": {
    "mail": "bjensen@example.com",
    "givenName": "Barbara",
    "sn": "Jensen",
    "description": "Created By CSV",
    "userName": "bjensen",
    "password": {...},
    "telephoneNumber": "1234567",
    "accountStatus": "active",
    ...
    "_rev": "00000000feb030ab",
    "_id": "9dce06d4-2fc1-4830-a92b-bd35c2f6bcbb"
  },
  "after": {
    "mail": "bjensen@example.com",
    "givenName": "Barbara",
    "sn": "Jensen",
    "description": "Created By CSV",
    "userName": "bjensen",
    "password": {...},
    "telephoneNumber": "0828392836",
    "accountStatus": "active",
    ...
    "_rev": "0000000041a73089",
    "_id": "9dce06d4-2fc1-4830-a92b-bd35c2f6bcbb",
    "roles": [],
    "authzRoles": null,
    "reports": null,
    "manager": null
  },
  "changedFields": [],
  "revision": "0000000041a73089",
  "message": "",
  "objectId": "managed/user/9dce06d4-2fc1-4830-a92b-bd35c2f6bcbb",
  "passwordChanged": false,
  "status": "SUCCESS",
  "_id": "e14ee7fb-7eb5-47c2-bf72-adbc3a648241-7058"
}

To exclude bjensen's telephone number and email address from the activity log, you would add the following filter policies:

"filterPolicies" : {
    "field" : {
        "excludeIf" : [
            "/activity/before/mail",
            "/activity/after/mail",
            "/activity/before/telephoneNumber",
            "/activity/after/telephoneNumber"
        ]
    }
}

With this configuration, a similar change in the activity log appears as follows:

{
  "transactionId": "e14ee7fb-7eb5-47c2-bf72-adbc3a648241-9836",
  "timestamp": "2017-11-02T12:40:43.162Z",
  "eventName": "activity",
  "userId": "openidm-admin",
  "runAs": "openidm-admin",
  "operation": "PATCH",
  "before": {
    "givenName": "Barbara",
    "sn": "Jensen",
    "description": "Created By CSV",
    "userName": "bjensen",
    "password": {...},
    "accountStatus": "active",
    "effectiveRoles": [],
    "effectiveAssignments": [],
    "preferences": {
      "updates": false,
      "marketing": false
    },
    "_rev": "0000000041a73089",
    "_id": "9dce06d4-2fc1-4830-a92b-bd35c2f6bcbb"
  },
  "after": {
    "givenName": "Barbara",
    "sn": "Jensen",
    "description": "Created By CSV",
    "userName": "bjensen",
    "password": {...},
    "accountStatus": "active",
    "effectiveRoles": [],
    "effectiveAssignments": [],
    "preferences": {
      "updates": false,
      "marketing": false
    },
    "_rev": "00000000d6e1312d",
    "_id": "9dce06d4-2fc1-4830-a92b-bd35c2f6bcbb",
    "roles": [],
    "authzRoles": null,
    "reports": null,
    "manager": null
  },
  "changedFields": [],
  "revision": "00000000d6e1312d",
  "message": "",
  "objectId": "managed/user/9dce06d4-2fc1-4830-a92b-bd35c2f6bcbb",
  "passwordChanged": false,
  "status": "SUCCESS",
  "_id": "e14ee7fb-7eb5-47c2-bf72-adbc3a648241-9840"
}

Note

By default, the /access/http/request/headers and /access/http/response/headers fields are considered case-insensitive for filtering. All other fields are considered case-sensitive.

To specify that a value should be filtered, regardless of case, add the caseInsensitiveFields property to your audit configuration, including an array of fields that should be considered case-insensitive. Fields are referenced using JSON pointer syntax and the array of fields can be empty.

With the following configuration, the audit service excludes cookies named session-jwt and session-JWT from the log:

"caseInsensitiveFields" : [
    "http.request.cookies"
],
Read a different version of :