Auditing Providers

9 Auditing Providers

This chapter describes Auditing provider concepts and functionality, and provides step-by-step instructions for developing a custom Auditing provider.

Auditing is the process whereby information about operating requests and the outcome of those requests are collected, stored, and distributed for the purposes of non-repudiation. In WebLogic Server, an Auditing provider provides this electronic trail of computer activity.

This chapter includes the following sections:

Auditing Concepts

Before you develop an Auditing provider, you need to understand the following concepts:

Audit Channels

An Audit Channel is the component of an Auditing provider that determines whether a security event should be audited, and performs the actual recording of audit information based on Quality of Service (QoS) policies.

Note:

See Implement the AuditChannel SSPI.

Auditing Events From Custom Security Providers

Each type of security provider can call the configured Auditing providers with a request to write out information about security-related events, before or after these events take place. For example, if a user attempts to access a withdraw method in a bank account application (to which they should not have access), the authorization provider can request that this operation be recorded. Security-related events are only recorded when they meet or exceed the severity level specified in the configuration of the Auditing providers.

For information about how to post audit events from a custom security provider, see Auditing Events From Custom Security Providers.

The Auditing Process

Figure 9-1 shows how Auditing providers interact with the WebLogic Security Framework and other types of security providers (using authentication providers as an example) to audit selected events. An explanation follows.

Figure 9-1 Auditing Providers, the WebLogic Security Framework, and Other Security Providers

Description of "Figure 9-1 Auditing Providers, the WebLogic Security Framework, and Other Security Providers"

Auditing providers interact with the WebLogic Security Framework and other types of security providers in the following manner:

Note:

In Figure 9-1 and the explanation below, the other types of security providers are a WebLogic Authentication provider and a custom authentication provider. However, these can be any type of security provider that is developed as described in Auditing Events From Custom Security Providers.

A resource container passes a user's authentication information (for example, a username/password combination) to the WebLogic Security Framework as part of a login request.
The WebLogic Security Framework passes the information associated with the login request to the configured authentication providers.
If, in addition to providing authentication services, the authentication providers are designed to post audit events, the authentication providers will each:
1. Instantiate an AuditEvent object. At minimum, the AuditEvent object includes information about the event type to be audited and an audit severity level.
  
  Note:
  
  An AuditEvent class is created by implementing either the AuditEvent SSPI or an AuditEvent convenience interface in the authentication provider's runtime class, in addition to the other security service provider interfaces (SSPIs) the custom authentication provider must already implement. See Create an Audit Event.
2. Make a trusted call to the Auditor Service, passing in the AuditEvent object.
  
  Note:
  
  This is a trusted call because the Auditor Service is already passed to the security provider's initialize method as part of its Provider SSPI implementation. See Understand the Purpose of the Provider SSPIs.
The Auditor Service passes the AuditEvent object to the configured Auditing providers' runtime classes (that is, the AuditChannel SSPI implementations), enabling audit event recording.

Note:

Depending on the authentication providers' implementations of the AuditEvent convenience interface, audit requests may occur both pre and post event, as well as just once for an event.
The Auditing providers' runtime classes use the event type, audit severity and other information (such as the Audit Context) obtained from the AuditEvent object to control audit record content. Typically, only one of the configured Auditing providers will meet all the criteria for auditing.

Note:

See Audit Severity and Audit Context, respectively.
When the criteria for auditing specified by the authentication providers in their AuditEvent objects is met, the appropriate Auditing provider's runtime class (that is, the AuditChannel SSPI implementation) writes out audit records in the manner their implementation specifies.

Note:

Depending on the AuditChannel SSPI implementation, audit records may be written to a file, a database, or some other persistent storage medium when the criteria for auditing is met.

Implementing the ContextHandler MBean

The ContextHandlerMBean, weblogic.management.security.audit.ContextHandler, provides a set of attributes for ContextHandler support. You use this interface to manage audit providers that support context handler entries in a standard way.

An Auditor provider MBean can optionally implement the ContextHandlerMBean MBean. The Auditor provider can then use the MBean to determine the supported and active ContextHandler entries.

The WebLogic Remote Console detects when an Auditor provider implements this MBean and automatically provides a tab for using these attributes.

Note:

The ContextHandler entries associated with the ContextHandlerMBean are not related to, nor do they affect, the contents of an AuditEvent that is passed to the Audit providers. An AuditEvent received by a provider may or may not include a ContextHandler with ContextElements. If a ContextHandler is included, an Audit provider can get the ContextHandler from the AuditEvent, regardless of whether you implemented the ContextHandlerMBean management interface. In particular, the AuditContext getContext method returns a weblogic.security.service.ContextHandler interface that is independent of the context handler implemented by the ContextHandlerMBean.

