The Audit Client Service is designed to offload the cost of the sending or writing an audit trail. This is accomplished by writing the received Audit Events to an internal Queue and sending them on a separate thread. The queue has a maximum depth to limit memory usage. When this depth is reached the implementation performs several actions to attempt to improve the throughput one of which is temporarily increasing the thread priority of the queue reader.
This effectively "strangles" the input until the queue depth is reduced. To reach this level throughput at least 300 events/sec must be being delivered to the Audit Forwarding Server.
The Audit Client Service will also ensure that no events get lost if the connection to the sink gets lost. This is done by saving the events to a persistent store if the connection is lost. Events are buffered in memory and written in blocks to the file. When the connection is recovered, the events in the file are sent to the sink, followed by the contents of any memory buffer and finally the latest event.
Two Audit Forwarders are supplied with the package, one that simply writes to a file and another that requires the Audit Forward Service daemon to be running on the host where the trail is being produced. This daemon is available as separate product that is part of an enterprise auditing package.
This service was originally developed as a part of an integrated SSO (single Sign On) solution for banking solutions using web services.
The following sections describe how to use the alarming service
The Audit Service is composed of 2 layers, the IAuditClientService which you code to to send an audit trail and the IAuditClientSpi which is the SPI (Service Provider Interface) and responsible for actually forwarding the trail. The SPI is created by the client service but is also configurable.
Both the service and the SPI are obtained using locators and are, therefore, configurable in the services.conf file:
If you want to write your audit trail to a file you can set the audit-provider key to com.addc.auditing.client.impl.file.AuditClientSpiFile . Once you have set up the configuration you get the IAuditClientService instance with the locator:
IAuditClientService auditor = AuditClientServiceFactory.getAuditClientService();
This will return an initialised IAuditClientService instance.
WARNING The IAuditClientService implementation is multi-threaded and must, therefore, be initialised outside of the EJB. For example in WebLogic you would initialise the IAuditClientService in a startup class:
public class MyStartup implements T3StartupDef {
...
...
public String startup(String name, Hashtable args) throws Exception {
...
...
AuditClientServiceFactory.getAuditClientService();
...
...
}
...
...
}
The initialisation requires a configuration files named AuditClient.conf , AuditClient.properties or AuditClient.xml with the following properties:
| Key | Description |
| persistencePath | The path where temporary queue files are written if a connection is lost |
| prefix | The prefix for queue files |
| url | The url of the Audit Forward Service or the path where the audit trail is stored |
To send an Audit event you first need to create an event and then send it using the service. Audit events include security information:
Create an Audit Event
AuditEvent event = new AuditEvent(
AuditType.SESSION_AUTH,
AuditSeverity.SUCCESS,
"OriginatorName",
"ServerName",
"Session successfully initialised.");
Send it
auditor.sendAuditEvent(event);
The IAuditClientService supports fine grained filtering using exclusion filters. The AuditFilter class is associated with an AuditType and contains a list of AuditSeveritie s that should not be sent. The IAuditClientConfig interface supplies methods for setting, modifying and removing filters from the service:
IAuditClientService auditor = AuditClientServiceFactory.getAuditClientService();
...
// Create a filter
auditor.setAuditFilter(AuditType.PRINCIPAL_AUTH, AuditSeverity.INFORMATION);
// Add WARNING severity to the filter
auditor.setAuditFilter(AuditType.PRINCIPAL_AUTH, AuditSeverity.WARNING);
// Remove WARNING severity to the filter
auditor.removeAuditFilterSeverity(AuditType.PRINCIPAL_AUTH, AuditSeverity.WARNING);
// Remove the filter
auditor.removeAuditFilter(AuditType.PRINCIPAL_AUTH);
The Audit Client Service supports alarming through the use of Alarm Filter objects can be added to the service. These filters are not quite the same as the AuditFilters; they are designed to raise an alarm if an Audit Event matches the audit type and the severity is equal to or greater than the filter’s severity. Like Audit Filters, Alarm Filters can be added or removed from the service through the AuditConfig interface:
IAuditClientService auditor = AuditClientServiceFactory.getAuditClientService();
...
// Create an alarm filter
auditor.setAlarmFilter(AuditType.PRINCIPAL_AUTH, AuditSeverity.ERROR);
// Change the alarm filter
auditor.setAlarmFilter(AuditType.PRINCIPAL_AUTH, AuditSeverity.WARNING);
// Remove the filter
auditor.removeAlarmFilter(AuditType.PRINCIPAL_AUTH);
It also allows you to explicitly raise a CRITICAL alarm for any AuditEvent by setting the alarm flag in the event:
AuditEvent event = new AuditEvent(
AuditType.SESSION_AUTH,
AuditSeverity.WARNING,
"OriginatorName",
"ServerName",
"Session authentication failed.");
...
event.setAlarmCritical(true);