14 Auditing OAM Administrative and Run-time Events

In Oracle Access Manager and Oracle Fusion Middleware 11g, auditing provides a measure of accountability and answers to the "who has done what and when" types of questions. Audit data can be used to create dashboards, compile historical data, and assess risks. Analyzing recorded audit data allows compliance officers to perform periodic reviews of compliance policies.

This chapter describes the Oracle Access Manager administrative and run-time events that can be audited. Configuring common auditing settings for Oracle Access Manager and validating your auditing configuration is the subject of this chapter. Analyzing and using audit data is outside the scope of this chapter.

This chapter includes the following topics:

Prerequisites

This section identifies requirements for tasks in this chapter: Review Introduction to Oracle Access Manager Auditing

Introduction to Oracle Access Manager 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.

Oracle Access Manager 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.

While auditing can be enabled or disabled, it is normally enabled in production environments. Auditing has minimal performance impact, and the information captured by auditing can be useful (even mission-critical).

Note:

Auditing for OAM 10g was based on OAM policies. However, auditing for OAM 11g is based on configuration parameters set in the OAM Administration Console which enables data capture for a user or set of users.

Oracle Access Manager audit data can be written to either a single, centralized Oracle Database instance or to flat files. Regardless of where the audit record is stored, it contains a sequence of items that can be configured to meet particular requirements. The audit log file helps the audit administrator track errors and diagnose problems if the audit framework is not working properly.

Oracle Access Manager integrates with Oracle Business Intelligence Publisher, which provides a pre-defined set of compliance reports:

This section introduces auditing for Oracle Access Manager in the following topics:

See Also:

Introduction to Oracle Fusion Middleware Audit Framework in the Oracle Fusion Middleware Application Security Guide

About OAM Auditing Configuration

An OAM administrator controls certain auditing parameters using the OAM Administration Console. This Oracle Access Manager auditing configuration is recorded in the file oam-config.xml. Additional auditing configuration is required through the Common Audit Framework.

Note:

The audit configuration is part of oam-config.xml. OAM audit policies cannot be configured using Fusion Middleware Control. OAM does not use JPS infrastructure to configure the audit configuration. There are no WebLogic Scripting Tool (WLST) commands for OAM auditing.

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

See Also:

About Audit Record Storage

By default, Oracle Access Manager records audit data to a file. However, 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.

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.

Note:

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

In production environments, Oracle recommends using a database audit store to provide scalability and high-availability for the Common Audit Framework. Audit data is cumulative and grows over time. Ideally this is a database for only audit data; not used by other applications.

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

Figure 14-1 provides a simplified view of the audit architecture with a supported database. The Oracle Fusion Middleware Audit Framework schema for audit log tables is provided by the Repository Creation Utility (RCU), which must be run before you can log information to the database.

Figure 14-1 Audit to Database Architecture

Surrounding text describes Figure 14-1 .

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.

About Audit Reports and Oracle Business Intelligence Publisher

The data in the database audit store is exposed through pre-defined reports in Oracle Business Intelligence Publisher. 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 Manager and accessible with Oracle Business Intelligence Publisher. You can also use Oracle Business Intelligence Publisher to create your own custom audit reports.

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.Oracle BI EE is designed to bring greater business visibility and insight to a wide variety of users.

The components of Oracle Business Intelligence Enterprise Edition 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 Business Intelligence Enterprise Edition 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 Oracle Fusion Middleware Security Guide

For an overview of how to prepare Oracle BI EE for use with auditing reports for Oracle Access Manager, see "Preparing Oracle Business Intelligence Publisher EE".

About the Audit Log

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: Date, Time, Initiator, EventType, EventStatus, MessageText, ECID, RID ContextFields, SessionId, TargetComponentType, ApplicationName, and EventCategory to name a few.

See Also:

The topic on audit logs in the chapter on configuring and managing auditing in the Oracle Fusion Middleware Security Guide

OAM Events You Can Audit

This section provides the following topics:

OAM Administrative Events You Can Audit

Administrative events are those generated when the OAM Administration Console is used.

The OAM-specific administrative events that can be audited and the details captured in them are listed in Table 14-1. These event definitions and configurations are implemented as part of the audit service in Oracle Platform Security Services.

Note:

With OAM 11g, the administrator controls the amount and type of information that is logged by choosing a filter preset from the Audit Configuration tab on the OAM Server Common Properties page.

Auditable events for each filter preset are fixed in the read-only component_events.xml file. Editing or customizing this file is not supported for OAM 11g.

Table 14-1 OAM Administrative Audit Events

Administrative Event Event Data Include

Administration Console Login success/failure

  • User name

  • Remote IP

  • Roles

Authentication Policy Creation

  • Policy name

  • Authentication scheme details

  • Resource details

  • Policy type (authentication or authorization)

