8.2 Oracle Access Management Auditing

Many businesses must now be able to audit identity information and user access on applications and devices.

Compliance audits help an enterprise conform with regulatory requirements—Sarbanes-Oxley or the Health Insurance Portability and Accountability Act (HIPAA) are two examples.

The following topics provide information about:

8.2.1 Understanding Oracle Access Management Auditing

Oracle Access Management uses the Oracle Fusion Middleware Common Audit Framework to support auditing for a large number of user authentication and authorization run-time events, and administrative events (changes to the system). The Oracle Fusion Middleware Common Audit Framework provides uniform logging and exception handling and diagnostics for all audit events.

Auditing is based on configuration parameters set using the Oracle Access Management Console which enables data capture for a user or set of users. While auditing can be enabled or disabled, it is normally enabled in production environments. Audit data can be written to either a single, centralized Oracle Database instance or to flat files known as bus-stop files.

Note:

The Oracle Fusion Middleware Common Audit Framework database audit store does not include Access Manager policy or session-data and is not configured through the Oracle Access Management Console.

Auditing has minimal performance impact, and the information captured by auditing can be useful (even mission-critical). The audit log file helps the audit Administrator track errors and diagnose problems if the audit framework is not working properly.

8.2.2 About Oracle Access Management Auditing Configuration

An Administrator controls certain auditing parameters using the Oracle Access Management Console. This auditing configuration is recorded in the oam-config.xml file.

Additional auditing configuration is required through the Common Audit Framework.

Note:

Oracle recommends that you use only the Oracle Access Management Console or WebLogic Scripting Tool (WLST) commands for changes; do not edit the oam-config.xml file directly.

Event configuration (mapping events to levels) occurs in the component_events.xml file. An audit record contains a sequence of items that can be configured to meet particular requirements.

