Security Auditing in WebLogic

Weblogic provides an extensible mechanism to audit the activities of weblogic security framework. Weblogic security framework is the framework which takes care of all security related features in a weblogic server including authentication and authorization. Auditing is turned off by default.

The security framework comes out of the box with a DefaultAuditProvider which can be installed and configured into the security framework. When installed and configured in, it starts logging audit information into a file named DefaultAuditRecorder.log in the server log directory. If the default audit provider is not sufficient, users can write custom audit providers and have it installed and perform custom activities such as storing in database etc. The security framework is designed in a pluggable fashion and there can be multiple audit providers if desired.

All the components of the security framework such as authentication providers, authorization providers etc. emit audit events. If an audit provider is installed, then it receives these audit events and it can do whatever it wants with it. Obviously, the DefaultAuditProvider simply logs these events.

A generic audit event has the following information – (1) event type (2) severity level (information, warning, error, success and failure). The severity levels also have ranks associated with them, with “information” having the least rank and “failure” the maximum and (3) optional “context info” about the event (things like ejb method name and parameters in an authorization audit event).

The DefaultAuditProvider has configuration to choose the severity and context information to be filtered or propagated. This configuration is of course specific to the DefaultAuditProvider. A custom audit provider can have any other configuration as desired. Once the audit provider is installed, its settings can be changed at runtime without having to bounce WLS instance. All the settings and configurations are done through WLS console.

The security framework components also add extra data to the event by inheriting from the generic audit event. For example, events generated by the authentication provider have sub type which specifies the action being performed – such as authentication, identity assertion, user being locked etc. An authorization provider adds information regarding the resource being accessed and the subject accessing the resource. The interfaces for the sub events are well defined and a custom auditor can be more intelligent when dealing with the events. The DefaultAuditProvider does not bother much and just logs it using the “toString” semantics.