You can choose to implement the ContextHandlerMBean context handler in a manner that compliments the AuditContext getContext method. (The SimpleSampleAuditProviderImpl.java sample takes this approach.) However, there is no requirement that you do so.

ContextHandlerMBean Methods

The ContextHandlerMBean interface implements the following methods:

getActiveContextHandlerEntries
```
public String[] getActiveContextHandlerEntries()
```
Returns the ContextHandler entries that the Audit provider is currently configured to process.
getSupportedContextHandlerEntries
```
public String[] getSupportedContextHandlerEntries()
```
Returns the list of all ContextHandler entries supported by the auditor.
setActiveContextHandlerEntries
```
public void setActiveContextHandlerEntries(String[] types) throws InvalidAttributeValueException
```
Sets the ContextHandler entries that the Audit provider will process. The entries you specify must be listed in the Audit provider's SupportedContextHandlerEntries attribute.

Example: Implementing the ContextHandlerMBean

Example 9-5 shows the SimpleSampleAuditProviderImpl.java class, which is the runtime class for the sample Auditing provider. This sample Auditing provider has been enhanced to implement the ContextHandlerMBean.

An MBean Definition File (MDF) is an XML file used by the WebLogic MBeanMaker utility to generate the Java files that comprise an MBean type. All MDFs must extend a required SSPI MBean that is specific to the type of the security provider you have created, and can implement optional SSPI MBeans.

Example 9-1 shows the key sections of the MDF for the sample Auditing provider, which implements the optional ContexthandlerMBean.

Example 9-1 Example: SimpleSampleAuditor.xml

<MBeanType
Name          = "SimpleSampleAuditor"
DisplayName   = "SimpleSampleAuditor"
Package       = "examples.security.providers.audit.simple"
Extends       = "weblogic.management.security.audit.Auditor"
Implements    = "weblogic.management.security.audit.ContextHandler"
PersistPolicy = "OnUpdate"
>
...
<MBeanAttribute
Name          = "SupportedContextHandlerEntries"
Type          = "java.lang.String[]"
Writeable     = "false"
Default       = "new String[] { 
&quot;com.bea.contextelement.servlet.HttpServletRequest&quot; }"
Description   = "List of all ContextHandler entries
supported by the auditor."
/>

Extend weblogic.management.security.audit.ContextHandlerImpl

The ContextHandlerMBean has an setActiveContextHandlerEntries attribute that sets the ContextHandler entries that the Audit provider is currently configured to process. The entries you specify must be listed in the Audit provider's SupportedContextHandlerEntries attribute. However, this requirement is not actually enforced by the MBean. Additional work is required to validate that this attribute can set only values from the SupportedContextHandlerEntries attribute.

You must also create an MBean customizer (for example, you might call it MyAuditorImpl.java) file that extends weblogic.management.security.audit.ContextHandlerImpl. Extending weblogic.management.security.audit.ContextHandlerImpl gives the provider access to the ActiveContextHandlerEntries attribute validator, which ensures that the entries include only SupportedContextHandlerEntries.

An example of extending ContextHandlerImpl is available in SimpleSampleAuditorImpl, which is shown in Example 9-2.

After you implement code similar to that in SimpleSampleAuditorImpl, add code to your Audit runtime provider to get the ActiveContextHandlerEntries. One possible way to do this is shown in Example 9-3.

Example 9-2 SimpleSampleAuditorImpl

package examples.security.providers.audit.simple;
import javax.management.MBeanException;
import javax.management.modelmbean.RequiredModelMBean;
import weblogic.management.security.audit.ContextHandlerImpl;

/**
* The simple sample auditor's mbean implementation.
* <p>
* It is needed to inherit the ContextHandlerMBean's ActiveContextHandlerEntries
* attribute validator that ensures that the ActiveContextHandlerEntries
* attribute only contains values from the SupportedContextHandlerEntries
* attribute.
*
* @author Copyright © 1996, 2008, Oracle and/or its affiliates.
* All rights reserved.
*/
public class SimpleSampleAuditorImpl extends ContextHandlerImpl
// Note: extend ContextHandlerImpl instead of AuditorImpl to inherit
// the ActiveContextHandlerEntries attribute validator.
{
/**
* Standard mbean impl constructor.
*
* @throws MBeanException
*/
public SimpleSampleAuditorImpl(RequiredModelMBean base) throws MBeanException
{
super(base);
}
}

