Identity Manager can submit audit events to custom audit publishers.
The following custom publishers are provided:
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.
JMX. Publishes audit events so that a JMX (Java Management Extensions) client can monitor Identity Manager audit log activity.
Scripted. Allows for custom scripts to store audit events.
If you want to create your own publisher, see Developing Custom Audit Publishers.
The information in this section includes the following topics:
Custom audit publishers are enabled from the Audit Configuration page.
In the Administrator interface, click Configure in the main menu, then click Audit in the secondary menu.
The Audit Configuration page opens.
Select the Use custom publisher option at the bottom of the page.
A table opens listing the currently configured audit publishers.
To configure a new audit publisher, select the custom publisher type from the New Publisher drop-down menu.
Complete the Configure New Audit Publisher form. Click OK.
Important! Click Save to save the new audit publisher!
To enable the Console, File, JDBC, or Scripted audit publishers, follow the steps in To Enable Custom Audit Publishers. Select the appropriate publisher type from the New Publisher drop-down menu.
Complete the Configure New Audit Publisher form. If you have questions about the form, refer to the i-Helps and online Help.
The Console audit publisher prints audit events to either standard out or to standard error.
The File audit publisher writes audit events to a flat file.
The JDBC audit publisher records audit events in a JDBC datastore.
The Scripted audit publisher allows custom scripts written in JavaScript or BeanShell to store audit events.
The JMS audit log custom publisher makes it possible to publish audit event records to a JMS (Java Message Service) queue or topic.
Publishing to JMS provides additional flexibility for correlation in environments that have multiple Identity Manager servers. In addition, JMS can be used in situations where there are restrictions on using the File audit log publisher, for example in Windows environments where the log may not be accessible to a client reporting tool while the server is running.
JMS offers several benefits for environments with multiple servers:
The JMS message store centralizes (and simplifies) message storage and retrieval.
The JMS architecture does not place restrictions on how many clients can access the service.
The JMS protocol is easy to send through firewalls and other network infrastructure.
Java Message System provides two models for messaging: the point-to-point or queuing model, and the publish and subscribe or topic model. Identity Manager supports both models.
In the point-to-point model, a producer posts messages to a particular queue and a consumer reads messages from the queue. Here, the producer knows the destination of the message and posts the message directly to the consumer’s queue.
The point-to-point model has the following characteristics:
Only one consumer will get the message.
The producer does not have to be running at the time the receiver consumes the message, nor does the receiver need to be running at the time the message is sent.
Every message successfully processed is acknowledged by the receiver.
The publish and subscribe model, on the other hand, supports publishing messages to a particular message topic. Zero or more subscribers may register interest in receiving messages on a particular message topic. In this model, neither the publisher nor the subscriber know about each other. A good metaphor for this model is the anonymous bulletin board.
The publish and subscribe model has the following characteristics:
Multiple consumers can receive messages.
A timing dependency exists between publishers and subscribers. The publisher has to create a subscription before clients can subscribe. Once subscribed, subscribers have to remain continuously active to receive messages, unless a durable subscription has been established. In the case of a durable subscription, messages published while the subscriber is not connected will be redistributed when the subscriber reconnects.
For more information about JMS, see http://www.sun.com/software/products/message_queue/index.xml
The JMS publisher formats audit events into JMS TextMessages. These TextMessages are then sent to either a queue or a topic, depending on the configuration. Text messages can be formatted as XML or Universal Logging Format (ULF), depending on configuration.
To enable the JMS publisher type, follow the steps in To Enable Custom Audit Publishers and select JMS from the New Publisher drop-down menu.
To configure the JMS publisher type, complete the Configure New Audit Publisher form. If you have questions about the form, refer to the i-Helps and online Help.
The JMX audit log publisher publishes audit events so that a JMX (Java Management Extensions) client can monitor Identity Manager audit log activity.
Java Management Extensions (JMX) is a Java technology that allows for managing and/or monitoring applications, system objects, devices, and service oriented networks. The managed/monitored entity is represented by objects called MBeans (for Managed Bean).
Identity Manager’s JMX audit log publisher monitors the audit log for events. When an event is detected, the JMX publisher wraps the audit event record with an MBean, and also updates a temporary history (which is kept in memory). For each event, a separate small notification is sent to the JMX client. If the event is of interest, the JMX client can query the MBean wrapping the audit event for additional information.
See the com.waveset.object.AuditEvent Javadoc for information about audit event records. The Javadoc is available in the REF kit, which is discussed in Developing Custom Audit Publishers.
To retrieve information from the correct MBean, a history sequence number is required. This number is included in the event notification.
Each event notification includes the following information:
Type. A string describing the type of event. The string follows the format AuditEvent.<ObjectType>.<Action> where ObjectType and Action are returned from com.waveset.AuditEvent. For example, if an unlock event is sent, the type would be AuditEvent.LighthouseAccount.Unlock.
SequenceNumber. The history buffer key used to query information from the MBean.
To enable the JMX publisher type, follow the steps in To Enable Custom Audit Publishers and select JMX from the New Publisher drop-down menu.
To configure the JMX publisher type, complete the Configure New Audit Publisher form. If you have questions about the form, refer to the i-Helps and online Help.
Publisher Name. Type a unique name for the JMX audit event publisher.
History Limit. Change the default value as needed to specify the number of event items that the publish should retain in memory. (Default is 100.)
Click Test to verify that the Publisher Name is acceptable.
Click OK. The Configure New Audit Publisher form closes.
Important! Click Save.
Use a JMX client to view the JMX publisher. JConsole, which is included in the JDK 1.5, was used to create the following screen captures.
If using JConsole, choose attach to process to view the IDM:type=AuditLog MBean. For information on configuring JConsole for use as a JMX client, see Viewing JMX Data in Sun Identity Manager 8.1 System Administrator’s Guide.
In JConsole, click the Notifications tab to view audit events. Note the sequence number in the notification. A sequence number is required when querying the MBean for additional information.
In JConsole, click the Operations tab. Use the sequence number in the notification to query the MBean for event details. Each of the operations are prefixed with ’get’ and the only parameter is the ’sequence’ number.
The MBean is virtually a one-to-one mapping to the com.waveset.object.AuditEvent class. Table 10–19 provides a description for each attribute/operation that the MBean provides.
Table 10–19 MBeanInfo Attribute/Operation Descriptions
Attribute / Operation |
Description |
---|---|
AccountAttributesBlob |
The list of changed attributes |
AccountId |
AccountId associated with the event |
Action |
Action taken during the event |
AuditableAttributes |
The Auditable attributes |
ErrorString |
Any error string |
Interface |
The Audit interface |
MemberObjectGroupRefs |
The member object group references |
ObjectName |
The object name |
ObjectType |
The object type |
OverflowAttributes |
All the overflow attributes |
Parameters |
All the parameters |
Reason |
The reason for the event |
ResourceName |
Resource associated with the event |
RoleName |
Role associated with the event |
SubjectName |
User or service associated with the event |
Server |
Name of the server from which the event fired |
Status |
Status of the audit event |
Timestamp |
Date/Time of the audit event |
In JConsole, click the Attributes tab. Attributes are prefixed with Current to indicate that the attribute contains the most recent audit event sent to the system.