Audit Logging
The Audit Logging interface allows administrators to configure and test log messages along with defining retention policies.
Audit log settings are configured globally for all applications and modules. Audit logs can be sent to a file, database, and/or a Syslog server. The database connection for audit is configured in the RapidIdentity CLI Menu and can be the same as or different from the configuration database.
 |
Audit Types
The Audit Types interface allows administrators to configure the format configuration of the audit logs and optionally target Amazon Kinesis Data Streams for the audit logs.
Administrators can include and configure one or more of the following targets:
File-based target
Database-based target
Syslog based
Amazon Kinesis
Note
Alerts, Activity, and Reporting in the UI all depend on having a Database target enabled.
 |
Selecting Enable File-Based Audit Log allows administrators to select JSON or XML as a format for one-line events, or Legacy as the format for multi-line XML; Legacy corresponds to the format prior to RapidIdentity 2017.11.14.
If Enable Syslog Based Audit Log is enabled, administrators will need to define the syslog host, syslog port, syslog protocol, and syslog facility for these audit logs.
If File-Based Audit Log was initially enabled in RapidIdentity 4.3 or earlier, this option will have defaulted to Legacy; otherwise, it will default to JSON.
If Database Logging is enabled, administrators can send or submit a sample log message at any time by clicking the Send Test Log Message text. The event will be sent to all configured audit targets and can help verify that the audit configuration is correct.
JSON Example
Note
The examples shown have been formatted for human readability, when in reality they are one line per record with no newlines or indenting injected.
{
"id": "89eab250-c598-11e7-bf85-005056c00008",
"productId": "net.idauto.audit.product.saml",
"moduleId": "net.idauto.audit.module.idp",
"actionId": "net.idauto.audit.idp.action.authentication",
"timestamp": "2017-11-09T21:54:19.764Z",
"targetSystem": "DIRECTORY",
"targetId": "521d7b81-ac96-4ae4-bbd2-d346d826c5d6",
"target": "jdoe",
"hostIp": "192.168.11.101",
"perpIp": "127.0.0.1",
"perpId": "521d7b81-ac96-4ae4-bbd2-d346d826c5d6",
"perpDN": "CN=John Doe,OU=employees,OU=people,OU=idauto,DC=ad2k8,DC=local",
"successful": "true",
"ext.User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36",
"successful": "true",
"ext.json_data": {
"errorMessage": "Incorrect Username and/or Password",
"policy": {
"id": "47bf6460-3421-11e7-8178-005056c00008",
"name": "Password Only",
"version": 26
},
"methods": ["username"],
"failedStep": "password"
}
}XML Example
Note
The examples shown have been formatted for human readability, when in reality they are one line per record with no newlines or indenting injected.
The Legacy format and the XML format are the same content, but the Legacy format does include newlines and indenting.
<record id="a21e6010-c598-11e7-bf85-005056c00008">
<product>
<id>
net.idauto.audit.product.saml
</id>
<displayName>
Federation
</displayName>
</product>
<module>
<id>
net.idauto.audit.module.idp
</id>
<displayName>
Federation Identity Provider
</displayName>
</module>
<action>
<id>
net.idauto.audit.idp.action.authentication
</id>
<displayName>
IdP Authentication
</displayName>
<classification>
<id>
net.idauto.audit.common.classification.normal
</id>
</classification>
<categories>
<category>
<id>
net.idauto.audit.common.category.systemUsage
</id>
</category>
</categories>
</action>
<hostIp>
192.168.11.101
</hostIp>
<perpetratorId>
521d7b81-ac96-4ae4-bbd2-d346d826c5d6
</perpetratorId>
<perpetratorDN>
CN=John Doe,OU=employees,OU=people,OU=idauto,DC=ad2k8,DC=local
</perpetratorDN>
<perpetratorIp>
127.0.0.1
</perpetratorIp>
<targetSystem>
DIRECTORY
</targetSystem>
<targetId>
521d7b81-ac96-4ae4-bbd2-d346d826c5d6
</targetId>
<target>
jdoe
</target>
<successful>
false
</successful>
<properties>
<property key="json_data">
<values>
<value>
{
"errorMessage": "Incorrect Username and/or Password",
"policy": {
"id": "47bf6460-3421-11e7-8178-005056c00008",
"name": "Password Only",
"version": 26
},
"methods": ["username"],
"failedStep": "password"
}
</value>
</values>
</property>
</properties>
<timestamp>
2017-11-09 15:55:00
</timestamp>
</record>Retention Policies
Retention policies allow administrators to configure which audit events are logged and when logging into a database, how long each event will be retained before purging. These are predefined with licensing and can be edited, but new ones cannot be added.
 |
Retention policies are organized hierarchically. "Inherit" results in applying whatever policy is described in the next level up.
The top-most level of the Retention Policy hierarchy is displayed in the Products table. Administrators can modify the policy configuration by clicking Edit.
 |
Administrators can select Always Retain, Do Not Log, Retain For, or Inherit for the Policy. After the policy type is selected, click Save.
Drilldown allows administrators to provide granular retention policies to any of the listed RapidIdentity products. As administrators continue to drill down with each product retention policy, a breadcrumb trail appears to illustrate the overall hierarchy. Clicking on the breadcrumb trail words allows administrators to return to that level of the retention policy hierarchy.
 |
Once the most granular level of the retention policy is reached, the Drilldown option disappears. Retention policies accessed through the Drilldown button can be edited by clicking Edit and the same interface to edit the parent-level of the retention policy becomes visible.
 |