Example 9-3 Getting Active Context Handler Entries

 String [] activeHandlerEntries = myMBean.getActiveContextHandlerEntries();
    if (activeHandlerEntries != null) {
      for (int i=0; i<activeHandlerEntries.length; i++) {
        if ((activeHandlerEntries[i] != null) &&
            (activeHandlerEntries[i].equalsIgnoreCase(HTTP_REQUEST_ELEMENT))) {
          handlerEnabled = true;
          break;
        }
      }
    }

Do You Need to Develop a Custom Auditing Provider?

The default (that is, active) security realm for WebLogic Server includes a WebLogic Auditing provider. The WebLogic Auditing provider records information from a number of security requests, which are determined internally by the WebLogic Security Framework. The WebLogic Auditing provider also records the event data associated with these security requests, and the outcome of the requests.

The WebLogic Auditing provider makes an audit decision in its writeEvent method, based on the audit severity level it has been configured with and the audit severity contained within the AuditEvent object that is passed into the method. See Create an Audit Event.

Note:

You can change the audit severity level that the WebLogic Auditing provider is configured with using the WebLogic Remote Console. See Configuring a WebLogic Auditing Provider in Administering Security for Oracle WebLogic Server.

If there is a match, the WebLogic Auditing provider writes audit information to the DefaultAuditRecorder.log file, which is located in the WL_HOME\yourdomain\yourserver\logs directory. Example 9-4 is an excerpt from the DefaultAuditRecorder.log file.

Example 9-4 DefaultAuditRecorder.log File: Sample Output

When Authentication suceeds. [SUCCESS]
#### Audit Record Begin <Feb 23, 2005 11:42:17 AM>  <Severity=SUCCESS> 
<<<Event Type = Authentication Audit Event><TestUser><AUTHENTICATE>>> Audit 
Record End ####
When Authentication fails. [FAILURE]
#### Audit Record Begin <Feb 23, 2005 11:42:01 AM>  <Severity=FAILURE> 
<<<Event Type = Authentication Audit Event><TestUser><AUTHENTICATE>>> Audit
Record End ####When Operations are invoked.[SUCCESS]
When a user account is unlocked. [SUCCESS]
#### Audit Record Begin <Feb 23, 2005 11:42:17 AM>  <Severity=SUCCESS> 
<<<Event Type = Authentication Audit Event><TestUser><USERUNLOCKED>>> Audit 
Record End ####
When an Authorization request succeeds. [SUCCESS]
#### Audit Record Begin <Feb 23, 2005 11:42:17 AM>  <Severity=SUCCESS> 
<<<Event Type = Authorization Audit Event ><Subject: 1
Principal = class weblogic.security.principal.WLSUserImpl("TestUser")
><ONCE><<jndi>><type=<jndi>, application=, path={weblogic}, action=lookup>>>
Audit Record End ####

Specifically, Example 9-4 shows the Role Manager (a component in the WebLogic Security Framework that deals specifically with security roles) recording an audit event to indicate that an authorized administrator has accessed a protected method in a certificate servlet.

You can specify a new directory location for the DefaultAuditRecorder.log file on the command line with the following Java startup option:

-Dweblogic.security.audit.auditLogDir=c:\foo

The new file location will be c:\foo\yourserver\DefaultAuditRecorder.log.

If you want to write audit information in addition to that which is specified by the WebLogic Security Framework, or to an output repository that is not the DefaultAuditRecorder.log (that is, to a simple file with a different name/location or to an existing database), then you need to develop a custom Auditing provider.

How to Develop a Custom Auditing Provider

If the WebLogic Auditing provider does not meet your needs, you can develop a custom Auditing provider by following these steps:

Create Runtime Classes Using the Appropriate SSPIs
Generate an MBean type for your custom auditing provider by completing the steps described in Generate an MBean Type Using the WebLogic MBeanMaker.
Configure the Custom Auditing Provider

Note:

After creating a custom Auditing provider, if you are using WLST to manage your custom Auditing provider configuration, you must ensure that the provider interface jar is specified in the WLST_EXT_CLASSPATH environment variable. Optionally, you can set the location of the directory containing the provider jar using the -Dweblogic.alternateTypesDirectory system property in the CONFIG_JVM_ARGS environment variable.

Create Runtime Classes Using the Appropriate SSPIs

Before you start creating runtime classes, you should first:

When you understand this information and have made your design decisions, create the runtime classes for your custom Auditing provider by following these steps:

For an example of how to create a runtime class for a custom Auditing provider, see Example: Creating the Runtime Class for the Sample Auditing Provider.

