The audit engine collects auditing information in Oracle Identity Manager. Whenever a profile is modified, the audit engine captures the changes (the delta) and updates (or generates, if missing) the snapshots of the user and role profiles and stores these snapshots and deltas in XML format. The audit engine also contains post-processors, which, based on the generated XML, populate the reporting tables with relevant data. To maintain high performance, by default the audit engine performs these tasks in an asynchronous and offline manner by using the underlying Java Messaging Service (JMS) provided by the application server.
This chapter discusses the following topics:
As mentioned earlier in this chapter, when you install Oracle Identity Manager user profile auditing is enabled by default and the auditing level is set to Resource Form. If you change the auditing level, then you must run the GenerateSnapshot.sh script (on UNIX) or the GenerateSnapshot.bat script (on Microsoft Windows). This script is in the IDM_HOME/server/bin directory. The script examines all users in Oracle Identity Manager database and generates new snapshots based on the new auditing level.
Note:If you change the auditing level, then you must run the GenerateSnapshot script before allowing users to access the system.
You can configure the "level of detail for auditing" aspect of the auditing engine and specify the audit level as the value of the XL.UserProfileAuditDataCollection system property in the Advanced Administration.
See Also:"System Properties in Oracle Identity Manager" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for information about this system property
The supported audit levels are:
Process Task: Audits the entire user profile snapshot together with the resource lifecycle process.
Resource Form: Audits user record, role membership, resource provisioned, and any form data associated to the resource.
Resource: Audits the user record, role membership, and resource provisioning.
Membership: Only audits the user record and role membership.
Core: Only audits the user record.
None: No audit is stored.
Note:When you specify a particular audit level, all audit levels that are at a lower priority level are automatically enabled. For example, if you specify the Membership audit level, then the Core audit level is automatically enabled.
Audit level specifications are case-sensitive. When you specify an audit level, ensure that you do not change the case (uppercase and lowercase) of the audit level.
Information about auditors is stored in the following tables of the database:
AUD: This table stores metadata about all the auditors defined in Oracle Identity Manager.
aud_jms: This table stores data to be consumed by the audit engine and eventually by the auditors. It is an operational and intermediate staging table.
The key in this table is sent to the JMS. Oracle Identity Manager uses this table to control the order of the changes when multiple changes are made to the same user. You can use the Issue Audit Messages Task scheduled task to automate the reissue of messages that are not processed. For more information about this scheduled task, see "Managing the Scheduler" in Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.
Oracle Identity Manager provides a scheduled task named Issue Audit Messages Task. This scheduled task retrieves audit message details from the aud_jms table and sends a single JMS message for a particular identifier and auditor entry in the aud_jms table. An MDB processes the corresponding audit message.
The following is the attribute of this task:
Use the Max Records attribute to specify the maximum number of audit messages to be processed for a specified scheduled task run. The default value of this attribute is 400.
If there is a backlog of audit messages in the aud_jms table, then you can increase the value of the Max Records attribute. The value that you set depends on how many messages the JMS engine can process during the default scheduled task execution interval. This, in turn, depends on the performance of the application server and database. Before increasing the Max Records value, you must determine how much time is taken to process the number of audit messages in the JMS destination (oimAuditQueue) by, for example, using the administrative console of the application server. If the time taken is less than the scheduled task interval, then you can make a corresponding increase in the value of the Max Records attribute.