2 Audit Engine

User profile audits cover changes to user profile attributes, user membership, resource provisioning, access policies, and resource forms.

This chapter discusses the following topics:

• Audit Engine

• Tables Used for Storing Information About Auditors

• Issuing Audit Messages

2.1 Audit Engine

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 group 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 section discusses the following topics:

• Audit Levels

• Post-Processors

• Creating Custom Post-Processors

2.1.1 Audit Levels

As mentioned earlier in this chapter, when you install Oracle Identity Manager with the Audit and Compliance module, 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 Linux) or the GenerateSnapshot.bat script (on Microsoft Windows). This script is in the OIM_HOME/xellerate/bin directory. The script examines all users in the 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 following aspects of the auditing engine:

• Level of detail for auditing

• Active triggers

• Behavior of the audit engine

• Data captured in the audit snapshot

You can specify the audit level as the value of the XL.UserProfileAuditDataCollection system configuration property in the Design Console.

See Also:

The "System Configuration Form" section of Oracle Identity Manager Design Console Guide

The following are the supported audit levels:

1. Process Task: Audits the entire user profile snapshot with the resource life cycle process

2. Resource Form: Audits user record, group membership, provisioned resources, and any form data associated with the resource and process

3. Resource: Audits the user record, group membership, and provisioned resources

4. Membership: Only audits the user record and user group membership

5. Core: Only audits the user record

6. None: Audit data is not generated or 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.

2.1.2 Post-Processors

The AUD table stores the audit metadata XML. The audit engine uses this metadata to create the snapshot XML and the snapshot changes XML. The metadata XML provides, among other things, information about the table that stores the snapshot XML and snapshot changes XML and the post-processors. After the audit engine generates the snapshot, these post-processors process the snapshot data and change XML information, and store this information in the reporting tables.

There are two types of post-processors, the internal auditor type and custom type. Internal auditor post-processors are defined in the auditor XML metadata.

2.1.3 Creating Custom Post-Processors

You can create custom post-processors to extend the functionality of the existing post-processors so that additional information can be stored in the reporting tables. Custom post-processors are not defined in the XML metadata.

To create a custom post-processor:

See Also:

• Appendix A, "Sample Code for a Custom Post-Processor"

• The "Lookup Definition Form" section of Oracle Identity Manager Design Console Guide

1. Open the Lookup Definition form of the Design Console.

2. Create a class that extends the CustomAuditDataProcessor class and implements the processAuditData method.

3. Create a lookup definition in the Oracle Identity Manager Design Console as follows:

   1. In the Code field, enter Audit.AuditorName.CustomProcessors. Here, AuditorName is the name of the auditor that the post-processor uses.

      For example, for a user profile audit, the Code field value can be Audit.UserProfile.CustomProcessors.

   2. Select the Lookup Type option.

   3. Enter the group name related to the auditor, in this case, the UPA Processors Group.

   4. Add the lookup code information.

      This is the fully qualified classpath to the class you create. The code key and Decode should be the classpath.

4. After the class is created and the lookup information is set up, place the class in a JAR file in the OIM_HOME/xellerate/JavaTasks directory.

2.2 Tables Used for Storing Information About Auditors

Information about auditors is stored in the following tables of the database:

• AUD: This table stores information about all the auditors defined in Oracle Identity Manager.

• aud_jms: This table stores information about the changes made for an auditor.

  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. This scheduled task is discussed in the "Issuing Audit Messages" section.

2.3 Issuing Audit Messages

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:

Max Records

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 (xlAuditQueue) 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.