Implement the AuditProvider SSPI

To implement the AuditProvider SSPI, provide implementations for the methods described in Understand the Purpose of the Provider SSPIs and the following method:

getAuditChannel
```
public AuditChannel getAuditChannel();
```
The getAuditChannel method obtains the implementation of the AuditChannel SSPI. For a single runtime class called MyAuditProviderImpl.java, the implementation of the getAuditChannel method would be:
```
return this;
```
If there are two runtime classes, then the implementation of the getAuditChannel method could be:
```
return new MyAuditChannelImpl;
```
This is because the runtime class that implements the AuditProvider SSPI is used as a factory to obtain classes that implement the AuditChannel SSPI.

See Java API Reference for Oracle WebLogic Server for the AuditProvider SSPI.

Implement the AuditChannel SSPI

To implement the AuditChannel SSPI, provide an implementation for the following method:

writeEvent
```
public void writeEvent(AuditEvent event)
```
The writeEvent method writes an audit record based on the information specified in the AuditEvent object that is passed in. See Create an Audit Event.

See Java API Reference for Oracle WebLogic Server for the AuditChannel SSPI.

Example: Creating the Runtime Class for the Sample Auditing Provider

Example 9-5 shows the SimpleSampleAuditProviderImpl.java class, which is the runtime class for the sample Auditing provider. This runtime class includes implementations for:

The three methods inherited from the SecurityProvider interface: initialize, getDescription and shutdown (as described in Understand the Purpose of the Provider SSPIs.)
The method inherited from the AuditProvider SSPI: the getAuditChannel method (as described in Implement the AuditProvider SSPI).
The method in the AuditChannel SSPI: the writeEvent method (as described in Implement the AuditChannel SSPI).

Note:

The bold face code in Example 9-5 highlights the class declaration and the method signatures.

Example 9-5 SimpleSampleAuditProviderImpl.java

package examples.security.providers.audit.simple;
import java.io.File;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.PrintStream;
import javax.servlet.http.HttpServletRequest;
import weblogic.management.security.ProviderMBean;
import weblogic.security.service.ContextHandler;
import weblogic.security.spi.AuditChannel;
import weblogic.security.spi.AuditContext;
import weblogic.security.spi.AuditEvent;
import weblogic.security.spi.AuditProvider;
import weblogic.security.spi.SecurityServices;

public final class SimpleSampleAuditProviderImpl implements AuditProvider, AuditChannel
{
   private String      description; // a description of this provider
   private PrintStream log;         // the log file that events are written to
   private boolean     handlerEnabled = false;
   private final static String HTTP_REQUEST_ELEMENT =
 "com.bea.contextelement.servlet.HttpServletRequest";
   public void initialize(ProviderMBean mbean, SecurityServices services)
   {
     System.out.println("SimpleSampleAuditProviderImpl.initialize");
     SimpleSampleAuditorMBean myMBean = (SimpleSampleAuditorMBean)mbean;
     description = myMBean.getDescription() + "\n" + myMBean.getVersion();
     String [] activeHandlerEntries = myMBean.getActiveContextHandlerEntries();
     if (activeHandlerEntries != null) {
       for (int i=0; i<activeHandlerEntries.length; i++) {
         if ((activeHandlerEntries[i] != null) &&
             (activeHandlerEntries[i].equalsIgnoreCase(HTTP_REQUEST_ELEMENT))) {
           handlerEnabled = true;
           break;
        }
       }
     }
     File file = new File(myMBean.getLogFileName());
     System.out.println("\tlogging to " + file.getAbsolutePath());
     try {
       log = new PrintStream(new FileOutputStream(file), true);
     } catch (IOException e) {
       throw new RuntimeException(e.toString());
     }
   }

   public String getDescription()
   {
     return description;
   }
   public void shutdown()
   {
     System.out.println("SimpleSampleAuditProviderImpl.shutdown");
     log.close();
   }
   public AuditChannel getAuditChannel() 
   {
     return this;
   }
   public void writeEvent(AuditEvent event) 
   {
     log.println(event);

     if ((!handlerEnabled) || (!(event instanceof AuditContext)))
       return;

     AuditContext auditContext = (AuditContext)event;
     ContextHandler handler = auditContext.getContext();

     if ((handler == null) || (handler.size() == 0))
       return;

     Object requestValue = handler.getValue("com.bea.contextelement.servlet.HttpServletRequest");
     if ((requestValue == null) || (!(requestValue instanceof HttpServletRequest)))
       return;
     HttpServletRequest request = (HttpServletRequest) requestValue;
     log.println("    " + HTTP_REQUEST_ELEMENT + " method: " + request.getMethod());
     log.println("    " + HTTP_REQUEST_ELEMENT + " URL: " + request.getRequestURL());
     log.println("    " + HTTP_REQUEST_ELEMENT + " URI: " + request.getRequestURI());
     return;
   }
}

