Previous      Contents      Index      Next
Sun Java[TM] System Identity Manager 7.1 Admininstration

Chapter 12
Audit Logging

This chapter describes how the Sun Java™ System Identity Manager auditing system records events. The information is organized as follows:

Overview
What Does Identity Manager Audit?
Creating Events
Audit Configuration
Database Schema
Log Database Keys
Preventing Audit Log Tampering
Using Custom Publishers

---

Overview

The purpose of Identity Manager auditing is to record who did what, when, and to which Identity Manager objects.

Audit events are handled by one or more publishers. By default, Identity Manager records audit events in the repository using the repository publisher. Filtering, with the help of audit groups, allows the administrator to select a subset of audit events for recording. Each publisher can be assigned one or more audit groups that are enabled initially.

Note	For information about monitoring and managing user violations, see Chapter 11, "Identity Auditing.".

---

What Does Identity Manager Audit?

Most default auditing is carried out by internal Identity Manager components. However, there are interfaces that allow events to be generated from workflow or from Java code.

The default Identity Manager audit instrumentation focuses on four main areas:

Provisioner – An internal component known as the provisioner may generate audit events.
View Handlers – In the view architecture, the view handler needs to generate audit records. A view handler should always audit when objects are created or modified.
Session – The session methods (such as checkinObject, createObject, runTask, login, and logout) create an audit record after completing an auditable operation. Most of the instrumentation is pushed into the view handlers.
Workflow – By default, only the approval workflows are instrumented to generate audit records. These generate an audit event when requests are approved or rejected. The workflow feature’s interface to the audit logger is through the com.waveset.session.WorkflowServices application.

---

Creating Events

Although Identity Manager handles internal auditing, in some cases you may want to log audit events from custom workflows.

Auditing from Workflow

Use the com.waveset.session.WorkflowServices application to generate audit events from any workflow process. Table 12-1 describes the arguments that are available for this application.

Table 12-1  Arguments for com.waveset.session.WorkflowServices

Argument	Type	Description
op	String	Operation for WorkflowServices. Must be set to audit.
type	String	Name of the object type that is being audited.
action	String	Name of the action that was performed.
status	String	Name of the status for the specified action.
name	String	Name of the object being affected by the specified action.
resource	String	(Optional) Name of the resource where the object being changed resides.
accountId	String	(Optional) Account ID that is being modified. This should be a native resource account name.
error	String	(Optional) Localized error string to accompany any failures.
reason	String	(Optional) Name of the ReasonDenied object, which maps to an internationalized message describing the causes of common failures.
attributes	Map	(Optional) Map of attribute names and values that were added or modified.
parameters	Map	(Optional) Maps up to five additional names or values that are relevant to an event.
organizations	List	List of organization names or IDs where this event will be placed. This is used for organizational scoping of the audit log. If not present, the handler will attempt to resolve the organization based on the type and name. If the organization cannot be resolved, the event is placed in Top (the highest level of the organizations hierarchy).
originalAttributes	Map	(Optional) Map of old attribute values. The names should match the ones listed in the attributes argument. The values will be any previous value you wish to save in your audit log.

Refer to Table 12-18 for a list of default object, action, and status names.

Examples

Code Example 12-1 illustrates a simple workflow activity. It shows the generation of an event that will log a resource deletion activity named ADSIResource1, performed by ResourceAdministrator:

Code Example 12-1  Simple Workflow Activity

<Activity name='createEvent'>    <Action class='com.waveset.session.WorkflowServices'>    <Argument name='op' value='audit'/>    <Argument name='type' value='Resource'/>    <Argument name='action' value='Delete'/>    <Argument name='status' value='Success'/>    <Argument name='subject' value='ResourceAdministrator'/>    <Argument name='name' value='ADSIResource1'/>    </Action>    <Transition to='end'/> </Activity>

Code Example 12-2 shows how you can add specific attributes to a workflow that tracks the changes applied by each user in an approval process to a granular level. This addition typically will follow a ManualAction that solicits input from a user.

ACTUAL_APPROVER is set in the form and in the workflow (if approving from the approvals table) based on the person who actually performed the approval. APPROVER identifies the person to whom it was assigned.

Code Example 12-2  Attributes Added to Track Changes in an Approval Process

