Configuring Auditing

20 Configuring Auditing

You can configure profile auditing, which includes audit for user profile, role profile, and catalog. Otherwise, you can use lightweight audit.

This chapter describes about auditing in Oracle Identity Governance and compressing user profile audit data. It contains the following sections:

20.1 About Auditing

Oracle Identity Manager provides an audit engine to collect extensive data for audit and compliance purposes. You can use the audit functionality to capture, archive, and view entity and transactional data for compliance monitoring and IT-centric processes and forensic auditing.

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.

20.2 User Profile Auditing

Understand the data collected, post processor and tables used for user profile auditing, and archiving and compressing user profile audit data.

This section discusses the following topics:

20.2.1 Data Collected for User Profile Audits

Data collected for user profile audits involves setting the supported audit levels, capture of user profile audit data, storage of snapshots for user profile audit, and trigger for taking snapshots for user profile audit.

This section discusses about how data is collected for user profile audits in the following topics:

20.2.1.1 About Data Collected for User Profile Audits

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.

20.2.1.2 Capture of User Profile Audit Data

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 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 20-1.

Table 20-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 20-2.

Table 20-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.

20.2.1.3 Storage of Snapshots for User Profile Audit

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 20-3.

Table 20-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.

20.2.1.4 Trigger for Taking Snapshots for User Profile Audit

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

20.2.2 Post-Processor Used for User Profile Auditing

The user profile auditor has an internal post-processor that normalizes the snapshot XML into the reporting tables.

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.

20.2.3 Tables Used for User Profile Auditing

The database tables used for user profile auditing are UPA_USR, UPA_FIELDS, UPA_GRP_MEMBERSHIP, UPA_RESOURCE, UPA_UD_FORMS, and UPA_UD_FORMFIELDS.

Table 20-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 20-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 will be populated only if the XL.EnableExceptionReports system property is set to TRUE. For more information about this property, see Default System Properties in Oracle Identity Governance.
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 will be incorrect in the audit snapshot and the reporting tables.

20.2.4 Archiving User Profile Audit Data

The audit archival and purge utility is used to archive user profile audit data.

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.

20.2.5 Legacy Audit Data Compression

You can compress the existing and incoming audit data in the UPA table at mid-tier level based on the level of compression you set.

The size of the UPA table increases significantly because of the large size of audit data present in the SNAPSHOT and DELTAS columns. You can compress the data in these columns and save huge amount of space.

This section contains the following topics:

20.2.5.1 Configuring Audit Data Compression for New Deployment

In a fresh or upgraded deployment of Oracle Identity Governance, audit data compression is disabled by default. To enable it, set the following values of the Midtier compression for Audit (UPA) data system property with keyword OIM.AuditCompression:

0: This is the default value. It determines that none of the columns in the UPA table are compressed.
1: This value determines that the SNAPSHOT column in the UPA table is compressed.
3: This value determines that the SNAPSHOT and DELTAS columns in the UPA table are compressed.

In addition, the Midtier compression for Audit(UPA) data algo system property with keyword OIM.AuditCompressionAlgo determines that GZIP is used as the compression algorithm. Do not change the default value of this system property, which is GZIP.

See Default System Properties in Oracle Identity Governance for information about the Midtier compression for Audit (UPA) data and Midtier compression for Audit(UPA) data algo system properties.

20.2.5.2 Configuring Existing Audit Data Compression

To compress the uncompressed data that is existing in the UPA table from earlier releases of Oracle Identity Governance, run the User Profile Audit Compression scheduled task. This job compresses the uncompressed data and reduces the size of UPA table.

The User Profile Audit Compression scheduled task has the following input parameters:

Number of Threads: The number of threads to be executed during the job run. This is a required parameter and the default value is 2.
Batch Size: The size of the batch for the job run. This is a required parameter and the default value 1000.
Time Limit in mins: Time for which you want to run the job. This is an optional parameter and the default value is 90.

See Predefined Scheduled Tasks for information about the User Profile Audit Compression scheduled task.

20.3 Role Profile Auditing

Understand the audit levels, capture and archive of data, storage of snapshots, and trigger for taking snapshots for role profile audit data.

This section discusses about role profile auditing in the following topics:

20.3.1 About Role Profile Auditing

The supported audit levels for role profile auditing are None, Role, and Role Hierarchy.

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.

20.3.2 Capture and Archiving of Role Profile Audit Data

Each time a role profile changes, a snapshot of the role profile is stored in an audit table.

Role profile audits cover changes to role profile attributes, role administrators, and direct subroles.

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

20.3.3 Storage of Snapshots for Role Profile Auditing

The GPA table stores the snapshot of role profile audits. The ARM_AUD table stores the snapshot of an admin role membership profile.

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 20-5.

