Oracle Identity Manager provides a powerful audit engine to collect extensive data for audit and compliance purposes. You can use the audit functionality together to capture, archive, and view entity and transactional data for compliance monitoring and IT-centric processes and forensic auditing.
This chapter consists of the following topics:
Oracle Identity Manager provides auditing and historical archiving of profile information. It takes a snapshot of a profile, stores the snapshot in an audit table in the database, and updates the snapshot each time the profile data changes. In the context of profile auditing, the term snapshot means a copy taken of the entire profile data at any instant when the data is modified.
User profile audits cover changes to user profile attributes, user membership, resource provisioning, access policies, and resource forms.
This section 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. This auditing level specifies the minimum level required for attestation of form data.
You configure the audit level in the System Configuration part of the Advanced Administration by using the XL.UserProfileAuditDataCollection system property.
See Also:
"System Properties in Oracle Identity Manager" for information about the XL.UserProfileAuditDataCollection system propertyThe 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.
This section discusses the following topics:
Each time a user profile changes, Oracle Identity Manager takes a snapshot of the user profile and stores the snapshot in an audit table in the database.
A snapshot is also generated when there is a change in a user profile that must be audited, even if an initial snapshot is missing. The current snapshot is treated as the initial snapshot.
The following are the components of a user profile and the tables that store these components:
User Record: Contains the USR table, including all User Defined Fields (UDFs).
The USR table stores user attributes. When you create a user, Oracle Identity Manager adds an entry to this table.
User Role Membership: Contains the UGP table.
The UGP_USER_MEMBERSHIP_RULE column of the UGP table stores the user role membership rule.
Role Manager API method SearchRule getUserMembershipRule(String roleKey) can be used to retrieve the user membership rule from UGP table.
For more information about Role Manager APIs, see Oracle Fusion Middleware Java API Reference for Oracle Identity Manager.
Admin Role Membership: Contains the ARM_AUD table.
The ARM_AUD table defines the membership ID, admin role ID, user ID, organization, hierarchy, action, and logged-in user.
User Policy Profile: Contains the following tables:
UPD: Stores User Policy Profile data. This is a policy-centric view of the resources that are provisioned to a user.
UPP: Stores User Policy Profile-related details. This is a user-centric view of all the applicable policies for a user, and the resources they allow/deny.
Note:
When you change a role name by using Oracle Identity Self Service, the User Profile Audit (UPA) tables in the database are not updated with the change until the next snapshot of the user.User Resource Profile: This component can be divided into the following subcomponents:
User Resource Instance: Contains the OBI, OBJ, and OIU tables, as listed in Table 22-1.
Table 22-1 User Resource Instance Tables
| Table Name | Description |
|---|---|
|
OBI |
Stores resource (object) instance information. Oracle Identity Manager creates a resource instance every time a resource is provisioned. This instance stores all generic information related to that provisioned instance, including a request key (if the resource has been provisioned through a request), the corresponding process instance, and the instance status. |
|
OBJ |
Represents the resource object data, including details about the resource, such as resource name, whether or not auto-save and auto-prepopulate are set, and whether or not the resource object allows multiple instances. |
|
OIU |
Associates applicable user information to the resource object instance when provisioning takes place. In addition, it stores policy-related information for the specific resource instance. |
Resource Lifecycle (Provisioning) Process: Contains the MIL, ORC, OSI, PKG, SCH, and TOS tables, as listed in Table 22-2.
Table 22-2 Resource Lifecycle Process Tables
| Table Name | Description |
|---|---|
|
MIL |
Defines the process task definitions. Each entry corresponds to a process task. A process definition (PKG table) comprises of multiple tasks, which are a part of the various workflows in the definition. |
|
ORC |
Stores process instance information when provisioning takes place. When provisioning starts, Oracle Identity Manager generates an associated process (or workflow) instance that stores process-related information specific to the provisioning instance. |
|
OSI |
Stores information about tasks created for process instance. |
|
PKG |
Defines processes or workflows in Oracle Identity Manager, including process details such as process name, process type, descriptive field mapping, and associated resources and process forms. |
|
SCH |
Stores information related to running of a specific task instance such as the task status, status bucket, and timing of when the adapter run started or ended. |
|
TOS |
Stores atomic process information. |
Resource State (Process) Form: This information is stored in the UD parent and child tables. The UD_* tables are user-defined field tables that store the account state.
When Oracle Identity Manager takes a snapshot of a user profile, it stores the snapshot in the UPA table. The structure of the UPA table is described in Table 22-3.
Table 22-3 Definition of the UPA Table
| Column | Data Type | Description |
|---|---|---|
|
UPA_KEY |
NUMBER (19,0) |
Key for the audit record |
|
USR_KEY |
NUMBER (19,0) |
Key for the user whose snapshot is recorded in this entry |
|
EFF_FROM_DATE |
TIMESTAMP (6) |
Date and time at which the snapshot entry became effective |
|
EFF_TO_DATE |
TIMESTAMP (6) |
Date and time at which the snapshot entry was no longer effective In other words, this is the date and time at which the next snapshot entry was created. For the entry representing the latest user profile, the To Date column value is set to NULL. |
|
SRC |
VARCHAR2 (4000) |
User ID of the user responsible for the change, and the API used to carry out the change |
|
SNAPSHOT |
CLOB |
XML representation of the snapshot |
|
DELTAS |
CLOB |
XML representation of old and new values corresponding to a change made to the snapshot |
|
SIGNATURE |
CLOB |
Can be used to store a digital signature for the snapshot (for nonrepudiation purposes) |
Note:
The initial audit snapshots for default users in Oracle Identity Manager is not UTF-8 encoded. However, auditing of subsequent modifications to these users have UTF-8 encoded snapshots.When any data element in a user profile changes, Oracle Identity Manager creates a snapshot.
The following events trigger the creation of a user profile snapshot:
Modification of any kind to the user record (for example, through reconciliation and direct provisioning)
Role membership change for the user
Changes in the policies that apply to the user
Provisioning a resource to the user
Deprovisioning 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
The user profile auditor has an internal post-processor that normalizes the snapshot XML into the reporting tables: UPA_USR, UPA_FIELDS, UPA_GRP_MEMBERSHIP, UPA_RESOURCE, UPA_UD_FORMS, and UPA_UD_FORMFIELDS. These tables are used by the reporting module to generate the appropriate reports.
Table 22-4 lists the tables in the database that User profile audits use:
Note:
For more information about the User Profile Audits tables, such as column names and how to use them, refer to the schema documentation provided with Oracle Identity Manager.Table 22-4 User Profile Audit Tables
| Table Name | Description |
|---|---|
|
AUD |
Stores detailed information about all of the Auditors (for example, the User Profile Auditor) supported by Oracle Identity Manager. |
|
AUD_JMS |
Staging table that stores information about changes made as a part of any business transaction. This is an intermediate table to temporarily store data changelog data before the audit engine consumes it. When Audit messages are successfully processed, corresponding records are deleted from the table. Note: This table is not intended for end users and must not be used directly. |
|
UPA |
Main auditing table for storing all snapshots and changes made to the user profiles. |
|
UPA_FIELDS |
Stores user profile audit history changes in denormalized (vertical) format. |
|
UPA_GRP_MEMBERSHIP |
Stores groups membership history in denormalized format. |
|
UPA_RESOURCE |
Stores user profile resource history in denormalized format. |
|
UPA_USR |
Stores user profile history in denormalized format. |
|
UPA_UD_FORMS |
Together with the UPA_UD_FORMFIELDS table, contains information about changes to the user's account profile (process form). This table keeps track of the changes to the various forms, such as parent or child forms, which are being changed in any transaction. The changes to the account or entitlement attributes are stored in the UPA_UD_FORMFIELDS table. |
|
UPA_UD_FORMFIELDS |
Stores the names of account or entitlement profile fields that are modified. This table also keeps track of the old and new values of the modified fields. |
Note:
The UPA_UD_FORMS and UPA_UD_FORMFIELDS tables together store the audit trail of changes to the user's account profile in a de-normalized format. These tables can be used in various audit-related reports.
The UPA_UD_FORMS and UPA_UD_FORMFIELDS tables are populated only if the XL.EnableExceptionReports system property is set to TRUE. For more information about this property, see "System Properties in Oracle Identity Manager" in the Oracle Fusion Middleware Administering Oracle Identity Manager.
The Form Upgrade Job schedule task updates the form version to the latest active version and the form data to the value specified during the field's creation for all accounts. If this scheduled task is not run, then the form version and data is incorrect in the audit snapshot and the reporting tables.
User Profile audit data growth is based on the setting of the audit levels, and the growth can be significant in most of the deployments.
There is also a requirement to clean or archive the old user profile audit data to accommodate future growth.
You can use Audit Archival and Purge Utility to meet these requirements. See "Using the Audit Archival and Purge Utility" for detailed information about this utility.
Role profile audits cover changes to role profile attributes, role administrators, and direct subroles.
This section discusses the following topic:
Role profile auditing is determined by the value of the Level of Role Auditing system property with keyword XL.RoleAuditLevel. This property controls the amount of audit data collected when an operation is performed on a role, such as creation or modification. The supported levels are:
None: No audit data is collected. This is the default value.
Role: Creation, modification, and deletion of role is audited.
Role Hierarchy: Changes made to the role inheritance is audited.
This section discusses the following topics:
Each time a role profile changes, Oracle Identity Manager takes a snapshot of the role profile and stores the snapshot in an audit table in the database.
Oracle Identity Manager generates a snapshot when an audit is created for a role, even if an initial snapshot is missing. The current snapshot is treated as the initial snapshot.
The following are the components of a role profile and the tables that constitute these components:
UGP: Role record, including all UDFs for roles
GPG: Subrole/parent role information
When Oracle Identity Manager takes a snapshot of a role profile, it stores the snapshot in a GPA table. The structure of this table is as described in Table 22-5.
Table 22-5 Definition of the GPA Table
| Column | Data Type | Description |
|---|---|---|
|
GPA_KEY |
NUMBER (19,0) |
Key for the audit record |
|
UGP_KEY |
NUMBER (19,0) |
Key for the role whose role snapshot is recorded |
|
EFF_FROM_DATE |
TIMESTAMP (6) |
Date and time at which the snapshot entry became effective |
|
EFF_TO_DATE |
TIMESTAMP (6) |
Date and time at which the snapshot entry was no longer effective In other words, this is the date and time at which the next snapshot entry was created. For the entry representing the latest user profile, the To Date column value is set to NULL |
|
SRC |
VARCHAR2 (4000) |
Source of the entry, User ID of the user responsible for the change, and the API used to carry out the change |
|
SNAPSHOT |
CLOB |
XML representation of the snapshot |
|
DELTAS |
CLOB |
XML representation of old and new values corresponding to a change made to the snapshot |
|
SIGNATURE |
CLOB |
Can be used to store a digital signature for the snapshot (for nonrepudiation purposes) |
When Oracle Identity Manager takes a snapshot of a admin role membership profile, it stores the snapshot in the ARM_AUD table. The structure of this table is as described in Table 22-6.
Table 22-6 Definition of the ARM_AUD Table
| Column | Data Type | Description |
|---|---|---|
|
ARM_AUD_ID |
NUMBER(20) |
Admin role audit ID |
|
MEMBERSHIP_ID |
NUMBER(20) |
Admin role membership ID |
|
ROLE_ID |
NUMBER(20) |
Admin role ID |
|
USER_ID |
VARCHAR2(256 CHAR) |
User member ID |
|
SCOPE_ID |
NUMBER(20) |
Scope ID of the admin role membership |
|
INCLUDE_HIERARCHY |
NUMBER(1) |
Whether or not organization hierarchy is included |
|
ARM_AUD_EFF_FROM_DATE |
TIMESTAMP(6) |
Date from which admin role audit is effective |
|
ARM_AUD_EFF_TO_DATE |
TIMESTAMP(6) |
Date up to which admin role audit is effective |
|
USR_ACTION |
VARCHAR2(10 CHAR) |
Action of the user members |
|
USR_LOGIN |
VARCHAR2(256 CHAR) |
Login names of the user members |
When any data element in the role profile snapshot changes, Oracle Identity Manager creates a snapshot.
The creation of role profile snapshots is triggered by events that result in changes in any of the following:
Role profile data
Parent role information
Adding or revoking users or user memberships
See "Configuring Catalog Auditing" for information about catalog auditing.
This section describes how to enable and disable auditing in Oracle Identity Manager in the following sections:
To disable auditing in Oracle Identity Manager:
Set the values of User profile audit data collection level (XL.UserProfileAuditDataCollection) and Level of Role Auditing (XL.RoleAuditLevel) system properties to None, as described in "Modifying System Properties".
Disable the Issue Audit Messages Task scheduled job as described in "Disabling and Enabling Jobs".
If pending audit changes are required to be recorded in the audit tables, then disable the scheduled task after all the pending audit changes are processed.
To disable catalog auditing, set the value of the XL.CatalogAuditDataCollection system property to none.
To enable auditing in Oracle Identity Manager:
Set the values of User profile audit data collection level (XL.UserProfileAuditDataCollection) and Level of Role Auditing (XL.RoleAuditLevel) system properties to one of the levels defined in "User Profile Auditing" and "Role Profile Auditing" for user profile and role profile auditing respectively.
See "Configuring Oracle Identity Manager" for information about modifying the values of system properties.
Enable the Issue Audit Messages Task scheduled job as described in "Disabling and Enabling Jobs".
For user profile auditing, generate snapshots by running the GenerateSnapshot script as described in "Generating an Audit Snapshot" in the Oracle Fusion Middleware Developing and Customizing Applications for Oracle Identity Manager.
The following is the command-line usage of the GenerateSnapshot script:
./GenerateSnapshot.sh -username OIM_ADMIN_USERNAME -numOfThreads 8 -serverURLt3://WLS_SERVER:PORT -ctxFactory weblogic.jndi.WLInitialContextFactory[-inputFile fileWithUserKeys]
Here:
OIM_ADMIN_USERNAME is the Oracle Identity Manager administrator username.
WLS_SERVER is the Oracle WebLogic Server name.
PORT is the port number of the WebLogic Server.
To enable catalog auditing, set the value of the XL.CatalogAuditDataCollection system property to catalog.
Oracle Identity Manager introduces Lightweight Audit Engine in this release.
The Lightweight Audit engine is direct. Unlike legacy auditing, it does not have a denormalized reporting schema. It is completely independent of the legacy audit engine. For backward compatibility, Oracle Identity Manager uses both the audit engines.
Table 22-7 lists the entities supported by the lightweight audit engine and the corresponding entity operations.
Table 22-7 Entities Audited by Lightweight Audit Engine
| Entity | Operation |
|---|---|
|
User |
Create, Modify, Delete, Enabled, Disabled, Lock, Unlock, Reset Password, Change Password |
|
Role |
Create, Modify, Delete |
|
Role-User Membership |
Add, Remove, Modify |
|
Organization |
Create, Modify, Delete |
|
Organization-User Membership |
Added, Removed |
|
Policy |
Create, Modify, Delete, Enabled, Disabled |
|
Rule |
Create, Modify, Delete, Enabled, Disabled |
|
Return Value (Child) |
Create, Modify, Delete |
|
Rule-Return Value (Child) |
Add, Remove |
|
Policy-Rule Relationship |
Add, Remove |
|
Policy Violation |
Create, Modify, Delete, Enabled, Disabled |
|
Policy Violation Cause |
Create, Modify, Delete, Enabled, Disabled |
|
Scan Definition |
Create, Modify, Delete, Enabled, Disabled |
|
Scan Definition-Policy Relationship |
Create, Modify, Delete, Enabled, Disabled |
|
Scan Run |
Create, Modify, Delete, Enabled, Disabled |
|
Scan Run-Policy Relationship |
Add, Remove |
|
Scan Run-User Relationship |
Add, Remove |
|
Scan Run-Policy Violation Relationship |
Add, Remove |
|
Remediator |
Create, Modify, Delete |
|
Task Policy Violation |
Create, Modify, Delete |
When Oracle Identity Manager records the changes to an entity or relationship, it stores the data in the AUDIT_EVENT table. Table 22-8 lists the attributes of the AUDIT_EVENT table.
Table 22-8 Definition of the AUDIT_EVENT Table
| Attribute | Data Type | Description |
|---|---|---|
|
event_id |
VARCHAR2(40) |
Unique ID of the audit log event |
|
event_action |
VARCHAR2(255) |
Set of entity type actions such as CREATE, MODIFY, DELETE, ADD, REMOVE, MODIFY_RULE, and DELETE_RULE. |
|
event_date |
TIMESTAMP |
Date of event |
|
event_actor_id |
VARCHAR2(40) |
ID of the user who performed the action |
|
event_actor_name |
VARCHAR2(255) |
Name of the user who performed the action |
|
event_mechanism |
VARCHAR2(40) |
Self, Admin, Recon, Policy-Based, Request |
|
event_request_id |
VARCHAR2(40) |
If mechanism is Request, then requestId of request |
|
event_status |
VARCHAR2(1) |
Status of request S (success) or F (failure) |
|
event_fail_reason |
VARCHAR2(255) |
Descriptive reason for failed action. For example, POLICY_VIOLATION, ACCOUNT_LOCKED, and REQUEST NOT APPROVED. |
|
event_hash |
VARCHAR2(1024) |
When an audit event is created, the AuditEventManager generates a hash value based on the contents of the event like, example entity type, action, date/time and so on. The hash is encrypted and stored in event_hash.The AuditEventManager provides an API method to verify that a specific audit event's content has not been altered since the event was stored in the database. The method implementation retrieves the hash value and decrypts it. Then, the hash value is recomputed from the event's content and compared to the stored value. If the values are the same the method returns true, otherwise false. |
|
event_values_added |
CLOB |
Values added. Data is in name1=value1 name2=value2 format, where name can be a simple name (for example firstname, userMembers) or a path expression to represent complex, nested attributes (for example user.address[type=work].street) - enables SQL "contains" search |
|
event_values_removed |
CLOB |
Values removed. Data is in name1=value1 name2=value2 format, where name can be a simple name (for example firstname, userMembers) or a path expression to represent complex, nested attributes (for example user.address[type=work].street) - enables SQL "contains" search |
|
entity_type |
VARCHAR2(40) |
Type of entity |
|
entity_id |
VARCHAR2(40) |
ID of entity |
|
entity_name |
VARCHAR2(255) |
Name of the entity, for example User Login, Role Name, or Policy Name. |
|
to_entity_type |
VARCHAR2(40) |
Type of entity in relationship (for example User in Role-User, Rule in Policy-Rule, and so on) |
|
to_entity_id |
VARCHAR2(40) |
ID of to entity in relationship |
|
to_entity_name |
VARCHAR2(255) |
Name of to entity in relationship |