6.3 Auditing Web Services

Auditing describes the process of collecting and storing information about security events and the outcome of those events. An audit provides an electronic trail of selected system activity.

An audit policy defines the type and scope of events to be captured at run time. Although a very large array of system and user events can occur during an operation, the events that are actually audited depend on the audit policies in effect at run time. You can define component- or application-specific policies, or audit individual users.

You configure auditing for system components, including web services, and applications at the domain level using the Audit Policy page. You can audit SOA and ADF services.

The following table summarizes the events that you can audit for web services and the relevant component.

---

Table 6-8 Auditing Events for Web Services

Enable auditing for the following web service events. . .	Using this system component. . .
User authentication. User authorization. Policy enforcement, including message confidentiality, message integrity, and security policy.	OWSM—Agent For more information, see "OWSM-AGENT Events and Attributes".
Web service requests sent and responses received. SOAP faults incurred. Note: In this case, events are logged for both security and non-security web service invocations.	Oracle web services For more information, see "Oracle Web Services Events and Attributes".
OWSM assertion template creation, deletion, or modification. OWSM policy intent creation, deletion, or modification. OWSM policy creation, deletion, or modification. OWSM policy set authoring creation, deletion, or modification.	OWSM—Policy Manager Note: The Policy Manager audits both local policy attachments and global policy attachments for policy sets. For more information, see "OWSM-PM-EJB Events and Attributes".
OWSM policy attachment.	OWSM—Policy Attachment Note: The Policy Attachment audits only local policy attachments. For more information, see "Web Services Policy Attachment Events and Attributes".

---

You can also audit the events for a specific user, for example, you can audit all events by an administrator.

For more information about configuring audit policies, see "Configuring and Managing Auditing" in Securing Applications with Oracle Platform Security Services.

The following sections describe how to define audit policies and view audit data:

• Configuring Audit Policies

• Managing Audit Data Collection and Storage

• Viewing Audit Reports

6.3.1 Configuring Audit Policies

Follow the steps in this section to configure audit policies. For more information, see "Manage Audit Policies for Java Components with Fusion Middleware Control" in Securing Applications with Oracle Platform Security Services.

1. From the WebLogic Domain menu, select Security > Audit Policy.

   The Audit Policy Settings page is displayed.

   The audit policies table, at the center of the page, displays the audits that are currently in effect.

2. Select the component that you want to audit from the Audit Component Name menu.
3. Select an audit level from the Audit Level menu.

   Valid audit levels include:

   • None—Disables auditing.

   • Low, Medium, High—Audits subsets of event categories representing pre-defined levels of auditing.

   • Custom—Enables you to provide a custom auditing policy.

   You can view the components and applications that are selected for audit at each level in the audit policies list. For all audit levels other than Custom, the information in the audit policies list is greyed out, as you cannot customize other audit level settings.

4. To customize the audit policy, select the Custom option and perform one of the following steps:

   • Select the information that you want to audit by clicking the associated checkbox in the Select for Audit column.

     You can audit at the following levels of granularity: All events for a component, all events within a component event category, an individual event, or a specific outcome of an individual event (such as, success or failure).

     Click Select All to select all categories, None to deselect all categories, or Audit All Events to audit all events, including specific outcome of individual events (such as, successes and failures).

     At the event outcome level, you can specify an edit filter. Filters are rules-based expressions that you can define to control the events that are returned. For example, you might specify an Initiator as a filter for policy management operations to track when policies were created, modified, or deleted by a specific user. To define a filter for an outcome level, click the Edit Filter icon in the appropriate column, specify the filter attributes, and click OK. The filter definition appears in the Filter column.

     Deselect the checkbox for a component at a higher level to customize auditing for its subcomponents. You can select all components and applications by checking the checkbox adjacent to the column name.

   • At the event outcome level, you can specify an edit filter. Filters are rules-based expressions that you can define to control the events that are returned. For example, you might specify an Initiator as a filter for policy management operations to track when policies were created, modified, or deleted by a specific user. To define a filter for an outcome level, click the Edit Filter icon in the appropriate column, specify the filter attributes, and click OK. The filter definition appears in the Filter column.

   • To audit only success or failures for all system components and applications, select Select Successes Only or Select Failures Only from the Select menu, respectively. To clear all selections, select None.

5. If required, enter a comma-separated list of users in the Users to Always Audit text box.

   Specified users will always be audited, regardless of whether auditing is enabled or disabled, and at what level auditing is set.

6. Click Apply.

   To revert all changes made during the current session, click Revert.

6.3.2 Managing Audit Data Collection and Storage

To manage the data collection and storage of audit information, you need to perform the following tasks:

• Set up and manage an audit data repository.

  You can store records using one of two repository modes: file and database. It is recommended that you use the database repository mode. The Oracle Business Intelligence Publisher-based audit reports only work in the database repository mode.

• Set up audit event collection.

For more information, see "Managing the Audit Data Store" in Securing Applications with Oracle Platform Security Services.

6.3.3 Viewing Audit Reports

For database repositories, data is exposed through pre-defined reports in Oracle Business Intelligence Publisher.

A number of predefined reports are available, such as: authentication and authorization history, OWSM policy enforcement and management, and so on. For details about generating and viewing audit reports using Oracle Business Intelligence Publisher, see "Using Audit Analysis and Reporting" in Securing Applications with Oracle Platform Security Services.

For file-based repositories, you can view the bus-stop files using a text editor and create your own custom queries.