Within the Oracle Access Management Console, you can set the maximum log file and log directory size. Audit policies (known as Filter Presets declare the types of events to be captured by the audit framework for particular components.

Audit policies cannot be configured using Fusion Middleware Control. Oracle Access Management does not use JPS infrastructure to configure the audit configuration. There are no WebLogic Scripting Tool (WLST) commands for auditing.

8.2.3 About Audit Record Storage

Audit data can be written to either a single, centralized Oracle Database instance or to flat files known as bus-stop files. By default, audit data is recorded to the file but administrators can change the configuration to log audit data to a database. Although the formats differ, audit data content is identical in both the flat file and the database.

  • Audit Bus-stop: Local files containing audit data records before they are pushed to the audit data store. In the event that no audit data store is configured, audit data remains in these bus-stop files. The bus-stop files are simple text files that can be queried easily to look up specific audit events. When an audit data store is in place, the bus-stop acts as an intermediary between the component and the audit data store. The local files are periodically uploaded to the audit data store based on a configurable time interval.

    Bus-stop files for Java components are located in:

    $DOMAIN_HOME/servers/$SERVER_NAME/logs/auditlogs/OAM/audit.log 
    

    Bus-stop files for system components are located in:

    $ORACLE_INSTANCE/auditlogs/OAM/oam_server1/audit.log
    
  • Database Logging: Implements the Common Auditing Framework across a range of Oracle Fusion Middleware products. The benefit is audit-function commonality at the platform level.

  • Database Audit Store: In production environments, Oracle recommends using a database audit store to provide scalability and high-availability for the Common Audit Framework. A key advantage of the audit data store is that audit data from multiple components can be correlated and combined in reports; for example, authentication failures in all Middleware components and instances. Audit data is cumulative and grows over time so ideally this is a stand-alone RDBMS database for audit data only and not used by other applications.

    Note:

    The preferred mode in production environments is writing audit records to a stand-alone RDBMS database for audit data only.

    To switch to a database as the permanent store for your audit records, you must first use the Repository Creation Utility (RCU) to create a database schema for audit data. The RCU seeds that database store with the schema required to store audit records in a database. After the schema is created, configuring a database audit store involves:

    • Creating a data source that points to the audit schema you created

    • Configuring the audit store to point to the data source

    As previously documented, the Oracle Fusion Middleware Audit Framework schema is provided by the RCU.

    Figure 8-1 provides a simplified view of the audit architecture with a supported database.

    Figure 8-1 Audit to Database Architecture

    Description of Figure 8-1 follows
    Description of "Figure 8-1 Audit to Database Architecture"

    See Also:

    An independent audit loader process reads the flat log file and inserts records in the log table of the Oracle database. The audit store allows Administrators to expose audit data with Oracle Business Intelligence Publisher using a variety of out-of-the-box reports.

8.2.4 About Audit Reports and Oracle Business Intelligence Publisher

Oracle Access Management integrates with Oracle Business Intelligence Publisher, which provides a pre-defined set of compliance reports through which the data in the database audit store is exposed. These reports allow you to drill down the audit data based on various criteria, such as user name, time range, application type, and execution context identifier (ECID).

Out-of-the-box, there are several sample audit reports available with Oracle Access Management and accessible with Oracle Business Intelligence Publisher. You can also use Oracle Business Intelligence Publisher to create your own custom audit reports.

8.2.5 Oracle BI Enterprise Edition (Oracle BI EE)

Oracle BI Enterprise Edition (Oracle BI EE) is a comprehensive set of enterprise business intelligence tools and infrastructure, including a scalable and efficient query and analysis server, an ad-hoc query and analysis tool, interactive dashboards, proactive intelligence and alerts, real-time predictive intelligence, and an enterprise reporting engine.

The components of Oracle BI EE share a common service-oriented architecture, data access services, analytic and calculation infrastructure, metadata management services, semantic business model, security model and user preferences, and administration tools. Oracle BI EE provides scalability and performance with data-source specific optimized analysis generation, optimized data access, advanced calculation, intelligent caching services, and clustering.

See Also:

"Using Audit Analysis and Reporting" in the Securing Applications with Oracle Platform Security Services

You may need to prepare Oracle BI EE for use with auditing reports for Oracle Access Management.

See Preparing Oracle Business Intelligence Publisher EE.

Oracle BI EE reports contain enumerated fields, the data fields and labels of which are self-explanatory. Content of reports is described in Table 8-1 (taken from Knowledge Base Doc ID 1495333.1 on My Oracle Support.

Table 8-1 Oracle Business Intelligence Enterprise Edition Reports for OAM

Report Type Description

Account Management

User ID | Timestamp | Component/ Application Name | Event Details

Authentication_Statistics

Authentication_statistics

Failure | Userid | Number of Events

AuthenticationFromIPByUser

IP Address | Distinct User Count | Total Attempts | Users

AuthenticationPerIP

IP Address | Distinct Users | Total Number of Attempts

AuthenticationStatisticsPerServer

Server Instance Name | Success Count | Failure Count

Errors_and_Exceptions

All_Errors_and_Exceptions

User ID | Timestamp | Component/Application Name | Client IP Address | Message Event | Event Details

Authentication_Failures

User ID | Timestamp | Component/ Application Name | Client IP Address | Authentication Method | Message Event Details | Authorization_Failures

Users_Activities

Authentication_History

User ID | Timestamp | Component/ Application Name | Client IP Address | Authentication Method | Message Event Details | Authorization_Failures

Multiple_Logins_From_Same_IP

IP Address | Usernames Used

8.2.6 About the Audit Log and Data

An audit log file helps the audit administrator track errors and diagnose problems when the audit framework is not working properly. An audit log file records several fields including (but not limited to) Date, Time, Initiator, EventType, EventStatus, MessageText, ECID, RID ContextFields, SessionId, TargetComponentType, ApplicationName, and EventCategory.

See Also:

The topic on audit logs when configuring and managing auditing in the Securing Applications with Oracle Platform Security Services.