<Action name='Audit the Approval'    application='com.waveset.session.WorkflowServices'>      <Argument name='op' value='audit'/>      <Argument name='type' value='User'/>      <Argument name='name' value='$(CUSTOM_DESCRIPTION)'/>      <Argument name='action' value='approve'/>      <Argument name='accountId' value='$(accountId)'/>      <Argument name='status' value='success'/>      <Argument name='resource' value='$(RESOURCE_IF_APPLICABLE)'/>      <Argument name='loginApplication' value='$(loginApplication)'/>      <Argument name='attributes'>        <map>           <s>fullname</s><ref>user.accounts[Lighthouse].fullname</ref>           <s>jobTitle</s><ref>user.accounts[Lighthouse].jobTitle</ref>           <s>location</s><ref>user.accounts[Lighthouse].location</ref>           <s>team</s><ref>user.waveset.organization</ref>           <s>agency</s><ref>user.accounts[Lighthouse].agency</ref>       </map>     </Argument>     <Argument name='originalAttributes'>       <map> <s>fullname</s>         <s>User's previous fullname</s>         <s>jobTitle</s>         <s>User's previous job title</s>         <s>location</s>         <s>User's previous location</s>         <s>team</s>         <s>User's previous team</s>         <s>agency</s>         <s>User's previous agency</s>      </map>     </Argument>     <Argument name='attributes'>       <map>          <s>firstname</s>          <s>Joe</s>          <s>lastname</s>          <s>New</s>       </map>     </Argument>     <Argument name='subject'>        <or>           <ref>ACTUAL_APPROVER</ref>           <ref>APPROVER</ref>       </or>     </Argument>     <Argument name='approver' value='$(APPROVER)'/> </Action>

---

Audit Configuration

The audit configuration is composed of one or more publishers and several pre-defined groups.

An audit group defines a subset of all audit events based on the object types, actions and action results. Each publisher is assigned one or more audit groups. By default, the repository publisher is assigned to all audit groups.

An audit publisher delivers audit events to a particular audit destination. The default repository publisher writes audit records into the repository. Each audit publisher may have implementation specific options. Audit publishers may have a text formatter assigned: text formatters provide textual representation of audit events.