Configure the Custom Auditing Provider

Configuring a custom Auditing provider means that you are adding the custom Auditing provider to your security realm, where it can be accessed by security providers requiring audit services.

Configuring custom security providers is an administrative task, but it is a task that may also be performed by developers of custom security providers. This section contains information that is important for the person configuring your custom Auditing providers:

Configuring Audit Severity

Note:

The steps for configuring a custom Auditing provider are described in Configuring WebLogic Security Providers in Administering Security for Oracle WebLogic Server.

Configuring Audit Severity

During the configuration process, an Auditing provider's audit severity must be set to one of the following severity levels:

INFORMATION
WARNING
ERROR
SUCCESS
FAILURE

Security Framework Audit Events

This section describes the audit events that are posted by the WebLogic Server Security Framework. If you write a custom audit provider, it should be prepared to handle these events. The following topics are covered in this section:

Passing Additional Audit Information

The WebLogic Security providers implement the appropriate AuditEvent interfaces and post those events to the Audit provider. The audit events that also implement the AuditContext interface can provide more information via a ContextHandler.

Table 9-1 lists the weblogic.security.spi subinterfaces that extend the AuditEvent SSPI, and indicates which subinterfaces implement the AuditContext interface.

Table 9-1 Audit Events

Audit Event Name	Interface Class	Audit Event	Audit Context
Application Version Event	`weblogic.security.spi.AuditApplicationVersionEvent`	Yes	No
Authentication Audit Event	`weblogic.security.spi.AuditAtnEvent`	Yes	No
Authentication Audit Event V2	`weblogic.security.spi.AuditAtnEventV2`	Yes	Yes
Authorization Audit Event	`weblogic.security.spi.AuditAtzEvent`	Yes	Yes
CertPathBuilder Audit Event	`weblogic.security.spi.AuditCertPathBuilderEvent`	Yes	Yes
CertPathValidator Audit Event	`weblogic.security.spi.AuditCertPathValidatorEvent`	Yes	Yes
Configuration Audit Event	`weblogic.security.spi.AuditConfigurationEvent`	Yes	Yes
Credential Mapping Audit Event	`weblogic.security.spi.AuditCredentialMappingEvent`	Yes	Yes
Life Cycle Event	`weblogic.security.spi.AuditLifecycleEvent`	Yes	No
Audit Management Event	`weblogic.security.spi.AuditMgmtEvent`	Yes	No
Policy Audit Event	`weblogic.security.spi.AuditPolicyEvent`	Yes	No
Policy Consumer Audit Event	`weblogic.security.service.internal.PolicyConsumerAuditEvent`	AuditPolicyEvent	No
Provider Audit Record	`com.bea.security.spi.ProviderAuditRecord`	Yes	Yes
Role Consumer Audit Event	`weblogic.security.service.internal.RoleConsumerAuditEvent`	AuditRoleEvent	Yes
Role Deployment Audit Event	`weblogic.security.spi.AuditRoleDeploymentEvent`	Yes	No
Role Mapping Audit Event	`weblogic.security.spi.AuditRoleEvent`	Yes	Yes

Audit Event Interfaces and Audit Events

In the weblogic.security.spi package, WebLogic Security defines one top-level base interface (AuditEvent) with derived interfaces that represent the different types of audit events.

Subsequent sections describe when the security framework and security providers post the following audit events:

AuditApplicationVersionEvent
AuditAtnEventV2
AuditAtzEvent
AuditCerPathBuilderEvent, AuditCertPathValidatorEvent
AuditConfigurationEvent (AuditCreateConfigurationEvent, AuditDeleteConfigurationEvent, AuditInvokeConfigurationEvent, AuditSetAttributeConfigurationEvent)
AuditCredentialMappingEvent
AuditLifecycleEvent
AuditMgmtEvent
AuditPolicyEvent (AuditEndPolicyDeployEvent, AuditPolicyDeleteAppEvent, AuditPolicyDeployEvent, AuditPolicyUndeployEvent, AuditResourceProtectedEvent, AuditStartPolicyDeployEvent, PolicyConsumerAuditEvent)
AuditRoleDeploymentEvent (AuditStartRoleDeployEvent, AuditEndRoleDeployEvent, AuditRoleUndeployEvent, AuditRoleDeleteAppEvent)
AuditRoleEvent (RoleConsumerAuditEvent)

