| Oracle® Identity Manager Audit Report Developer's Guide Release 9.0.3 Part Number B32456-01 |
|
|
View PDF |
| Oracle® Identity Manager Audit Report Developer's Guide Release 9.0.3 Part Number B32456-01 |
|
|
View PDF |
User profile audits contain information about changes to user profile attributes, user membership, resource provisioning, access policies, and resource forms.
This chapter discusses the following topics:
By default, user profile auditing is enabled and the auditing level is set to Resource Form when you install Oracle Identity Manager with the Audit and Compliance module. The auditing level specifies the minimum level required for attestation on form data.
You configure the audit level in the System Properties page of the Administrative and User Console, using the keyword XL.UserProfileAuditDataCollection. See "Audit Levels" for details.
This section discusses the following topics:
Oracle Identity Manager takes a snapshot of a user profile, stores the snapshot in an audit table in the database, and updates the snapshot each time the user data changes. A snapshot contains all previous data for the user. In Release 9.0.3, Oracle Identity Manager generates a snapshot when an audit is created for a user, even if an initial snapshot is missing. The current snapshot is treated as the initial snapshot.
The following are the contents of a user profile and the tables that make up these components.
User Record: USR table, including all User Defined Files (UDFs)
User Group Membership: USG, UGP, and RUL information
User Policy Profile: UPP and UPD information
Note:
After changing a group name using the Administrative and User Console, the User Profile Audit tables in the database are not updated with the change until the next snapshot of the user.User Resource Profile, which consists of:
User Resource Instance: OIU, OBI , OST, and OBJ information
Resource Lifecycle (Provisioning) Process: ORC, PKG, TOS, STA, OSI, SCH , MIL
Resource State (Process) Form: UD_* (including child tables)
Oracle Identity Manager stores snapshot data as XML. XML provides a readable format for information about the events that caused a snapshot update. The following sections describe the XML in the snapshot and changes to the field in a User Profile Audit (UPA) table.
The snapshot XML file describes all attributes related to a user profile. The topmost element in this file is UserProfileSnapshot. This element contains a user key and a version for each XML entry. Each subsequent element stores information about the user profile, as follows:
UserInfo: General information about the user profile
GroupMembership: Information about group membership
PolicyProfile: Information about the policy that allowed provisioning for a specific resource
ResourceProfile: Information about all provisioned resources
ResourceInstance: Information about each resource that is provisioned to the user
ProcessData: Information about the data stored in the UDFs
The following code snippet is an example of an XML snapshot.
Example 2-1 Snapshot Code Snippet
<?xml version="1.0" encoding="UTF-8"?>
- <UserProfileSnapshot key="202" version="1.0">
- <UserInfo>
<Attribute name="Users.First Name">Testing02First</Attribute>
<Attribute name="Users.Role">Full-Time</Attribute>
<Attribute name="Users.Disable User">0</Attribute>
<Attribute name="Users.Email">amol@thortech.com</Attribute>
<Attribute name="Users.Status">Active</Attribute>
<Attribute name="Users.Update Date">2007-01-05 17:12:25.181</Attribute>
<Attribute name="Users.User ID">TESTING02USER9</Attribute>
<Attribute name="Users.Xellerate Type">End-User</Attribute>
<Attribute name="Users.Last Name">Testing02Last</Attribute>
<Attribute name="Users.Provisioned Date">2007-01-05 17:11:56.868</Attribute>
<Attribute encrypted="true" name="Users.Password"
password="true">8YxO3YSKDXJLmcsKeZhUSw == </Attribute>
<Attribute name="Users.Creation Date">2007-01-05 17:11:56.868</Attribute>
<Attribute name="Users.Lock User">0</Attribute>
<Attribute key="1" name="Users.Updated By Login">XELSYSADM</Attribute>
<Attribute name="Users.Password Reset Attempts Counter">0</Attribute>
<Attribute key="1" name="Organizations.Organization Name">Xellerate Users
</Attribute>
<Attribute name="Users.Login Attempts Counter">0</Attribute>
<Attribute key="1" name="Users.Created By Login">XELSYSADM</Attribute>
</UserInfo>
- <GroupMembership>
- <Group key="3">
<Attribute name="Groups-Users.Creation Date">2007-01-05 17:12:30.299
</Attribute>
<Attribute name="Groups-Users.Update Date">2007-01-05 17:12:30.299
</Attribute>
<Attribute name="Groups-Users.Membership Status">Active</Attribute>
<Attribute key="1" name="Groups-Users.Updated By Login">XELSYSADM
</Attribute>
<Attribute name="Groups-Users.Membership Type">Direct</Attribute>
<Attribute key="3" name="Groups.Group Name">ALL USERS</Attribute>
<Attribute key="1" name="Groups-Users.Created By Login">XELSYSADM
</Attribute>
</Group>
</GroupMembership>
- <PolicyProfile>
- <Policy key="1">
<Attribute name="UPD_ALLOW_LIST">Res2</Attribute>
<Attribute name="Access Policies.Key">1</Attribute>
<Attribute name="Access Policies.Name">AP2</Attribute>
</Policy>
</PolicyProfile>
- <ResourceProfile>
- <ResourceInstance key="57">
<Attribute name="Users-Object Instance For User.Creation Date">2007-01-05
17:12:36.599 </Attribute>
<Attribute key="45" name="Objects.Object Status.Status">Enabled</Attribute>
<Attribute key="1" name="Access Policies.Name">AP2</Attribute>
<Attribute key="6" name="Objects.Name">Res2</Attribute>
<Attribute name="Users-Object Instance For User.Provisioned By Method">
Access Policy</Attribute>
<Attribute key="1"
name="Users-Object Instance For User.Provisioned By Login">
XELSYSADM</Attribute>
<Attribute name="Users-Object Instance For User.Provisioned By ID">1
</Attribute>
<Attribute key="AP2" name="Access Policies.Key">1</Attribute>
- <ProcessData>
- <Parent key="8">
- <FormInfo>
<Attribute key="8" name="Structure Utility.Table Name">UD_RES2_PP
</Attribute>
<Attribute key="0" name="Structure Utility.Structure Utility Version
Label.Version Label">Initial Version</Attribute>
</FormInfo>
- <Data key="54">
<Attribute name="UD_RES2_PP_B">bbbbbbbbbbbb</Attribute>
<Attribute name="UD_RES2_PP_A">aaaaaaaaaaaa</Attribute>
<Attribute key="1" name="Access Policies.Name">AP2</Attribute>
</Data>
</Parent>
- <Children>
- <Child key="9">
- <FormInfo>
<Attribute key="9" name="Structure Utility.Table Name">UD_RES2_CP
</Attribute>
<Attribute key="0" name="Structure Utility.Structure Utility Version
Label.Version Label">Initial Version</Attribute>
</FormInfo>
- <Data key="63">
<Attribute name="UD_RES2_CP_C">Entry1C</Attribute>
<Attribute name="UD_RES2_CP_D">Entry1D</Attribute>
<Attribute key="1" name="Access Policies.Name">AP2</Attribute>
</Data>
</Child>
</Children>
</ProcessData>
</ResourceInstance>
- <ResourceInstance key="74">
<Attribute name="Users-Object Instance For User.Creation Date">2007-01-05
17:22:37.597</Attribute>
<Attribute key="33" name="Objects.Object Status.Status">Provisioning
</Attribute>
<Attribute key="5" name="Objects.Name">Res1</Attribute>
<Attribute name="Users-Object Instance For User.Provisioned By Method">
Direct Provision</Attribute>
<Attribute key="1" name="Users-Object Instance For User.Provisioned By
Login"> XELSYSADM</Attribute>
<Attribute name="Users-Object Instance For User.Provisioned By ID">
XELSYSADM</Attribute>
</ResourceInstance>
</ResourceProfile>
</UserProfileSnapshot>
Changes to the original snapshot are stored in an XML file. The information in this file describes all changes that affect user profile attributes for a given transaction. The topmost element in this file is Changes. All changes that were made during a particular transaction appear under each Change element. The where attribute identifies the location of the change. The audit engine makes the changes to an earlier snapshot XML file.
The following is an XML file with snapshot changes:
Example 2-2 Snapshot Changes File
<?xml version="1.0" encoding="UTF-8"?>
- <Changes>
- <Change action="insert" order="1"
where="/UserProfileSnapshot/ResourceProfile/ResourceInstance[@key='74']">
- <Attribute name="Users-Object Instance For User.Creation Date">
<OldValue />
<NewValue>2007-01-05 17:22:37.597</NewValue>
</Attribute>
- <Attribute name="Objects.Object Status.Status">
<OldValue key="" />
<NewValue key="35">Ready</NewValue>
</Attribute>
- <Attribute name="Objects.Name">
<OldValue key="" />
<NewValue key="5">Res1</NewValue>
</Attribute>
- <Attribute name="Users-Object Instance For User.Provisioned By Method">
<OldValue />
<NewValue>Direct Provision</NewValue>
</Attribute>
- <Attribute name="Users-Object Instance For User.Provisioned By Login">
<OldValue key="" />
<NewValue key="1">XELSYSADM</NewValue>
</Attribute>
- <Attribute name="Users-Object Instance For User.Provisioned By ID">
<OldValue />
<NewValue>XELSYSADM</NewValue>
</Attribute>
</Change>
- <Change action="update" order="2"
where="/UserProfileSnapshot/ResourceProfile/ResourceInstance[@key='74']">
- <Attribute name="Objects.Object Status.Status">
<OldValue key="35">Ready</OldValue>
<NewValue key="33">Provisioning</NewValue>
</Attribute>
</Change>
</Changes>
Information from the UPA table is normalized into UPA_USR, UPA_FIELDS, UPA_RESOURCE, and UPA_GRP_MEMBERSHIP for ease of querying for reporting purposes.
When Oracle Identity Manager takes a snapshot of a user profile, it stores the snapshot in a UPA table. The structure of this table is as described in Table 2-1.
Table 2-1 Audit Table Structure
| Field | Value |
|---|---|
|
Entry ID |
Key for the audit record. |
|
User Key |
Key for the User whose user snapshot is recorded in this entry. |
|
From Date |
Date the snapshot entry became effective. |
|
To Date |
Date the snapshot entry was no longer effective. In the case of the entry representing the current User Profile, the To data is set to NULL. |
|
Delta |
The XML representation of changes only. |
|
User Profile Snapshot |
The XML representation of the User Profile snapshot. |
|
Source |
The source of the entry. The username of the user responsible of the change in addition to the API used. |
|
Signature |
This column is for customers to sign the Snapshot for non-repudiation. |
When any data elements in the user profile snapshot change, Oracle Identity Manager to takes a new user profile snapshot. The following events trigger the creation of a new snapshot:
Modification to the user record of any kind, for example, by recon, direct, adapter, and so on
Group membership change for the user
Changes in the policies that apply to the user
Provisioning a resource to the user
De-provisioning of a resource for the user
Any provisioning related event for a provisioned resource:
Resource status change
Addition of provisioning tasks to the provisioning process
Updates to provisioning tasks in the provisioning process, for example, status changes, escalations, and so on
Creation of or updates to Process Form data
To prevent the volume of audit records from affecting performance, an audit engine performs complex data extraction, processing, and recording. The audit engine works between every step of processing in Oracle Identity Manager, instead of during transaction processing. When a trigger for a defined event fires, the audit engine takes a snapshot and performs offline processing to generate and record the snapshot.
The rest of section discusses the following topics:
User profile auditing is enabled by default when you install the Audit and Compliance module, and the auditing level is set to Resource Form. After changing the auditing level, you should run the GenerateSnapshot.sh script on Linux or the GenerateSnapshot.bat script on Windows. This script examines all users in the Oracle Identity Manager database and generates new snapshots based on the auditing level.
Note:
After changing the auditing level, be sure to run theGenerateSnapshot script before allowing users to access the system.You can specify the level of detail for auditing, including the active triggers, the behavior of the audit engine, and the data captured in the audit snapshot.
You specify audit levels as a system configuration property in Oracle Identity Manager. The supported levels are:
Process Task: Audits the entire user profile snapshot with the resource lifecycle process.
Resource Form: Audits user record, group membership, provisioned resources, and any form data associated with the resource.
Resource: Audits the user record, group membership, and provisioned resources.
Membership: Only audits the user record and user group membership.
Core: Only audits the user record.
None: No audit is stored.
Note:
Audit level specifications are case-sensitive.The AUD table stores the audit metadata XML. The audit engine uses the metadata to create the snapshot XML file and the XML file for changes to the snapshot. The metadata XML provides, among other things, information about the table that stores the snapshot, the XML file for changes, and post-processors. The post-processors process data after the audit engine generates the snapshot and change XML and stores it in the auditor table.
There are two types of post-processors, the internal auditor type and custom type. The internal auditor post-processors are defined in the auditor XML metadata. For instance, the user profile auditor has an internal post-processor that normalizes the XML filess into the reporting tables: UPA_USR, UPA_FIELDS, UPA_GRP_MEMBERSHIP, and UPA_RESOURCE. These tables are used by the reporting module to generate the appropriate reports.
You create custom post-processors to extend the functionality or reporting of a given auditor. Custom post-processors are not defined in the XML metadata. You define them in the lookup tables in Oracle Identity Manager.
To create custom post-processors:
Create a new class that extends from the CustomAuditDataProcessor class and implements the processAuditData method.
Create a new Lookup Definition in the Oracle Identity Manager Design Console as follows:
Call the code Audit.AuditorName.CustomProcessors, where AuditorName is the name of the auditor that the post-processor use.
For example, for a user profile audit, the auditor name can be UserProfileAuditor.
Select the Lookup Type option.
Enter the group name related to the auditor, in this case, the UPA Processors Group.
Add the Lookup Code Information.
This is the fully qualified classpath to the class you created. The code key and Decode should be the classpath.
Enter en for the Language and US for the Country settings.
After the class is created and the lookup information is set up, place the class in a .jar file in the OIM_HOME/JavaTasks directory.
User profile audits uses the following tables in the database:
AUD: This table stores information on all the auditors that Oracle Identity Manager supports.
Currently, only the UserProfileAudit entry is available.
AUD_JMS: This table stores information about the changes made for an auditor.
Currently, only user profile changes are stored. 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 re-issue messages if they are not processed.
UPA: This table is the main table and stores all the snapshots and changes made to the user profiles.
The Oracle Identity Manager reporting module uses the following tables:
UPA_FIELDS: This table stores user profile information in a vertical format.
This table has more information than the UPA_USR table. For instance, UD fields are stored in this table as well as other fields that are not available in UPA_USR.
UPA_GRP_MEMBERSHIP: This table contains group membership for all the users in the system.
The information includes when a user was added and removed from a group. Currently only direct group membership is stored in this table.
UPA_RESOURCE: The information in this table includes provisioned resources and changes in status for each of the resources.
This table does not include any form table information.
Oracle Identity Manager includes a scheduled task named Re-issue Audit Message Task. This task re-issues audit JMS messages that were not processed because of database connectivity problems. If problems are found when the JMS message is picked up for processing, the JMS system retries up to a configured number of times. If the message is not processed after the configured number of retries, it ends up in the Dead Letter Queue.
The actual data is not in the JMS system. All audit message data is stored in AUD_JMS. A corresponding JMS message with the AUD_JMS ID is sent. When the JMS message is picked up for processing, data from AUD_JMS is retrieved. You can re-issue the message by sending the ID from AUD_JMS back to the JMS system using the Re-issue Audit Message Task.
All messages about the same entity to be updated (for a user profile, the entity is the user key) reside in the AUD_JMS until they are resolved. After the Re-issue Audit Message Task runs, there should not be any AUD_JMS entries. If there are AUD_JMS entries, the message could be corrupted or the processor of the message cannot understand it. Each audit for a single user is performed sequentially so that the audits are logged according to when the events happened.
By default, the Re-issue Audit Message Task runs daily, but you should configure a specific start date and time, preferably when the system is not too busy. This allows for enough time to process messages, especially if there are many of them. You should run this task regularly. Use Oracle Identity Manager Design Console configure a specific start date and time for the Re-issue Audit Message Task. You can also use Design Console to configure the Re-issue Audit Message Task as follows:
Configure aud_jms entries to be processed according to an identifier
Specify a specific auditor class.
Configure a threshold, in number of hours, for the age that a message must be before it is submitted to the queue.
Release 9.0.3 introduces a new system flag, XL.SendAuditJMSMessage, configurable in the system properties section of the Design Console. The default value for the flag is True. When set to False, the audit engine creates an entry in aud_jms but does not send a JMS message. When set to False, you must run the ReissueAuditMessage scheduled task to process aud_jms entries.
Table 2-2 summarizes the attributes for the ReissueAuditMessage scheduled task that you can configure with Design Console:
Table 2-2 ReissueAuditMessage Attributes
| Attribute | Values |
|---|---|
|
|
The following are valid keys:
|
|
|
The following are valid values:
|
|
|
This parameter is a threshold, in number of hours, for the age that a message must be before it is submitted to the queue. The purpose of this parameter is to allow other tasks to be completed before processing the audit records for the tasks. Default: 5 |
A new scheduled task named Process Old Audit Messages was added in Release 9.0.3. This scheduled task is reserved for future use and may be revised or deprecated in a future release. Do note enable or execute this task.