The Audit Configuration (#ID#Configuration:AuditConfiguration) object is defined in the sample/auditconfig.xml file. This configuration object has an extension that is a generic object. At the top level, it has the following attributes:

filterConfiguration
extendedTypes
extendedActions
extendedResults
publishers

filterConfiguration

The filterConfiguration attribute lists event groups, which are used to enable one or more events to pass through the event filter. Each group listed in the filterConfiguration attribute contains the attributes listed in Table 12-2.

Table 12-2  filterConfiguration Attributes

Attribute	Type	Description
groupName	String	Event group name
displayName	String	Message catalog key representing the group name
enabled	String	Boolean flag indicating whether the entire group is enabled or disabled. This attribute is an optimization for the filtering object.
enabledEvents	List	List of generic objects that describe which events a group enables. An event must be listed to enable its logging. Each object listed must have these attributes: objectType (String) – Name the objectType. actions (List) – List of one or more actions. results (List) – List of one or more results.

Code Example 12-3 illustrates the default Resource Management group.

Code Example 12-3  Default Resource Management Group

<Object name='Resource Management'>   <Attribute name='enabled' value='true'/>   <Attribute name='displayName'              value='UI_RESOURCE_MGMT_GROUP_DISPLAYNAME'/>   <Attribute name='enabledEvents'>     <List>       <Object>         <Attribute name='objectType' value='Resource'/>         <Attribute name='actions' value='ALL'/>         <Attribute name='results' value='ALL'/>       </Object>       <Object>         <Attribute name='objectType' value='ResourceObject'/>         <Attribute name='actions' value='ALL'/>         <Attribute name='results' value='ALL'/>       </Object>     </List>   </Attribute> </Object>

Identity Manager provides the following default event groups:

Account Management
Compliance Management
Configuration Management
Identity Manager Login/Logoff
Password Management
Resource Management
Role Management
Security Management
Task Management
Changes Outside Identity Manager
Service Provider Edition

You can configure each group from the Audit Events page of the Identity Manager administrative interface (configure/auditeventconfig.jsp). The page allows you to configure successful or failed events for each group. The interface does not support adding or modifying enabledEvents for groups, but you can do this by using the Identity Manager debug pages.

The default event groups and the events they enable are described in the following sections.

Account Management

This group is enabled by default.

Table 12-3  Default Account Management Event Groups

Type	Actions
Resource Account	Create, Update, Delete, Enable, Disable, Reject, Approve, Rename
Identity Manager Account	Create, Update, Delete, Enable, Disable, Rename

Compliance Management

This group is enabled by default.

Table 12-4  Default Compliance Management Group Events

Type	Actions
AuditPolicy	All Actions
ComplianceViolation	All Actions
Remediation Workflow	All Actions

Configuration Management

This group is enabled by default.

Table 12-5  Default Configuration Management Event Groups

Type	Actions
Configuration	All Actions
UserForm	All Actions
Rule	All Actions
EmailTemplate	All Actions
LoginConfig	All Actions
Policy	All Actions
XMLData	Import
Log	All Actions

Identity Manager Login/Logoff

This group is enabled by default.

Table 12-6  Default Identity Manager Login/Logoff Event Groups

Type	Actions
User	Login, Logoff, Credentials Expired
Administrator	Login, Logoff, Credentials Expired

Password Management

This group is enabled by default.

Table 12-7  Default Password Management Event Groups and Events

Type	Actions
Resource Account	Change/Reset Password

Resource Management

This group is enabled by default.

Table 12-8  Default Resource Management Event Groups and Events

Type	Actions
Resource	All Actions
Resource Object	All Actions
ResourceForm	All Actions
ResourceAction	All Actions
AttrParse	All Actions

Role Management

This group is disabled by default.

Table 12-9  Default Role Management Event Groups and Events

Type	Actions
Role	All Actions

Security Management

This group is enabled by default.

Table 12-10  Default Security Management Event Groups and Events

Type	Actions
ObjectGroup	All Actions
AdminGroup	All Actions
Administrator	All Actions
EncryptionKey	All Actions

Task Management

This group is disabled by default.

Table 12-11  Task Management Event Groups and Events

Type	Actions
TaskInstance	All Actions
TaskDefinition	All Actions
TaskSchedule	All Actions
TaskResult	All Actions
ProvisioningTask	All Actions

Changes Outside Identity Manager

This group is disabled by default.

Table 12-12  Changes Outside Identity Manager Event Groups and Events

Type	Actions
ResourceAccount	NativeChange

Service Provider Edition

This group is enabled by default.

Table 12-13  Service Provider Edition Event Groups and Events

Type	Actions
IDMXUser	Create, Modify, Delete, Username Recovery, Challenge Response, Update Authentication Answers, Pre-Operation and Post-Operation Callouts,

extendedTypes

Each new Type that you add to the com.waveset.object.Type class can be audited. A new Type must be assigned a unique two-character database key, which is stored in the database. All new Types are added to the various audit reporting interfaces. Each new Type to be logged to the database without being filtered must be added to an audit event groups enabledEvents attribute (as described with the enabledEvents attribute).

There may be situations in which you want to audit something that does not have an associated com.waveset.objectType, or where you want to represent an existing type more granularly.

For example, the WSUser object stores all of the user's account information in the repository. Instead of marking each event as a USER type, the auditing process splits the WSUser object into two different audit types (Resource Account and Identity Manager Account). Splitting the object in this way makes it easier to find specific account information in the audit log.

Add extended audit types by adding to the extendedObjects attribute. Each extended object must have the attributes listed in the following table:

Table 12-14  Extended Object Attributes

Argument	Type	Description
name	String	The name of the type, which is used when constructing AuditEvents and during event filtering.
displayName	String	A message catalog key that represents the name of the type.
logDbKey	String	Two-character database key to use when storing this object in the Log table. See Log Database Keys for reserved values.
supportedActions	List	Actions supported by the object type. This attribute will be used when creating audit queries from the user interface. If this value is null, all actions will be displayed as possible values to be queried for this object type.
mapsToType	String	(Optional) The name of the com.waveset.object.Type that maps to this type, if applicable. This attribute is used when attempting to resolve an object organizational membership if not already specified on the event.
organizationalMembership	List	(Optional) A default list of organization IDs where events of this type should be placed, if they do not already have assigned organizational membership.

All customer-specific keys should start with the # symbol to prevent duplicate keys when new internal keys are added.

Code Example 12-4 illustrates the extended-type Identity Manager Account.

Code Example 12-4  Extended Type Identity Manager Account

<Object name='LighthouseAccount'>    <Attribute name='displayName' value='LG_LIGHTHOUSE_ACCOUNT'/>    <Attribute name='logDbKey' value='LA'/>    <Attribute name='mapsToType' value='User'/>    <Attribute name='supportedActions'>       <List>          <String>Disable</String>          <String>Enable</String>           <String>Create</String>          <String>Modify</String>          <String>Delete</String>          <String>Rename</String>       </List>    </Attribute> </Object>

extendedActions

Audit actions typically map to com.waveset.security.Right objects. When adding new Right objects, you must specify a unique two-character logDbKey, which will be stored in the database. You may encounter situations where there is no right to correspond to a particular action that must be audited. You can extend actions by adding them to the list of objects in the extendedActions attribute.

Each extendedActions object must include the attributes listed in Table 12-15.

Table 12-15  extendedAction Attributes

Attribute	Type	Description
name	String	The name of the action, which is used when constructing AuditEvents and during event filtering.
displayName	String	A message catalog key that represents the name of the action.
logDbKey	String	Two-character database key to use when storing this action in the Log table. See Log Database Keys for reserved values.

All customer-specific keys should start with the # symbol to prevent duplicate keys when new internal keys are added.

Code Example 12-5 illustrates adding an action for Logout.

Code Example 12-5  Adding an Action for Logout

<Object name='Logout'>   <Attribute name='displayName' value='LG_LOGOUT'/>   <Attribute name='logDbKey' value='LO'/> </Object>

extendedResults

In addition to extending audit types and actions, you can add results. By default, there are two results: Success and Failure. You can extend results by adding them to the list of objects in the extendedResults attribute.

Each extendedResults object must include the attributes described in Table 12-16.

Table 12-16  extendedResults Attributes

Attribute	Type	Description
name	String	The name of the result, which is used when setting the status on AuditEvents and during event filtering.
displayName	String	A message catalog key that represents the name of a result.
logDbKey	String	One-character database key to use when storing this result in the Log table. See the section titled Database Keys for reserved values.

All customer-specific keys should use the range 0–9 to prevent duplicate keys when new internal keys are added.

publishers

Each item in the publishers list is a generic object. Each publisher has the following attributes:

Table 12-17  publishers Attributes

Attribute	Type	Description
class	String	The name of the publisher class.
displayName	String	A message catalog key that represents the name of the publisher.
description	String	A description of the publisher.
filters	List	A list of audit groups assigned to this publisher.
formatter	String	The name of the text formatter (if any).
options	List	A list of publisher options. These options are publisher specific; each item in the list is a map representation of PublisherOption. See sample/auditconfig.xml for examples.

---

Database Schema

There are two tables in the Identity Manager database that are used to store audit data:

waveset.log – Stores most of the event details.
waveset.logattr – Stores the IDs of the organizations to which each event belongs.

waveset.log

This section lists the various column names and data types found in the waveset.log table. The data types are taken from the Oracle database definition and will vary slightly from database to database. For a list of data schema values for all supported databases, see Appendix C, "Audit Log Database Schema."

A few of the column values are stored as keys in the database for space optimization. For key definitions, see the section titled Log Database Keys.

objectType CHAR(2) – A two-character key that represents the object type that is being audited.
action CHAR(2) – A two-character key that represents the action that was performed.
actionStatus CHAR(1) – A one-character key that represents the result of the action that was performed.
reason CHAR(2) – A two-character database key to describe a ReasonDenied object if there was a failure. ReasonDenied is a class that wraps a message catalog entry and is used for common failures such as invalid credentials and insufficient privileges.
actionDateTime VARCHAR(21) – The date and time in which the above action took place. This value is stored in GMT time.
objectName VARCHAR(128) – The name of the object that was acted on during an operation.
resourceName VARCHAR(128) – The resource name that was used during an operation, if applicable. Some events do not reference resources; however, in many situations it gives greater detail to log the resource where an operation has performed.
accountName VARCHAR(255) – The account ID being acted on, if applicable.
server VARCHAR(128) – The server where the action was performed (automatically assigned by the event logger).
message VARCHAR(255) – Any localized messages associated with an action including things like error messages. The text is stored localized so it will not be internationalized.
interface VARCHAR(50) – The Identity Manager interface (such as the Administrator, User, IVR, or SOAP interface) from which the operation was performed.
acctAttrChanges VARCHAR(4000) – Stores the account attributes that have changed during a create and update. The attributes changes field is always populated during a create or update for a resource account or Identity Manager account object. All of the attributes changed during an action are stored in this field as a string. The data is in NAME=VALUE NAME2=VALUE2 format. This field can be queried by executing “contains” SQL statements against the name or value.

Code Example 12-6 illustrates a value in the acctAttrChanges column:

Code Example 12-6  Value in acctAttrChanges Column

COMPANY="COMPANY" DEPARTMENT="DEPT" DESCRIPTION="DSMITH DESCRIPTION" FAX NUMBER="5122222222" HOME ADDRESS="12282 MOCKINGBIRD LANE" HOME CITY="AUSTIN" HOME PHONE="5122495555" HOME STATE="TX" HOME ZIP="78729" JOB TITLE="DEVELOPER" MOBILE PHONE="5125551212" WORK PHONE="5126855555" EMAIL="someone@somecompany.COM" EXPIREPASSWORD="TRUE" FIRSTNAME="DANIEL" FULLNAME="DANIEL SMITH" LASTNAME="SMITH"

acctAttr01label-acctAttr05label VARCHAR(50) – These five additional NAME slots are columns that can promote up to five attributes to be stored in their own column instead of in the big blob. You can promote an attribute from the Resource Schema Configuration page using the "audit?" setting, and the attribute will be available for data mining.
acctAttr01value-acctAttr05value VARCHAR(128) – Five additional VALUE slots that can promote up to five attributes to be stored in a separate column instead of in the blob column.
parm01label-parm05label VARCHAR(50) – Five slots used to store parameters associated with an event. Examples of these are Client IP and Session ID.
parm01value-parm05value VARCHAR(128) – Five slots used to store parameters associated with an event. Examples of these are Client IP and Session ID.
id VARCHAR(50) – Unique ID assigned to each record by the repository referenced in the waveset.logattr table.
name VARCHAR(128) – Generated name assigned to each record.

waveset.logattr

The waveset.logattr table is used to store IDs of the organizational membership for each event, which is used to scope the audit log by organization.

id VARCHAR(50) – ID of the waveset.log record.
attrname VARCHAR(50) – Currently, always MEMBEROBJECTGROUPS.
attrval VARCHAR(255) – ID of the MemberObject group where the event belongs.

---

Log Database Keys

The objectType, action, actionStatus, and reason columns are stored in the database as keys to conserve space.

ObjectTypes, Actions, and Results

Table 12-18 describes the objectTypes, actions, and results that are stored in the database as keys:

Table 12-18  objectTypes, Actions, and Results Stored as Keys

objectType Name	DbKey	Action Name	DbKey	Results Name	DbKey
Account	AN	Approve	AP	Success	S
Administrator	AD	Bypass Verify	BV	Failure	F
AdminGroup	AG	Cancel Reconcile	CR
Attribute Definition	AF	challengeResponse	CD
Application	AP	Change Password	CP
Capability	US	Create	CT
Configuration	CN	Connect	CO
Discovery	DS	Delete	DL
EmailTemplate	ET	Deprovision	DP
Extract	ER	Disable	DS
ExtractTask	EX	Disconnect	DC
Identity Manager Account	LA	Enable	EN
IDMXUser	UX	Execute	LN
LoadConfig	LD	Export	EP
LoadTask	LT	Import	IM
LoginConfig	LC	List	LI
Policy	PO	Load	LD
Provisioning Task	PT	Login	LG
Resource	RS	Update	MO
Resource Account	RA	Logout	LO
Resource Form	RF	Native Changes	NC
Resource Object	RE	Post Operation	PT
RiskReportTask	RR	Pre Operation	PE
Role	RL	Provision	PV
Rule	RU	Reset Password	RP
User	US	Reprovision	RV
TaskDefinition	TD	Reject	RJ
TaskInstance	TI	Terminate	TR
TaskSchedule	TS	usernameRecovery	UR
TaskTemplate	TT
TaskResult	TR
UserForm	UF
WorkItem	WI
XMLDATA	XD

Reasons

Table 12-19 describes the reasons that are stored in the database as keys:

Table 12-19  Reasons Stored as Keys

Reason Name	English Text	DbKey
PolicyViolation	Violation of policy {0}: {1}	PV
InvalidCredentials	Invalid credentials	CR
InsufficientPrivileges	Insufficient privileges	IP
DatabaseAccessFailed	Database access failed	DA
AccountDisabled	Account disabled	DI

---

Preventing Audit Log Tampering

You can configure Identity Manager to prevent the following forms of audit log tampering:

Adding or inserting audit log records
Modifying existing audit logs records
Deleting audit log records or the entire audit log
Truncating audit logs

All Identity Manager audit log records have unique, per-server sequence numbers and encrypted hash of records and sequence numbers. When you create a Tamper Detection Report, it scans the audit logs per server for:

Gaps in the sequence number (indicating a deleted record)
Hash mismatches (indicating a modified record)
Duplicate sequence numbers (indicating a copied record)
Last sequence number that is less than expected (indicating a truncated log)

Configuring tamper-resistant logging

To configure tamper-resistant logging, use the following steps:

Create a tampering report by selecting Reports > New > Audit Log Tampering Report.
When the Define a Tampering Report page displays (see Figure 12-1), enter a title for the report and then Save it.

Figure 12-1  Configuring an Audit Log Tampering Report



You can also specify the following optional parameters:

Report Summary – Enter a descriptive summary of the report.
Starting sequence for server '<server_name>' – Enter the starting sequence number for the server.
This option enables you to delete old log entries without having them flagged as tampering and limits the report’s scope for performance reasons.
Email Report – Enable to email report results to a specified email address.
When you select this option, the page refreshes and prompts you for email addresses. However, keep in mind that email is not safe for text content — sensitive information (such as account IDs or account history) may be exposed.
Override default PDF options – Select to override the default PDF options for this report.
Organizations – Select organizations that should have access to this report.
Next, select Configure > Audit to open the Audit Configuration page (shown in Figure 12-2).

Figure 12-2  Tamper-Resistant Audit Logging Configuration



Select Use Custom Publisher, and then click on the Repository publisher link.
Select Enable tamper-resistant audit logs, and then click OK.
Click Save to save the settings.

You can turn this option off again, but unsigned entries will be flagged as such in the Audit Log Tampering Report, and you must reconfigure the report to ignore these entries.

---

Using Custom Publishers

Identity Manager can submit audit events to custom audit publishers. The following custom publishers are available:

Console — Prints audit events to the standard output or standard error.
File — Writes audit events to a flat file.
JDBC — Records audit events in a JDBC datastore.
JMS — Records audit events in a JMS queue or topic.
Scripted — Allows for custom scripts to store audit events.

The source code of these publishers can be found in the reference kit. The documentation of the interfaces is also available in the reference kit, in Javadoc format.

Developing Publishers

All publishers implement the AuditLogPublisher interface. (Refer to the Javadoc for interface details). Developers are encouraged to extend the AbstractAuditLogPublisher class. This class parses the configuration and ensures that all required options have been provided to the publisher. (See the example publishers in the reference kit).

Publishers must have a no-arg constructor.

Lifecycle

The following steps describe the lifecycle of a publisher:

The Object is instantiated.
The Formatter (if any) is set using the setFormatter() method.
Options are provided using the configure(Map) method.
Events are published using the publish(Map, LoggingErrorHandler) method.
Publisher is terminated using the shutdown() method.

Steps 1-3 are executed when Identity Manager starts up and whenever the audit configuration is updated. Step 4 will not occur if no audit event is generated before shutdown is called.

The configure(Map) is only called once on the same publisher object. (A publisher does not have to prepare for on-the-fly configuration changes). After the audit configuration is updated, the current publishers are first shut down and new publishers are created.

The configure() method in Step 3 may throw a WavesetException. In this case, the publisher will be ignored and no other calls will be made to the publisher.

Configuration

Publishers can have zero or more options. The getConfigurationOptions() method returns the list of options the publisher supports. The options are encapsulated using the PublisherOption class (see Javadoc for details of this class). The audit configuration viewer invokes this method when it builds the configuration interface for the publisher.

Identity Manager configures the publisher using the configure(Map) method at server startup and after audit configuration changes.

Developing Formatters

The reference kit includes the source code of the following formatters:

XmlFormatter — Formats audit events as
XML strings
UlfFormatter — Formats audit events according to the Universal Logging Format (ULF). The Sun Java System Application Server uses this format.

Formatters must implement the AuditRecordFormatter interface. In addition, formatters must have a no-arg constructor. Refer to the Javadoc included in the ref kit for details.

Registering Publishers/Formatters

The audit attribute of #ID#Configuration:SystemConfiguration object lists all the registered publishers and formatters. Only these publishers and formatters are available in the audit configuration user interface.

Previous      Contents      Index      Next

---

Part No: 820-0816-10.   Copyright 2007 Sun Microsystems, Inc. All rights reserved.