| Oracle® Identity Manager Audit Report Developer's Guide Release 9.0 B28760-01 |
|
 Previous |
 Next |
| Oracle® Identity Manager Audit Report Developer's Guide Release 9.0 B28760-01 |
|
Previous |
Next |
User profile audit stores information about changes in the user profile, user membership, resource provisioning, access policies, and resource forms.
This chapter discusses user profile auditing in the following sections:
By default, User Profile Audit is enabled (when installing with Audit and Compliance module) and the auditing level is set to Resource From. The auditing level is configurable and specifies the minimum level required for attestation on form data.
The XL.UserProfileAuditDataCollection keyword in System Properties in the Oracle Identity Manager Administrative and User Console determines the audit level. See Audit Levels in this chapter for more detailed information. This section covers the following topics:
The system takes a snapshot of a user profile and stores that snapshot in an audit table in the database. Oracle Identity Manager updates the snapshot any time the user data changes.
The following outline describes what constitutes a saved user profile. It also provides information about 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
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)
The snapshot for a user profile contains all the previous data for a particular user.
The snapshot and changes are saved as XML strings. Representing them in XML makes for easy readability and understanding of what events happened to update the snapshot. The following sections include examples of the XML in the snapshot and changes field in the UPA table.
The snapshot XML describes all the attributes for a given user. All the attributes are related to the user profile. The top most tag is UserProfileSnapshot. Within this tag, there are a key and version. These store user key and version information for each XML entry. Each of the subsequent tags store information about the user profile:
UserInfo: Information about the user profile itself
GroupMembership: Information about the group membership
PolicyProfile: Information about what policy allowed which resource provisioning
ResourceProfile: Information about all the provisioned resources
ResourceInstance: Information on each of the resources provisioned to the user
ProcessData: Information about the data stored in the UDFs
The following code snippet is an example of an XML snapshot.
<?xml version="1.0" encoding="ISO-8859-1" ?> - <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">2006-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">2006-01-05 17:11:56.868</Attribute> <Attribute encrypted="true" name="Users.Password" password="true">8YxO3YSKDXJLmcsKeZhUSw == </Attribute> <Attribute name="Users.Creation Date">2006-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">2006-01-05 17:12:30.299 </Attribute> <Attribute name="Groups-Users.Update Date">2006-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">2006-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">2006-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>
The snapshot changes XML describes all the changes that affect user attributes for a given transaction. All the attributes are related to the user profile. The top-most tag is Changes. Under this tag, we find all the changes made for a particular transaction. Each Change tag refers to a set of changes that affect the snapshot XML. The where attribute locates the position of the change and the Audit Engine makes the changes to the earlier snapshot XML by applying the changes.
The following extract is from an XML file containing snapshot changes:
<?xml version="1.0" encoding="ISO-8859-1" ?> - <Changes>- <Change action="insert" order="1" where="/UserProfileSnapshot/ResourceProfile/ResourceInstance[@key='74']">- <Attribute name="Users-Object Instance For User.Creation Date"> <OldValue /> <NewValue>2006-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.
Every time a snapshot of a user profile is taken, it is stored in a User Profile Audit, or 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. |
This section defines the events that trigger Oracle Identity Manager to take a user profile snapshot. As mentioned earlier, Oracle Identity Manager takes a new snapshot whenever any of the data elements that constitute the user profile snapshot change. Thus, the events that trigger the creation of a new snapshot are:
Modification to the user record (whatever the source: recon, direct, adapter, and so forth.)
Group membership change for the user
Changes in the policies that apply to the user
Provisioning of 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 (status changes, escalations, and so on.)
Creation of or updates to Process Form data
To prevent the volume of audit records to become a drain on the performance of the system, a conceptual Audit Engine performs complex data extraction, processing, and recording activity between every step of processing in Oracle Identity Manager, instead of the transactional processing. When the defined Event Triggers fire, they notify the audit engine to take a snapshot. The audit engine then performs the necessary processing offline to generate and record the audit snapshot.
This section includes the following topics:
When you install the Audit and Compliance module, User Profile Audit is enabled by default and the auditing level is set to Resource From. After upgrading or changing the auditing level to a different value, 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.
Tuning controls allow you to specify the level of detail of the auditing. These controls define the active triggers, and the working of the audit engine, and the data captured in the audit snapshot.
The audit levels are specified as a system configuration property in Oracle Identity Manager. The supported levels are:
Process Task: Audits the entire user profile snapshot together with the Resource Lifecycle Process.
Resource Form: Audits user record, group membership, resource provisioned, and any form data associated to the resource.
Resource: Audits the user record, group membership, and resource provisioning.
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, which is used by the audit engine to create the snapshot and changes XML. Apart from a lot of other information, this metadata XML provides information on the table to store the snapshot and changes XML and post-processors. Post-processors are used to process data after the audit engine generates the snapshot and changes 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 XMLs 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.
Custom post-processors are not included with the auditor itself. These are created by customers to extend the functionality or reporting of a given auditor. Custom post-processors are not defined in the XML metadata but in the lookup tables in Oracle Identity Manager.
To create custom post-processors, do the following:
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 will be using. For instance, in the case of User Profile audit, the auditor name would 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, which is the fully qualified classpath to the class you created. The code key and Decode should be the classpath. Type 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 XL_HOME/JavaTasks directory.
User profile audit uses the following tables in the database:
AUD: This table stores information on all the auditors supported by Oracle Identity Manager. Currently, only the UserProfileAudit entry is available. More auditors are planned in future releases to audit other type of entities (for example, User Groups, Resources, and so on).
AUD_JMS: This table stores the 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. With this table, Oracle Identity Manager can control the order of the changes when multiple changes are made to the same entity (in this case User). Also, 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 following tables are used for reporting using the Oracle Identity Manager reporting module:
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 the group. Currently only direct group membership is stored in this table.
UPA_RESOURCE: The information in this table includes the provisioned resources and the status change of each of the resources. This table does not include any form table information.
Oracle Identity Manager includes a scheduled task called Re-issue Audit Message Task that re-issues Audit JMS messages that were not processed because of database connectivity problems. All audit message data is stored in AUD_JMS and 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.
If any problems are found when the JMS message is picked up for processing, the JMS system will retry up to the configured number of retry times. If the message is not processed after retrying the configured number of retry times, it will end up in the Dead Letter Queue. Since the actual data is not in the JMS system, but is in another table, 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.
Once the Re-issue Audit Message Task runs, there should not be any AUD_JMS entries. If there are any AUD_JMS entries, the message itself could be corrupted or the processor of the message cannot understand it. All messages concerning the same entity (in the case of User Profile, the entity is the user key) to be updated will reside in the AUD_JMS until they are resolved. Each of the audits for a single user are performed sequentially so that the audits are logged in order of when the event happened.
You should enable the Re-issue Audit Message Task and set it to run regularly. By default, the Re-issue Audit Message Task runs daily, but you should configure a specific start date and time. The date and time specified should preferably be around times when the system is not too busy. This allows for enough time to process messages, especially if there are too many of them to process.
