Oracle Fusion Middleware 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. Configuring common auditing settings for Security Token Service and validating your auditing configuration is the subject of this section; analyzing and using audit data is outside it's scope.
The Oracle Fusion Middleware Common Audit Framework supports auditing for a number of run-time events, and administrative events (changes to the system). It also provides uniform logging, and exception handling and diagnostics for all audit events.
While auditing can be enabled or disabled, it is typically enabled in production environments. Auditing has minimal performance impact, and the information captured can be useful (even mission-critical). The Auditing Framework uses configuration parameters set in the Oracle Access Management Console that enable data capture for a user or set of users.
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.
Additional information is available in the following topics.
Note:
Security Token Service integrates with Oracle Business Intelligence Publisher which provides a pre-defined set of compliance reports.
Security Token Service can be configured to write audit records to a variety of targets supported by the Common Audit Framework.ss
Local flat files: By default, Security Token Service records audit data to a file.
Central database: 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.
Platform-specific log (Linux Syslog and Windows Event Log)
Audit Vault
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
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 Security Token Service and accessible with Oracle Business Intelligence Publisher. You can also use Oracle Business Intelligence Publisher to create your own custom audit reports.
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 Securing Applications with Oracle Platform Security Services
Specific administrative and run-time events that you can audit for Security Token Service are grouped together .
See Auditing Administrative and Run-time Events.
Included with the events are the common instructions for setting up and validating auditing.
See the following topics for more details: