Covering J2EE Security and WebLogic Topics

RoleManager Audit Events in WebLogic

Want to fill up your audit logs quickly? Set the auditor’s severity to INFORMATION and you’re well on your way. In this post we’ll take a closer look and see if the information gained is worthy of the disk space and processing time.

More is Better, Right?

It’s natural to expect that audit logs won’t be as "chatty" as application logging. After all, you’d typically only expect one or a handful of authorization events for each accessed resource. Application logging, on the other hand, might spew dozens of lines per request depending upon the logging level.

With this in mind, your security officer or well-meaning admin might see that the WebLogic DefaultAuditor is initially set to a severity of ERROR leaving not one but TWO severity levels untapped. More security data has to be good, right?

Not necessarily. Besides INFORMATION, the other severity level below ERROR is WARNING. I’ve never seen a WARNING event from the out-of-the-box providers. That’s not to say they don’t exist — just that I’ve never seen one. The INFORMATION severity is the lowest level which only seems to include a certain class of Role Manager events.

Role Manager audit events can be sourced from a Role Mapping provider or an Authorization provider. Useful Role Manager events can happen at the SUCCESS and FAILURE levels, but the INFORMATION-level events are highly repetitive and provide little bang for buck. Here are a couple of examples:

#### Audit Record Begin <Jun 26, 2007 9:20:01 PM> <Severity =INFORMATION> <<<Event Type = RoleManager Audit Event ><Subject: 2
Principal = class weblogic.security.principal.WLSUserImpl("weblogic")
Principal = class weblogic.security.principal.WLSGroupImpl("Administrators")
><<adm>><type=<adm>, category=Configuration><>>> Audit Record End ####

#### Audit Record Begin <Jun 26, 2007 9:20:01 PM> <Severity =INFORMATION> <<<Event Type = RoleManager Audit Event ><Subject: 2
Principal = class weblogic.security.principal.WLSUserImpl("weblogic")
Principal = class weblogic.security.principal.WLSGroupImpl("Administrators")
><<adm>><type=<adm>, category=Configuration><||Anonymous||Admin>>> Audit Record End ####

As you can see, there’s very little actionable information here. Yes, user "weblogic" did something but we’re not quite sure what.

Crunch the Numbers

To give you an idea of the volume of Role Manager events at the INFORMATION severity, I started up a WebLogic 8.1 domain which includes five custom applications. I then logged into console but went no further than the initial page. Here’s the breakdown of audit events (note that I’ve enabled configuration auditing):

Authentication: 2
Authorization: 6
AuthorizationPolicy Deploy: 25
Invoke Configuration: 1
RoleManager: 772
RoleManager Deploy: 3
Set Attribute: 10

As you can see, the RoleManager events account for 94%(!) of all events for my scenario. Hitting Refresh on the console caused approximately the same number of Role Manager events. I haven’t timed it, but writing all of those events to disk is probably quite measurable.

Console makes heavy use of JMX so I suspect a lot of the Role Manager events are caused by that. I tested a "normal" web app with just a protected page. Here are the results:

Authentication: 1
Authorization: 1
RoleManager: 14

Thus, for one request, the Role Manager events comprise 88% of the total number of events. The information is slightly different (and maybe even a little useful) as long as you don’t mind seeing it a bunch of times. Here are a couple events:

#### Audit Record Begin <Jun 26, 2007 10:44:08 PM> <Severity =INFORMATION> <<<Event Type = RoleManager Audit Event ><Subject: 2
Principal = class weblogic.security.principal.WLSUserImpl("weblogic")
Principal = class weblogic.security.principal.WLSGroupImpl("Administrators")
><<url>><type=<url>, application=ImplicitGroupsApp, contextPath=/implicitgroupsapp, uri=/users/users.jsp, httpMethod=GET><>>> Audit Record End ####

#### Audit Record Begin <Jun 26, 2007 10:44:08 PM> <Severity =INFORMATION> <<<Event Type = RoleManager Audit Event ><Subject: 2
Principal = class weblogic.security.principal.WLSUserImpl("weblogic")
Principal = class weblogic.security.principal.WLSGroupImpl("Administrators")
><<url>><type=<url>, application=ImplicitGroupsApp, contextPath=/implicitgroupsapp, uri=/users/users.jsp, httpMethod=GET><||user||Anonymous||everyone||Admin>>> Audit Record End ####

I suspect these are sourced by the authorization provider given that it’s showing the requested resource information. The list of roles is barely useful — which one is required?

Quantum Logging

If you decide to not use the INFORMATION severity you can still get the equivalent information from the audit log if you had to. The first thing to consider is the Authorization event. Here’s the event that accompanied the RoleManager event above:

#### Audit Record Begin <Jun 26, 2007 10:44:08 PM> <Severity =SUCCESS> <<<Event Type = Authorization Audit Event ><Subject: 2
Principal = class weblogic.security.principal.WLSUserImpl("weblogic")
Principal = class weblogic.security.principal.WLSGroupImpl("Administrators")
><ONCE><<url>><type=<url>, application=ImplicitGroupsApp, contextPath=/implicitgroupsapp, uri=/users/users.jsp, httpMethod=GET>>> Audit Record End ####

Notice that the resource information is identical to the equivalent RoleManager event.

How can you know which role was required for "/users/users.jsp?" One way is to check that application’s web.xml. However, that data could be newer than what was in place when the event was logged (e.g., web.xml was updated and the app was redeployed after the event).

A better way to do it is to find the most recent corresponding Authorization Policy Deploy event prior to the authorization event in question. For example,

#### Audit Record Begin <Jun 26, 2007 9:12:12 PM> <Severity =SUCCESS> <<<Event Type = Authorization Policy Deploy Audit Event ><Subject: 1
Principal = class weblogic.security.principal.WLSKernelIdentity("<WLS Kernel>")
><<url>><type=<url>, application=ImplicitGroupsApp, contextPath=/implicitgroupsapp, uri=/users/*, httpMethod=GET><user>>> Audit Record End ####

shows one of the policies for the ImplicitGroupsApp. Note that the policy applies to "/users/*" and requires the "user" role for URIs with that pattern.

This concludes our little romp through an audit log. If you choose to not select the INFORMATION severity you can save yourself considerable disk space while still retaining the ability to get the data you need.

Recording WLST Scripts in WebLogic 10

As I mentioned in my WebLogic 10 Released post, WebLogic 10 has the ability to record your sessions in the console as WLST scripts. Unfortunately, doing so takes all the excitement and mystery out of sleuthing around for MBean information! 😉

Even though it was deprecated in Weblogic 9, weblogic.Admin is still around which means you can still use the techniques described in Find WebLogic MBeans with Ease and Using Audit Logs to Make Scripting Easier. Furthermore, the approaches given in those posts give you the real object names of the MBeans in case you need to do some JMX work. Otherwise, WLST is the way to go for normal server configuration. The rest of this post will be a quick walk-through of the new script recording feature.

The first thing you’ll notice when you load the WebLogic 10 console is that it looks very similar to the WebLogic 9 console. You’ll also quickly notice the disabled “Record” link and the “Record WLST Scripts” link under “How Do I…” The simple steps below illustrate how to record a configuration script:

  1. Click the “Lock & Edit” button
  2. Click the Record link which is now enabled. A message like the following is displayed:

    The recording session has started. Recording to C:\BEA10\user_projects\domains\Test\AddAuditorScript.py.

  3. Configure whatever you want in the console. I happened to add an auditor. When you’re done, go to the next step.
  4. Click the “Activate Changes” button
  5. Navigate to Preferences->WLST Script Recording and click the Stop Recording button. You can also see the contents of the script file on this page. For adding an auditor and setting the severity, my script file looks like this:

    cmo.createAuditor(‘TestAuditor’, ‘weblogic.security.providers.audit.DefaultAuditor’)

    cd(‘/SecurityConfiguration/Test/Realms/myrealm/Auditors/TestAuditor’)
    cmo.setSeverity(‘INFORMATION’)

    activate()

Doesn’t get much easier than that, does it?

At this point you can edit the script (outside of console, of course) or do whatever you need to do. Then, you can subsequently run the script as you would any WLST script.

If you are interested in recording scripts, you should read the “How Do I” link since there are some things the recorder won’t do. For example, it won’t record the addition or deletion of users, roles, or policies. You can also learn about how the recorder handles encrypted values.

Finally, if you’re running Weblogic 9 and wish you could record scripts, look no further than the WLST Script Generator. At the other end of this link you will find Satya Ghattu‘s script generator and accompanying console extension for WebLogic 9. Thanks to Andre Glauser for passing along the link.

 

Bookmark this page on del.icio.us