Covering J2EE Security and WebLogic Topics

WebLogic Auditing

According to the explanatory text in the WebLogic Console:

"An Auditing provider collects, stores, and distributes information about operating requests and the outcome of those requests for the purposes of non-repudiation. You can configure multiple Auditing providers in a security realm, but none are required."

This article will discuss how to configure WebLogic to audit security events and configuration changes.

Auditing Security Events

By default, WebLogic does not have auditing turned on. To enable auditing, configure an audit provider in WebLogic Console by navigating to the Auditing Providers section of the active security realm. In the WebLogic 8.1 Console applet, drill down to mydomain->Security->Realms->myrealm->Providers->Auditing.

Add a new DefaultAuditor and click Create. You can set the auditing severity and log rotation time in the Details tab. The DefaultAuditor writes to a file called DefaultAuditRecorder.log in your server directory alongside access.log and myserver.log.

The DefaultAuditor doesn’t have any settings other than severity and rotation time. To have auditing take effect you’ll have to restart WebLogic. Now, whenever auditable security actions such as authentication or authorization occur, a line describing the event and the outcome is recorded in the audit log. Be aware that the audit log can be very verbose so keep an eye on disk space and performance.

Here’s an example authorization event from DefaultAuditRecorder.log:

#### Audit Record Begin <Mar 9, 2006 6:38:48 PM> <Severity =SUCCESS> <<<Event Type = Authorization Audit Event ><Subject: 2
Principal = class"weblogic")
Principal = class"Administrators")
><ONCE><<url>><type=<url>, application=console, contextPath=/console, uri=/actions/mbean/editmbeanaction, httpMethod=GET>>> Audit Record End ####

Auditing Configuration Changes

The auditing process typically only involves security events as they relate to the security providers. For example, events such as authentication, identity assertion, authorization, role mapping, etc., get audited. But what if you’d like to be able to audit any of the following actions:

  • Addition/deletion of configuration items
  • Modification of a setting
  • Addition/deletion of a user, group, etc.
  • Password resets
  • And so on

    These are things that a WebLogic administrator can do in WebLogic Console or via other forms of configuration MBean access such as scripting or weblogic.Admin. Logging these events is as simple as making one configuration change.

    In WebLogic Console, navigate to the domain screen. In WebLogic 8.1, simply click on the domain node in the applet. On the right hand side, set Configuration Auditing from None to one of the following

    • log
    • audit
    • logaudit

      and click Apply.

      Choosing "log" causes the configuration events to go to the server log (e.g., myserver.log). That’s right, you don’t have to have an audit provider configured to capture the data. Choosing "audit," on the other hand, causes the configuration events to be sent to the audit providers. Finally, "logaudit" causes the data to be sent to both places.

      This setting takes effect immediately, so after you clicked Apply configuration changes are logged.

      Here’s an example from the DefaultAuditRecorder.log of the "weblogic" user changing the SSL listen port from 443 to 444:

      #### Audit Record Begin <Mar 9, 2006 10:19:34 PM> <Severity =SUCCESS> <<<Event Type = SetAttribute Configuration Audit Event><Subject = Subject: 2
      Principal = class"weblogic")
      Principal = class"Administrators")
      ><Object = AppSec:Name=myserver,Server=myserver,Type=SSL><Attribute = ListenPort><From = 443><To = 444>>> Audit Record End ####

      The corresponding entry from the server log file is a little more readable:

      ####<Mar 9, 2006 10:19:34 PM EST> <Info> <Configuration Audit> <Laptop> <myserver> <ExecuteThread: ‘1’ for queue: ‘weblogic.admin.HTTP’> <weblogic> <> <BEA-159904> <USER weblogic MODIFIED AppSec:Name=myserver,Server=myserver,Type=SSL ATTRIBUTE ListenPort FROM 443 TO 444>

      Advanced Auditing

      Clearly, all of these event types can find their way to the audit providers. The significance of this is that you can write your own auditor to process the events in any way you’d like. Have a look at a set of sample security providers (with source) from BEA for a quick start at building your own.

      Let me know when you’ve written an audit provider for emailing the boss when some bozo changes the SSL port to 444! 😉