Authentication Policy Modification

  • Policy name

  • Authentication scheme details

  • Resource details

  • Policy type (authentication or authorization

  • Old Policy name

  • Old Authentication scheme details

  • Old Resource details

Authentication Policy Removal

  • Policy name

  • Authentication scheme details

  • Resource details

  • Policy type (authentication or authorization

Resource Creation

  • Resource name

  • URI

  • Operation

  • Resource type

Resource Modification

  • Resource name

  • URI

  • Operation

  • Resource type

  • Old Resource name

  • Old URI

  • Old Operation

Resource Removal

  • Resource name

  • URI

  • Operation

  • Resource type

Authentication Scheme Creation

  • Scheme name

  • Authentication modules

  • Level

Authentication Scheme Modification

  • Scheme name

  • Authentication modules

  • Level

  • Old Scheme name

  • Old Authentication modules

  • Old Level

Authentication Scheme Removal (Delete)

  • Scheme name

  • Authentication modules

  • Level

Response Creation

  • Response name

  • Response key

  • Data source

  • Response Type

Response Modification

  • Response name

  • Response key

  • Data source

  • Response Type

  • Old Response name

  • Old Response key

  • Old Data source

Response Removal (Delete)

  • Response name

  • Response key

  • Data source

  • Response Type

Partner Addition

  • Partner name

  • Partner ID

  • Partner URL

  • Logout URL

Partner Modification

  • Partner name

  • Partner ID

  • Partner URL

  • Logout URL

  • Old Partner name

  • Old Partner URL

  • Old Logout URL

Partner Removal

  • Partner name

  • Partner ID

  • Partner URL

  • Logout URL

Constraints creation

  • Constraint Name

  • Constraint type

  • Constraint data

Constraints Modification

  • Constraint Name

  • Constraint type

  • Constraint data

  • Old Constraint name

  • Old Constraint type

  • Old Constraint data

Constraints Removal

  • Constraint Name

  • Constraint type

  • Constraint data

Server Domain creation

  • Domain Name

Server Domain Modification

  • Domain Name

  • Old Domain Name

Server Domain Removal

  • Domain Name

Server configuration change

  • New details

  • Old details

  • Instance Name

  • Host Name

  • Application Name

  • User Name

  • Remote ID

  • Roles

  • Date and time

OAM Run-time Events You Can Audit

Run-time events are those generated by some of the events the Oracle Access Manager component engines issue when interacting with one another.

The run-time events that can be audited, when they are issued, and the details captured in them are listed in Table 14-2. These event definitions and configurations are implemented as part of the audit service in Oracle Platform Security Services.

Note:

With OAM 11g, the administrator controls the amount and type of information that is logged by choosing a filter preset from the Audit Configuration tab on the OAM Server Common Properties page.

Auditable events for each filter preset are fixed in the read-only component_events.xml file. Editing or customizing this file is not supported for OAM 11g.

Table 14-2 OAM Run-time Audit Events

Run-time Event Issued When Event Details Include

Authentication Attempt

A user attempts to access a protected resource and the request arrives at the SSO server; this event might be followed by the events credential submit and authentication success or failure.

  • Remote IP

  • Resource ID

  • Partner ID

  • Resource ID

  • Authentication scheme ID

  • Authentication Policy ID

Authentication Success

A client submits credentials and credential validation is successful.

  • Remote IP

  • User Name

  • User DN

  • Resource ID

  • Authentication scheme ID

  • Authentication Policy ID

  • Partner ID

Authentication Failure

A client submits credentials and credential validation fails.

  • Remote IP

  • User Name

  • User DN

  • Resource ID

  • Authentication Scheme ID

  • Failure Error Code

  • Retry count

  • Authentication Policy ID

  • Partner ID

Session Creation

Authentication succeeds.

  • SSO Session ID

  • User Name

  • User DN

  • Remote IP

  • Resource ID

  • Authentication scheme ID

  • Authentication Policy ID

Session Destroy

Authentication succeeds.

  • SSO Session ID

  • User Name

  • User DN

  • Partner ID

Login success

A client finishes the login procedure and it is forwarded to the agent.

  • Remote IP

  • User Name

  • User DN

  • Authentication level

  • Resource ID

  • Authentication scheme ID

  • Authentication Policy ID

  • Partner ID

Login failure

A client fails to login; this event is issued only when all the retry authentication attempts allowed have failed or when the account is locked.

  • Remote IP

  • User Name

  • Authentication level

  • Resource ID

  • Authentication scheme ID

  • Authentication Policy ID

  • Partner ID

Logout success

A client finishes the logout procedure and is forwarded to the agent.

  • Remote IP

  • User DN

  • Authentication level

  • SSO Session ID

  • Partner ID

Logout failure

A client fails to logout.

  • Remote IP

  • User DN

  • SSO Session ID

  • Failure details

  • Partner ID

Credential Collection

A client is redirected to the credential collection page.

  • Remote IP

  • Resource Name

  • Resource ID

  • Authentication scheme ID

  • Authentication Policy ID

Credential Submit

A client submits credentials.

  • Remote IP

  • User Name

  • Resource ID

  • Authentication scheme ID

  • Authentication Policy ID

Authorization Success

A client has been authorized to access a resource.

  • Remote IP

  • User DN

  • Resource ID

  • Authorization Policy ID

Authorization Failure

A client has not been authorized to access a resource.

  • Remote IP

  • User DN

  • Resource ID

  • Authorization Policy ID

Server Start Up

The server starts up.

  • Date and time

  • Instance Name

  • Host Name

  • Application Name

  • User Name

Server Shut Down

The server shuts down.

  • Date and time

  • Instance Name

  • Host Name

  • Application Name

  • User Name

About Authentication Event Auditing

Auditing events during authentication can help administrators scrutinize security weaknesses in their systems. Information about users requesting authentication or brute force attacks can be stored in the file system or in a back-end database.

The events that an administrator can configure for auditing during authentication are:

  • Authentication success

  • Authentication failure

  • Create, modify, delete, or view Authentication Policy data

Information related to the user being authenticated include the following:

  • IP address

  • Browser type

  • User Login ID

  • Time of Access

Note:

Oracle recommends that you avoid auditing, logging, or tracing sensitive user attributes, such as user passwords.

Setting Up Auditing for Oracle Access Manager

The following overview provides a list of the tasks that must be performed before you can perform auditing with Oracle Access Manager.

Task overview: Configuring auditing for Oracle Access Manager includes

  1. Set up the audit data store, as described in "Setting Up the Audit Database Store".

  2. Set up publishing for audit reports, as described in "Preparing Oracle Business Intelligence Publisher EE".

  3. Edit the Audit Configuration in the OAM Administration Console, as described in:

  4. Confirm that auditing is working as desired; see: "Validating Oracle Access Manager Auditing and Reports".

Setting Up the Audit Database Store

This topic provides an overview of the tasks required to create the audit database and extend the schema using the Repository Creation Utility (RCU). This task is required before you can audit events for Oracle Access Manager if you choose a database store for audit data.

See Also:

Task overview: Creating the database audit store

  1. Create an audit database, version 11.1.0.7 or later, as described in he Oracle Fusion Middleware Application Security Guide.

  2. Run the Oracle Repository Creation Utility (RCU) against the database, as described in "Create the Audit Schema using RCU" in the Oracle Fusion Middleware Repository Creation Utility User's Guide.

  3. Set up audit data sources for the audit loader and configure it for the OAM Server as described in "Set Up Audit Data Sources" in the Oracle Fusion Middleware Application Security Guide:

    • Use the Java EE audit loader configuration for WebLogic Server.

    • Use the JNDI name of the datasource jdbc/AuditDB that points to the database that was set up in step 2 above

  4. In the service instance specified in the domain file (DOMAIN_HOME/config/fmwconfig/jps-config.xml), enable database auditing by changing the value of the property audit.loader.repositoryType to DB. For example:

    <serviceInstance name="audit" provider="audit.provider">
  <property name="audit.filterPreset" value="None"/>
  <property name="audit.maxDirSize" value ="0"/>
  <property name="audit.maxFileSize" value ="104857600"/>
  <property name="audit.loader.jndi" value="jdbc/AuditDB"/>
  <property name="audit.loader.interval" value="15" />
  <property name="audit.loader.repositoryType" value="DB" />
</serviceInstance>

  5. Restart the WebLogic Server.

  6. Ensure that the audit loader is configured for the OAM Server and that it points to the proper database, as described in "Configure a Database Audit Store for Java Components" in the Oracle Fusion Middleware Application Security Guide.

  7. Maintain the bus-stop files, as described in "Tuning the Bus-stop Files" in the Oracle Fusion Middleware Application Security Guide.

Preparing Oracle Business Intelligence Publisher EE

You must prepare Oracle Business Intelligence Publisher Enterprise Edition (EE) for use with Oracle Access Manager audit reports as outlined in the following procedure.

See Also:

  • Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition

  • Oracle Fusion Middleware Developer's Guide for Oracle Business Intelligence Enterprise Edition

  • Oracle Fusion Middleware User's Guide for Oracle Business Intelligence Enterprise Edition

Task overview: Prepare Oracle BI Publisher

  1. Install Oracle BI Publisher, as described in the Oracle Business Intelligence Enterprise Edition Installation and Upgrade Guide.

  2. Perform tasks as described in "Set Up Oracle Reports in Oracle Business Intelligence Publisher" in the Oracle Fusion Middleware Application Security Guide:

    • Unjar the AuditReportTemplate.jar into your Reports folder.

    • Set up the JNDI connection for the audit data source or the JDBC connection the audit database

  3. Set up audit report templates, as described in the section "Set Up Audit Report Templates" of the Oracle Fusion Middleware Application Security Guide.

  4. Set up audit report filters, as described in the section "Set Up Audit Report Filters" of the Oracle Fusion Middleware Application Security Guide.

  5. View reports from the following path: Reports/Oracle_Fusion_Middleware_Audit reports.

About the Auditing Configuration Page in Oracle Access Manager

Within Oracle Access Manager, certain Audit Configuration settings are accessible as OAM Server Common Properties under the System Configuration. These settings are not required when you audit to a database. Figure 14-2 shows the Audit Configuration page.

Figure 14-2 Server Common Properties - Auditing

Server Common Properties - Auditing

The Auditing page is divided into two sections: The Log Directory section and the Filter Settings section.

Note:

The actual log directory cannot be configured using the Administration Console. It is the default directory for the Common Audit Framework audit loader. Changing the directory impacts the audit loader and is not supported.

Table 14-3 describes the elements in the Audit Configuration page.

Table 14-3 Audit Configuration Elements

Elements Description

Maximum Directory Size

The maximum size, in MBs, of the directory that contains audit output files. For example, assuming that the maximum file size is 10, a value of 100 for this parameter implies that the directory allows a maximum of 10 files. Once the maximum directory size is reached, the audit logging stops.

For example, a value of 100 specifies a maximum of 10 files if the file size is 10 MB. If the size exceeds this, the creation of audit logs stops.

This is configured using the max.DirSize property described in the configuration filejps-config.xml. This property controls the maximum size of a bus-stop directory for Java components as described in the Oracle Fusion Middleware Application Security Guide.

Maximum File Size

The maximum size, in MBs, of an audit log file. Once the size of a file reaches the maxi mum size, a new log file is created. For example, specifying 10 directs file rotation when the file size reaches 10 MB.

This is configured using the max.fileSize property described in the configuration filejps-config.xml. This property controls the maximum size of a bus-stop file for Java components as described in the Oracle Fusion Middleware Application Security Guide.

Filter Enabled

Check this box to enable event filtering.

Filter Preset

Defines the amount and type of information that is logged when the filter is enabled. The default value is Low.

  • All: captures and records all auditable OAM events

  • Low: captures and records a specific set of auditable OAM events

  • Medium: captures and records events covered by the Low setting plus a number of other auditable OAM events

  • None: no OAM events are captured and recorded

Events for each filter preset are fixed in the read-only component_events.xml file. Editing or customizing this file is not supported for OAM 11g. Only items that are configured for auditing at the specified filter preset can be audited.

Special Users

Specifies the list of users whose actions are included only when the filter is enabled. All actions of the special users are audited regardless of the filter preset. Administrators can add, remove or edit special users from this table.

Adding, Viewing, or Editing Common Audit Settings within Oracle Access Manager

The following procedure describes how to add, view, or edit OAM Server Common Audit Configuration settings using the OAM Administration Console.

To view or edit auditing configuration in the Administration Console

  1. From the System Configuration tab, navigation tree, double-click Server Instances.

    Alternatively: From any OAM Server page, click the Server Instances link.

  2. On the Audit Configuration page, enter appropriate details for your environment (Table 14-3):

    • Log directory and file maximums

    • Filter settings include specific users from the audit.

  3. Click Apply to submit the changes (or close the page without applying changes).

  4. Restart the OAM Administration Server and OAM Servers after changes are made.

Validating Oracle Access Manager Auditing and Reports

You can use the following procedure to test your run-time event auditing configuration.

Prerequisites

To validate your OAM 11g auditing configuration

  1. In a browser, enter the URL to a protected resource and sign in using an invalid credential.

  2. Sign in again using the proper credential.

  3. Sign in to Oracle BI EE. For example:

    http://host:port/xmlpserver

    Here, host is the computer hosting Oracle BI Publisher; port is the listening port for BI Publisher; xmlpserver is the login page for BI Publisher.

  4. In Oracle BI Publisher Enterprise, locate the desired Oracle Access Manager reports. For example:

    Click Shared Folders, click Oracle_Fusion_Middleware_Audit, click Component_Specific, click Oracle_Access_Manager, and then select the desired report, as shown:

    Oracle BI Publisher Reports Page

  5. Perform any analysis as desired, or edit your auditing configuration as needed.

    /Middleware_home/user_projects/domains/base_domain/servers/oam_server1/logs/ 
auditlogs/OAM/

  6. Archive and manage audit logs according to your company policies.