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.
The following sections describe Auditing provider concepts and functionality, and provide step-by-step instructions for developing a custom Auditing provider:
Before you develop an Auditing provider, you need to understand the following concepts:
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:
For more information about Audit Channels, see Implement the AuditChannel SSPI.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 Chapter 12, "Auditing Events From Custom Security Providers."
Figure 10-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 10-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 10-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 Chapter 12, "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:
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. For more information about Audit Events and the AuditEvent SSPI/convenience interfaces, see Create an Audit Event.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. For more information, 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:
For more information about audit severity levels and the Audit Context, 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 theAuditChannel
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.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 Server Administration 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.
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 10-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 10-1 shows the key sections of the MDF for the sample Auditing provider, which implements the optional ContexthandlerMBean.
Example 10-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[] { "com.bea.contextelement.servlet.HttpServletRequest" }" Description = "List of all ContextHandler entries supported by the auditor." />
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 10-2.
Example 10-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); } }
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 10-3.
Example 10-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; } } }
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. (For more information about AuditEvent objects, see Create an Audit Event.
Note:
You can change the audit severity level that the WebLogic Auditing provider is configured with using the WebLogic Server Administration Console. For more information, see "Configuring a WebLogic Auditing Provider" in Securing 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 10-4 is an excerpt from the DefaultAuditRecorder.log
file.
Example 10-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 10-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.
If the WebLogic Auditing provider does not meet your needs, you can develop a custom Auditing provider by following these steps:
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.
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.
For more information about the AuditProvider SSPI and the getAuditChannel method, see the WebLogic Server API Reference Javadoc.
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. For more information about AuditEvent
objects, see Create an Audit Event.
For more information about the AuditChannel SSPI and the writeEvent method, see the WebLogic Server API Reference Javadoc.
Example 10-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 10-5 highlights the class declaration and the method signatures.Example 10-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; } }
Before you start generating an MBean type for your custom security provider, you should first:
Understand the Basic Elements of an MBean Definition File (MDF)
Understand the SSPI MBean Hierarchy and How It Affects the Administration Console
When you understand this information and have made your design decisions, create the MBean type for your custom Auditing provider by following these steps:
Use the WebLogic MBeanMaker to Create the MBean JAR File (MJF)
Install the MBean Type Into the WebLogic Server Environment
Note:
Several sample security providers (available athttps://codesamples.samplecode.oracle.com/servlets/tracking?id=S224
on the Oracle Technology Network Web site) illustrate how to perform these steps.
All instructions provided in this section assume that you are working in a Windows environment.
To create an MBean Definition File (MDF), follow these steps:
Copy the MDF for the sample Auditing provider to a text file.
Note:
The MDF for the sample Auditing provider is calledSampleAuditor.xml
.Modify the content of the <MBeanType>
and <MBeanAttribute>
elements in your MDF so that they are appropriate for your custom Auditing provider.
Add any custom attributes and operations (that is, additional <MBeanAttribute>
and <MBeanOperation>
elements) to your MDF.
Save the file.
Note:
A complete reference of MDF element syntax is available in Appendix A, "MBean Definition File (MDF) Element Syntax."Once you create your MDF, you are ready to run it through the WebLogic MBeanMaker. The WebLogic MBeanMaker is currently a command-line utility that takes as its input an MDF, and outputs some intermediate Java files, including an MBean interface, an MBean implementation, and an associated MBean information file. Together, these intermediate files form the MBean type for your custom security provider.
The instructions for generating an MBean type differ based on the design of your custom Auditing provider. Follow the instructions that are appropriate to your situation:
If the MDF for your custom Auditing provider does not include any custom operations, follow these steps:
Create a new DOS shell.
Type the following command:
java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
where the -DMDF
flag indicates that the WebLogic MBeanMaker should translate the MDF into code, xmlFile is the MDF (the XML MBean Description File) and filesdir is the location where the WebLogic MBeanMaker will place the intermediate files for the MBean type.
Whenever xmlfile is provided, a new set of output files is generated.
Each time you use the -DcreateStubs=true
flag, it overwrites any existing MBean implementation file.
Note:
As of version 9.0 of WebLogic Server, you can also provide a directory that contains multiple MDF's by using the -DMDFDIR <MDF directory name> option. In prior versions of WebLogic Server, the WebLogic MBeanMaker processed only one MDF at a time. Therefore, you had to repeat this process if you had multiple MDFs (in other words, multiple Auditing providers).Proceed to Use the WebLogic MBeanMaker to Create the MBean JAR File (MJF).
If the MDF for your custom Auditing provider does include custom operations, consider the following:
Are you creating an MBean type for the first time? If so, follow these steps:
Create a new DOS shell.
Type the following command:
java -DMDF=
xmlfile -Dfiles=
filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
where the -DMDF
flag indicates that the WebLogic MBeanMaker should translate the MDF into code, xmlFile is the MDF (the XML MBean Description File) and filesdir is the location where the WebLogic MBeanMaker will place the intermediate files for the MBean type.
Whenever xmlfile is provided, a new set of output files is generated.
Each time you use the -DcreateStubs=true
flag, it overwrites any existing MBean implementation file.
Note:
As of version 9.0 of WebLogic Server, you can also provide a directory that contains multiple MDF's by using the -DMDFDIR <MDF directory name> option. In prior versions of WebLogic Server, the WebLogic MBeanMaker processed only one MDF at a time. Therefore, you had to repeat this process if you had multiple MDFs (in other words, multiple Auditing providers).For any custom operations in your MDF, implement the methods using the method stubs.
Save the file.
Proceed to Use the WebLogic MBeanMaker to Create the MBean JAR File (MJF).
Are you updating an existing MBean type? If so, follow these steps:
Copy your existing MBean implementation file to a temporary directory so that your current method implementations are not overwritten by the WebLogic MBeanMaker.
Create a new DOS shell.
Type the following command:
java -DMDF=
xmlfile -Dfiles=
filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
where the -DMDF
flag indicates that the WebLogic MBeanMaker should translate the MDF into code, xmlFile is the MDF (the XML MBean Description File) and filesdir is the location where the WebLogic MBeanMaker will place the intermediate files for the MBean type.
Whenever xmlfile is provided, a new set of output files is generated.
Each time you use the -DcreateStubs=true
flag, it overwrites any existing MBean implementation file.
Note:
The WebLogic MBeanMaker processes one MDF at a time. Therefore, you may have to repeat this process if you have multiple MDFs (in other words, multiple Auditing providers).If you modified the MDF to include any custom operations that were not in the original MDF, implement the methods using the method stubs.
Save the version of the MBean implementation file that is complete (that is, has all methods implemented).
Copy this MBean implementation file into the directory where the WebLogic MBeanMaker placed the intermediate files for the MBean type. You specified this as filesdir in step 3. (You will be overriding the MBean implementation file generated by the WebLogic MBeanMaker as a result of step 3.)
Proceed to Use the WebLogic MBeanMaker to Create the MBean JAR File (MJF).
The MBean interface file is the client-side API to the MBean that your runtime class or your MBean implementation will use to obtain configuration data. It is typically used in the initialize method as described in Understand the Purpose of the "Provider" SSPIs.
Because the WebLogic MBeanMaker generates MBean types from the MDF you created, the generated MBean interface file will have the name of the MDF, plus the text "MBean" appended to it. For example, the result of running the SampleAuditor MDF through the WebLogic MBeanMaker will yield an MBean interface file called SampleAuditorMBean.java
.
Once your have run your MDF through the WebLogic MBeanMaker to generate your intermediate files, and you have edited the MBean implementation file to supply implementations for the appropriate methods within it, you need to package the MBean files and the runtime classes for the custom Auditing provider into an MBean JAR File (MJF). The WebLogic MBeanMaker also automates this process.
To create an MJF for your custom Auditing provider, follow these steps:
Create a new DOS shell.
Type the following command:
java -DMJF=jarfile -Dfiles=filesdir weblogic.management.commo.WebLogicMBeanMaker
where the -DMJF
flag indicates that the WebLogic MBeanMaker should build a JAR file containing the new MBean types, jarfile is the name for the MJF and <filesdir>
is the location where the WebLogic MBeanMaker looks for the files to JAR into the MJF.
Compilation occurs at this point, so errors are possible. If jarfile is provided, and no errors occur, an MJF is created with the specified name.
Note:
When you create a JAR file for a custom security provider, a set of XML binding classes and a schema are also generated. You can choose a namespace to associate with that schema. Doing so avoids the possibility that your custom classes will conflict with those provided by Oracle. The default for the namespace is vendor. You can change this default by passing the -targetNameSpace argument to the WebLogicMBeanMaker or the associated WLMBeanMaker ant task.If you want to update an existing MJF, simply delete the MJF and regenerate it. The WebLogic MBeanMaker also has a -DIncludeSource option, which controls whether source files are included into the resulting MJF. Source files include both the generated source and the MDF itself. The default is false. This option is ignored when -DMJF is not used.
The resulting MJF can be installed into your WebLogic Server environment, or distributed to your customers for installation into their WebLogic Server environments.
To install an MBean type into the WebLogic Server environment, copy the MJF into the WL_HOME\server\lib\mbeantypes
directory, where WL_HOME is the top-level installation directory for WebLogic Server. This "deploys" your custom Auditing provider; that is, it makes the custom Auditing provider manageable from the WebLogic Server Administration Console.
Note:
WL_HOME\server\lib\mbeantypes
is the default directory for installing MBean types. (Beginning with 9.0, security providers can be loaded from ...\domaindir\lib\mbeantypes
as well.) However, if you want WebLogic Server to look for MBean types in additional directories, use the -Dweblogic.alternateTypesDirectory=<dir>
command-line flag when starting your server, where <dir> is a comma-separated list of directory names. When you use this flag, WebLogic Server will always load MBean types from WL_HOME\server\lib\mbeantypes
first, then will look in the additional directories and load all valid archives present in those directories (regardless of their extension).
For example, if -Dweblogic.alternateTypesDirectory = dirX,dirY
, WebLogic Server will first load MBean types from WL_HOME\server\lib\mbeantypes
, then any valid archives present in dirX and dirY. If you instruct WebLogic Server to look in additional directories for MBean types and are using the Java Security Manager, you must also update the weblogic.policy file to grant appropriate permissions for the MBean type (and thus, the custom security provider). For more information, see "Using Java Security to Protect WebLogic Resources" in Programming Security for Oracle WebLogic Server.
You can create instances of the MBean type by configuring your custom Auditing provider (see Configure the Custom Auditing Provider Using the Administration Console), and then use those MBean instances from a GUI, from other Java code, or from APIs. For example, you can use the WebLogic Server Administration Console to get and set attributes and invoke operations, or you can develop other Java objects that instantiate MBeans and automatically respond to information that the MBeans supply. We recommend that you back up these MBean instances.
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:
Note:
The steps for configuring a custom Auditing provider using the WebLogic Server Administration Console are described under "Configuring WebLogic Security Providers" in Securing Oracle WebLogic Server.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
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:
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 10-1 lists the weblogic.security.spi
subinterfaces that extend the AuditEvent SSPI, and indicates which subinterfaces implement the AuditContext
interface.
Audit Event Name | Interface Class | Audit Event | Audit Context |
---|---|---|---|
Application Version Event |
|
Yes |
No |
Authentication Audit Event |
|
Yes |
No |
Authentication Audit Event V2 |
|
Yes |
Yes |
Authorization Audit Event |
|
Yes |
Yes |
CertPathBuilder Audit Event |
|
Yes |
Yes |
CertPathValidator Audit Event |
|
Yes |
Yes |
Configuration Audit Event |
|
Yes |
Yes |
Credential Mapping Audit Event |
|
Yes |
Yes |
Life Cycle Event |
|
Yes |
No |
Audit Management Event |
|
Yes |
No |
Policy Audit Event |
|
Yes |
No |
Policy Consumer Audit Event |
|
AuditPolicyEvent |
No |
Provider Audit Record |
|
Yes |
Yes |
Role Consumer Audit Event |
|
AuditRoleEvent |
Yes |
Role Deployment Audit Event |
|
Yes |
No |
Role Mapping Audit Event |
|
Yes |
Yes |
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)
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 10-2 describes the conditions under which the event is posted and severity level of the event.
Table 10-2 Application Version Events
Component | Description | Severity |
---|---|---|
Security Framework |
The security framework posts these events for the following reasons:
|
Success or Failure |
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 10-3 describes the conditions under which the event is posted and severity level of the event.
Table 10-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 |
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 10-4 describes the conditions under which the events are posted and severity level of the event.
Table 10-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 |
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 10-5 describes the conditions under which the events are posted and severity level of the event.
Table 10-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 |
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 10-6 describes the conditions under which the events are posted and severity level of the events.
Table 10-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:
|
Success or Failure |
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 10-7 describes the condition under which the events are posted and severity level of the event.
Table 10-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 |
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.
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
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 10-8 describes the conditions under which the events are posted and lists the event severity level.
Table 10-8 Audit Policy Events
Component | Description | Severity |
---|---|---|
WebLogic Authorization Provider |
|
Success or Failure |
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 10-9 describes the conditions under which the events are posted and lists the event severity level.
Table 10-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:
|
Success or Failure |
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 10-10 describes the conditions under which the events are posted and lists the event severity level.
Component | Description | Severity |
---|---|---|
WebLogic Authorization Provider |
The WebLogic Authorization provider implements this interface and posts audit events for the following security events:
|
Success |