AuditApplicationVersionEvent

Application version audit events are posted by the security framework. You can use the getEventType method to get the type of the audit event. The actual audit string returned by getEventType is String = "Application Version Audit Event".

Table 9-2 describes the conditions under which the event is posted and severity level of the event.

Table 9-2 Application Version Events

Component	Description	Severity
Security Framework	The security framework posts these events for the following reasons: Authorization Manager application version creation has succeeded or failed. Authorization Manager application version deletion has succeeded or failed. Authorization Manager non-versioned application deletion has succeeded or failed. Role Manager application version creation has succeeded or failed. Role Manager application version deletion has succeeded or failed. Role Manager non-versioned application deletion has succeeded or failed. Credential Manager application version creation has succeeded or failed. Credential Manager application version deletion has succeeded or failed. Credential Manager non-versioned application deletion has succeeded or failed.	Success or Failure

Component

Description

Severity

Security Framework

The security framework posts these events for the following reasons:

Authorization Manager application version creation has succeeded or failed.
Authorization Manager application version deletion has succeeded or failed.
Authorization Manager non-versioned application deletion has succeeded or failed.
Role Manager application version creation has succeeded or failed.
Role Manager application version deletion has succeeded or failed.
Role Manager non-versioned application deletion has succeeded or failed.
Credential Manager application version creation has succeeded or failed.
Credential Manager application version deletion has succeeded or failed.
Credential Manager non-versioned application deletion has succeeded or failed.

Success or Failure

AuditAtnEventV2

Authentication audit events are posted by the security framework. You can use the getEventType method to get the type of the audit event. The actual audit string returned by getEventType is String eventType = "Event Type = Authentication Audit Event".

Table 9-3 describes the conditions under which the event is posted and severity level of the event.

Table 9-3 Authentication Audit Events

Component	Description	Severity
Security Framework	Posted after successful authentication of a user.	Success
Security Framework	Posted after unsuccessful authentication (a LoginException thrown from JAAS login method). This LoginException can be thrown by either JAAS framework or by JAAS LoginModule of WebLogic Server authentication provider.	Failure
Security Framework	Posted after an identity assertion to an anonymous user.	Success
Security Framework	Posted after an unsuccessful identity assertion (IdentityAssertionException thrown from identity assertion method)	Failure
Security Framework	Posted after an unsuccessful identity assertion (IOException is thrown by identity assertion callback handler when retrieving username from callback).	Failure
Security Framework	Posted after an unsuccessful identity assertion (UnsupportedCallbackException is thrown by identity assertion callback handler when retrieving username from callback).	Failure
Security Framework	Posted after an unsuccessful identity assertion (when username returned from identity assertion callback handler is null or zero length).	Failure
Security Framework	Posted after a successful identity assertion.	Success
Security Framework	Posted after an unsuccessful identity assertion.	Failure
Security Framework	Posted after a successful impersonate identity (anonymous identity).	Success
Security Framework	Posted after a successful impersonate identity.	Success
Security Framework	Posted after an unsuccessful impersonate identity.	Failure
Security Framework	Posted after a failure of principal validation.	Failure

AuditAtzEvent

Authorization audit events are posted by the security framework. You can use the getEventType method to get the type of the audit event. The actual audit string returned by getEventType is String eventType = "Event Type = Authorization Audit Event V2 ".

Table 9-4 describes the conditions under which the events are posted and severity level of the event.

Table 9-4 Authorization Audit Events

Component	Description	Severity
Security Framework	Posted if access is not allowed to resource (exception thrown by authorization provider).	Failure
Security Framework	Posted if access is allowed to resource.	Success
Security Framework	Posted if access is not allowed to resource.	Failure

AuditCerPathBuilderEvent, AuditCertPathValidatorEvent

CertPath Builder and Validation audit events are posted by the security framework. You can use the getEventType method to get the type of the audit event. The actual audit strings returned by getEventType are as follows:

String eventType = "Event Type = CertPathBuilder Audit Event "
String eventType = "Event Type = CertPathValidator Audit Event "

Table 9-5 describes the conditions under which the events are posted and severity level of the event.

Table 9-5 CertPath Builder and Validation Events

Component	Description	Severity
Security Framework	Posted if the Certificate Path is successfully built.	Success
Security Framework	Posted if the Certificate Path is not successfully built.	Failure
Security Framework	Posted if the Certificate Path is successfully validated.	Success
Security Framework	Posted if the Certificate Path is not successfully validated.	Failure

