Audit service provider settings
Use this page to define the implementation details of the audit service provider. There are three types of audit service providers: binary file-based, third party and SMF.
From the admin console, click one of the following paths:
- Security > Security auditing > Audit service provider > audit_service_provider_name.
- Security > Security auditing > Audit service provider > New > Binary File-based emitter.
- Security > Security auditing > Audit service provider > New > Third party emitter.
- Security > Security auditing > Audit service provider > New > SMF emitter.
Name
Unique name associated with the audit service provider.
Third party emitter class name
Name of the class for this implementation. This field is only present for Third party emitter implementations.
Audit file location
Path to the binary log file.
Audit file size
Maximum size of a single binary log file. This value is defined in megabytes.
Maximum number of audit log files
Maximum number of binary log files to create before the oldest is replaced.
The maximum number of logs does not include the current binary log being used written to. It is a reference to the maximum number of archived (timestamped) logs. The total number of binary logs that can exist for a server process is the maximum number of archived logs plus the current log.
Audit log wrapping
The wrapping behavior of the binary audit log when the maximum number of binary audit log files is reached.
There are customizable options available when specifying the default audit log wrapping behavior. This is only applicable to the Binary Audit Log implementation. Choose from one of the following options:
- WRAP
- If we select this option, when the maximum audit logs are reached, the oldest audit log is rewritten; notification is not sent to the auditor. This is the default option, and mimics the default behavior in WebSphere Application Server Version 7.0.
- NOWRAP
- This option does not rewrite over the oldest audit log. It stops the audit service, sends a notification to the SystemOut.log, and quiesces the application server.
- SILENT_FAIL
- This option does not rewrite over the oldest audit log. It also stops the audit service, but does allow the WebSphere process to continue. Notifications are not posted in the SystemOut.log.
If audit notification of failures in the audit subsystem is configured, and SILENT_FAIL is selected, the auditor is not notified of the audit subsystem failure. The SILENT_FAIL option takes precedence
If we use the NOWRAP or SILENT_FAIL options, when the server is stopped as a result of the logs being maxed-out, a stopserver is performed, or because the server abends in some way, we must archive the binary audit logs before you restart the server.
IBM recommends using the High Performance Extensible Logging (HPEL) log and trace infrastructure . We view HPEL log and trace information using the logViewer .
Event formatting module class name
Class used to format the generic event into a format that is specific to the audit service provider implementation. For example, a third party audit service provider implementation might have an event formatting class that takes the generic event and translates it into XML data.
Selectable filters
Available event filters. To enable a filter for an implementation, select the filter from the Selectable event filters list and then click >.
Enabled filters
Event filters that are currently enabled for an implementation. To disable a filter for an implementation, select the filter from the Enabled filters list and then click <.
Custom properties
Specifies any custom properties that might be used to add properties to a third party implementation. Custom properties are not available for binary file-based implementations or SMF implementations.
- Name
- Value
Auditing the security infrastructure Use High Performance Extensible Logging to troubleshoot applications Audit service provider collection