Table 20-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 20-6.

Table 20-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

20.3.4 Trigger for Taking Snapshots for Role Profile Auditing

When any data element in the role profile snapshot changes, a snapshot is created.

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

20.4 Catalog Auditing

You can enable catalog auditing by setting the value of the XL.CatalogAuditDataCollection system property to catalog.

See Configuring Catalog Auditing for information about catalog auditing.

20.5 Enabling and Disabling Auditing in Oracle Identity Governance

You can disable or enable auditing by setting appropriate values for the XL.UserProfileAuditDataCollection and XL.CatalogAuditDataCollection system properties.

This section describes how to enable and disable auditing in Oracle Identity Governance in the following sections:

20.5.1 Disabling Auditing in Oracle Identity Governance

You can disable auditing by setting values in the XL.UserProfileAuditDataCollection, XL.RoleAuditLevel, and XL.CatalogAuditDataCollection system properties.

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 Editing 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.

20.5.2 Enabling Auditing in Oracle Identity Governance

You can enable auditing by setting values in the XL.UserProfileAuditDataCollection, XL.RoleAuditLevel, and XL.CatalogAuditDataCollection system properties. In addition, enable the Issue Audit Messages Task scheduled job and run the GnerateSnapshot script.

To enable auditing in Oracle Identity Governance:

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 Capture and Archiving of Role Profile Audit Data for user profile and role profile auditing respectively.

See Configuring Oracle Identity Governance 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 Developing and Customizing Applications for Oracle Identity Governance.
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.
Note:

If Oracle Identtiy Governance is installed on IPv6 host computer, then pass ipv6 as the last input argument to the GenerateSnapshot.sh script.

To enable catalog auditing, set the value of the XL.CatalogAuditDataCollection system property to catalog.

20.6 Lightweight Audit

Using lightweight audit involves the understanding the entities that are audited, the definition of the table that stores audit data, and audit logging configuration.

This section describes the lightweight audit engine in Oracle Identity Manager. It contains the following topics:

20.6.1 About Lightweight Audit

Some of the entities that are audited by lightweight audit engine are user, role, role membership, organization, organization-user membership, scan definition, and policy violation. The AUDIT_EVENT table stores the audit data.

The lightweight audit feature is a forward looking audit engine for Oracle Identity Manager. Lightweight Audit engine is direct and, unlike the legacy auditing, does not have a denormalized reporting schema. For backward compatibility Oracle Identity Manager uses both the audit engines. This topic provides entities that are audited by the Lightweight Audit Engine in a tabular format.

Table 20-7 lists the entities that are audited by the Lightweight Audit Engine:

Table 20-7 Entities that are audited in Oracle Identity Manager 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 following AUDIT_EVENT table. Table 20-8 lists the content of the AUDIT_EVENT table.

Table 20-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_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

20.6.2 Audit Logging Configuration

The lightweight audit engine allows configuration of audit events though predefined groups. You can also add new entity types or actions.

There is no configuration for audit event logging in the legacy auditing, which results in data growth and performance issues. In other words, you can configure what gets audited for your deployment, and enable or disable audit logging at the following levels:

Enable or disable audit for all entities
Configure auditing per entity type or per action, such as create role
Configure auditing per entity relation or action, such as provision accounts, grant roles, and grant admin roles

For each of these, you can configure whether to enable or disable success, failure, or both.

The audit logging configuration can be done by using the AuditEventGroupManager and AuditEventEntityTypeActionManager public interfaces. For information about these APIs, see Java API Reference for Oracle Identity Manager.

By default, auditing for all data is enabled. You can disable or configure the audit date based on your requirement. Table 20-9 lists the entity types or actions per group that are supported by default. You can add new entity types or actions, which will then be supported.

Table 20-9 Group Entity Type Actions

Group Name	Entity Type / Action
User management	User / CREATE User / MODIFY User / DELETE User / LOCK User / UNLOCK User / ENABLE User / DISABLE
Role management	Role / CREATE Role / MODIFY Role / DELETE RoleRole / ADD RoleRole / REMOVE
Role membership	RoleUser / GRANT RoleUser / REVOKE
Password management	User / CHANGE PASSWORD User / RESET_PASSWORD
Login / logoff	User / LOGIN User / LOGOFF
Organization management	Organization / CREATE Organization / MODIFY Organization / DELETE Organization / ENABLE Organization / DISABLE
Organization membership	Organization User / ADD Organization User / REMOVE
Account management	Account Entitlement / GRANT Account Entitlement / REVOKE
Access policy management	Policy / CREATE Policy / MODIFY Policy / DELETE Policy Type / CREATE Policy Type / MODIFY Policy Type / DELETE Rule / CREATE Rule / MODIFY Rule / DELETE