AuditConfigurationEvent

Configuration audit events are posted by the security framework. The following events are posted:

AuditConfigurationEvent
AuditCreateConfigurationEvent (The actual audit string returned by getEventType is String CREATE_EVENT = "Create Configuration Audit Event")
AuditDeleteConfigurationEvent (The actual audit string returned by getEventType is String DELETE_EVENT = "Delete Configuration Audit Event")
AuditInvokeConfigurationEvent (The actual audit string returned by getEventType is String INVOKE_EVENT = "Invoke Configuration Audit Event")
AuditSetAttributeConfigurationEvent (The actual audit string returned by getEventType is String SETATTRIBUTE_EVENT = "SetAttribute Configuration Audit Event")

Table 9-6 describes the conditions under which the events are posted and severity level of the events.

Table 9-6 Audit Configuration Events

Component	Description	Severity
WebLogic Management Infrastructure	The WebLogic Management infrastructure implements this interface and may post configuration audit events for the following configuration change events: A request to create a new configuration artifact has been allowed or disallowed. A request to delete an existing configuration artifact has been allowed or disallowed. A request to modify an existing configuration artifact has been allowed or disallowed. A invoke an operation on an existing configuration artifact has been allowed or disallowed.	Success or Failure

Component

Description

Severity

WebLogic Management Infrastructure

The WebLogic Management infrastructure implements this interface and may post configuration audit events for the following configuration change events:

A request to create a new configuration artifact has been allowed or disallowed.
A request to delete an existing configuration artifact has been allowed or disallowed.
A request to modify an existing configuration artifact has been allowed or disallowed.
A invoke an operation on an existing configuration artifact has been allowed or disallowed.

Success or Failure

AuditCredentialMappingEvent

Credential mapping audit events are posted by the security framework. You can use the getEventType method to get the type of the audit event. The actual audit string returned by getEventType is String EVENT_TYPE = "Event Type = Credential apping Audit Event".

Table 9-7 describes the condition under which the events are posted and severity level of the event.

Table 9-7 Credential Mapping Audit Events

Component	Description	Severity
Security Framework	The WebLogic Security Framework implements this interface and may post audit events for the following security events: Credentials for a WebLogic Server User are requested Credentials for a Subject are requested	Success

Component

Description

Severity

Security Framework

The WebLogic Security Framework implements this interface and may post audit events for the following security events:

Credentials for a WebLogic Server User are requested

Credentials for a Subject are requested

Success

AuditLifecycleEvent

The AuditLifecycleEvent interface is used to post audit lifecycle events. The WebLogic Security Framework implements this interface and may post audit events for the following security events:

After the auditing service in the framework is started.
Before the auditing service in the framework is stopped.

The actual audit string returned by getEventType is String eventType = "Event Type = AuditLifecycle Audit Event".

The AuditLifecycleEventType class describes the audit service lifecycle event types that are supported. Possible values are START_AUDIT and STOP_AUDIT.

An Auditing provider can use this interface to get additional information about the audit lifecycle event. The AuditSeverity and AuditLifecycleEventType attributes can be used to determine which of the above audit events has been posted.

AuditMgmtEvent

Management audit events are not currently posted by either the Security Framework or by the supplied providers. However, a custom security provider may implement this interface and post different audit events for the various management operations performed by the custom security provider.

An Auditing provider can use this interface to get additional information about the management audit event. The AuditSeverity attribute can be used to determine whether the management operation succeeded or failed.

AuditPolicyEvent

AuditPolicyEvent is posted by the security framework and the WebLogic Authorization provider. The security framework posts audit policy events when policies are deployed to or undeployed from an authorization provider. The WebLogic Server authorization provider posts audit policy events when creating, deleting, or updating policies. You can use the getEventType method to get the type of the audit event. The audit events and the actual audit strings returned by getEventType are as follows:

AuditStartPolicyDeployEvent (The actual audit string returned by getEventType is String eventType = "Event Type = Authorization Start Policy Deploy Audit Event ".)
AuditPolicyUndeployEvent (The actual audit string returned by getEventType is String eventType = "Event Type = Authorization Policy Undeploy Audit Event ".)
AuditPolicyDeployEvent (The actual audit string returned by getEventType is String eventType = "Event Type = Authorization Policy Deploy Audit Event ".)
AuditPolicyDeleteAppEvent (The actual audit string returned by getEventType is String eventType = "Event Type = Authorization Delete Application Policies Audit Event ".)
AuditEndPolicyDeployEvent (The actual audit string returned by getEventType is String eventType = "Event Type = Authorization End Policy Deploy Audit Event ".)

For PolicyConsumerAuditEvent, which implements AuditPolicyEvent, the actual audit strings returned by getEventType are:

String eventType = "Event Type = Policy Consumer Get Handler"
String eventType = "Event Type = Policy Consumer Set Policy"
String eventType = "Event Type = Policy Consumer Set Unchecked Policy"
String eventType = "Event Type = Policy Consumer Done"

Table 9-8 describes the conditions under which the events are posted and lists the event severity level.

Table 9-8 Audit Policy Events

Component	Description	Severity
WebLogic Authorization Provider	The WebLogic Authorization provider implements this interface and posts audit events for the following security events: Security policy creation has succeeded. Security policy creation has failed. Security policy removal has succeeded. Security policy removal has failed. A security policy update has succeeded. A security policy update has failed. Application deletion of security policies has succeeded. Application deletion of security policies has failed.	Success or Failure

Component

Description

Severity

WebLogic Authorization Provider

The WebLogic Authorization provider implements this interface and posts audit events for the following security events:
Security policy creation has succeeded.
Security policy creation has failed.
Security policy removal has succeeded.
Security policy removal has failed.
A security policy update has succeeded.
A security policy update has failed.
Application deletion of security policies has succeeded.
Application deletion of security policies has failed.

Success or Failure

AuditRoleDeploymentEvent

The security framework posts audit role deployment events when roles are deployed to or undeployed from a role mapping provider. You can use the getEventType method to get the type of the audit event. The following events are posted:

AuditRoleDeployEvent (The actual audit string returned by getEventType is String eventType = "Event Type = RoleManager Deploy Audit Event ".)
AuditStartRoleDeployEvent (The actual audit string returned by getEventType is String eventType = "Event Type = RoleManager Start Deploy Role Audit Event ".)
AuditEndRoleDeployEvent (The actual audit string returned by getEventType is String eventType = "Event Type = RoleManager End Deploy Role Audit Event ".)
AuditRoleUndeployEvent (The actual audit string returned by getEventType is String eventType = "Event Type = RoleManager Undeploy Audit Event ".)

Table 9-9 describes the conditions under which the events are posted and lists the event severity level.

Table 9-9 Audit Role Deployment Events

Component	Description	Severity
Security Framework	The WebLogic Security Framework implements this interface and may post audit events for the following security events: Security role deployment to a role mapping provider has succeeded. Security role deployment to a role mapping provider has failed. Security role undeployment to a role mapping provider has succeeded. Security role undeployment to a role mapping provider has failed. Application deletion of security roles to a role mapping provider has succeeded. Application deletion of security roles to a role mapping provider has failed.	Success or Failure

Component

Description

Severity

Security Framework

The WebLogic Security Framework implements this interface and may post audit events for the following security events:

Security role deployment to a role mapping provider has succeeded.
Security role deployment to a role mapping provider has failed.
Security role undeployment to a role mapping provider has succeeded.
Security role undeployment to a role mapping provider has failed.
Application deletion of security roles to a role mapping provider has succeeded.
Application deletion of security roles to a role mapping provider has failed.

Success or Failure

AuditRoleEvent

The WebLogic Authorization provider posts audit role events when roles are created, deleted, or updated. You can use the getEventType method to get the type of the audit event. The actual audit strings returned by getEventType are as follows:

String eventType = "Event Type = RoleManager Audit Event "
String eventType = "Event Type = RoleManager Delete Application Roles Audit Event "

For RoleConsumerAuditEvent, which implements AuditRoleEvent, the actual audit strings returned by getEventType are:

String eventType = "Event Type = Role Consumer Get Handler"
String eventType = "Event Type = Role Consumer Set Role"
String eventType = "Event Type = Role Consumer Done"

Table 9-10 describes the conditions under which the events are posted and lists the event severity level.

Table 9-10 Audit Role Events

Component	Description	Severity
WebLogic Authorization Provider	The WebLogic Authorization provider implements this interface and posts audit events for the following security events: Security role creation has succeeded. Security role creation has failed. Security role removal has succeeded. Security role removal has failed. A security role update has succeeded. A security role update has failed.	Success

Component

Description

Severity

WebLogic Authorization Provider

The WebLogic Authorization provider implements this interface and posts audit events for the following security events:

Security role creation has succeeded.
Security role creation has failed.
Security role removal has succeeded.
Security role removal has failed.
A security role update has succeeded.
A security role update has failed.

Success