Auditing is a mechanism that records the most important interactions in the system in a computer-processable forms. The goal of the auditing is to record the interactions on "business" level, essentially recording who does what, who changed what, etc.

The audit record (audit trail) has to be machine-processable. It should be eventually possible to reconstruct a partial historical state of the system from the audit records by "going back in time".

Audit Record Structure





The exact moment in time that the audit record was generated

Event Identifier


Unique identification of an audit event. It is a Lightweight Identifier.

Event Type


Type of audit event. It describes what kind of operation was executed (adding an object, modification, user login, ...)

Event Stage


Stage of event processing: request of execution. See below.

Session Identifier


Identifier of the interactive session in which the event have taken place. For security reason this is different than the content of the session cookie.

Task Identifier


Unique identification of a task that this event is a part. It is a Lightweight Identifier.

Task OID


OID of a task that this event is part of (if the task is persistent). Since 4.3 the OID of the task tree root is used, if applicable.

Host Identifier


Identifier of a host that generated the audit record. This is the host name corresponding to a network interface that accepted the HTTP request.

Node IdentifiernidIdentifier of a node in a midPoint cluster that generated the audit record.
Remote Host AddressraddrNetwork address of a remote host that originated the request causing this event.



User that initiated ("caused") the event. It may the user that started the operation from a GUI or web service interface, the user that is owner of the task that recorded the event, etc.



Object that is a primary target of an operation (if applicable). In case that operation targets more than one object, the "primary" or the most important is recorded (e.g. the user object)

Target Owner


Owner of the object that is a target of this operation (if applicable). E.g. a owner of a task that is being stopped, owner of an account that is being modified, etc.



The changes that are being made to the targets. Deltas contain detailed information about the operation.



The channel that was the source of the operation that this record describes



Result of the operation: success, failure, partial failure, etc.

Event Types

Event type defines the kind of operation that was executed. Currently defined event types are defined in the table below.

Event Type

Event DB ID




Creating a new object (e.g adding a user, account, resource, ...)



Modification of an existing object



Removing an object

4Executing changes directly in the repository, e.g. changes made via debug pages.



Synchronizing a change notification. This type should only be present in REQUEST stage, the EXECUTION stage of the event will provide a more specific event type.



Creating a new session, e.g. user login.



End of a session, e.g. user logout.

WORK_ITEM8Creation or completion of a work item (e.g. a request to approve particular assignment). See Workflow Auditing.
WORKFLOW_PROCESS_INSTANCE9Creation or completion of a workflow process instance (may include 0, 1 or many work items). See Workflow Auditing.
10Initiation or completion of reconciliation

Other event types may be added in the future (including custom event types).

Event Stages

Operations in midPoint may be subject to quite complex processing before they get executed. This may include processing RBAC, expressions, workflows or other "plugin" hooks. Therefore the details of the operation may considerably differ at the beginning of the operation and at the end. Event stages are defined to denote this difference and to record events at various stages through the operation lifecycle.

Event Stage

Stage DB ID




The operation is requested. The record shows operation details (e.g. deltas) in the form as originally intended by the user or client.



The operation after execution. The record shows operation details (e.g. deltas) in the form as it was executed.

Other stages may be added in the future (e.g. stage for approvals or workflow steps).

There is usually one request and one execution record for each operation. E.g. the request record contains the delta that assigns role to a user. The execution record will also contain that delta but it may additional deltas, e.g. deltas for adding new accounts implied by the role. In some cases there may be several execution records for a single request record. This happens if the execution happens in several waves. E.g. a role is assigned to a user. Some of the accounts implied by the role may be created immediately and others needs to wait for an approval. Therefore the accounts that can be created immediately will be audited in a first execution audit record. The second batch of accounts will be audited when they are later approved and created. This goes to the second audit record. This situation may also happen even if there are no approvals, e.g. in case of resource dependencies or even complex inbound-outbound-template interactions.

Event Outcomes

The result of the executed operation. All the possible values are described in the following table.

Event OutcomeOutcome DB IDDecritption

Used when operation and sub operations finish successfully. The operation is completed and the result is final.


Used when operation finish successfully, but minor problem occurred. For example operation code recovered
from some error and after that operation finished successfully. The operation is completed and the result is final.


Used when operation contains at least one operation witch status SUCCESS/WARNING and at least one
operation with status FATAL_ERROR.  The operation is completed and the result is final.


Used when operation didn't finish correctly. The operation is completed and the result is final.


Result does not make any sense for the operation. This is useful in cases that the operation is not supported
(e.g. an optional part of the interface). This is different than UNKNOWN, as in this case we really know that it
result is not applicable. In UNKNOWN case we know nothing. The operation is completed and the result is final.


The operation is being executed. This is set for operations that are executed asynchronously or take a significant
amount of time. Short synchronous operations do not need to set this status, they may go well with the default
UNKNOWN status. The operation is in progress and the final result is not yet known.


No information about operation is present. Presence of this status usually means programming bug, e.g. someone
forgot to set or compute appropriate operation result.


The operation didn't finish correctly but that was expected and handled. It is equivalent to success for all practical
cases except for displaying the result. But using success status for this situation might be misleading. The operation
is completed and the result is final.

Initiator and Attorney

MidPoint 3.7 introduced a concept of attorney. Therefore there is possibility that one user acts on behalf of another user. Both users are recorded in the audit logs. The meaning is as follows:

Audit Trails

The auditing subsystem in midPoint is designed to be pluggable. There are currently two auditing implementations: auditing to log files and to database table.

Logfile Auditing

Audit logs are recorded in a form of human-readable text records in the usual log files. This auditing goes to the default log file (idm.log) and is turned off by default. It is using a dedicated logger name:


This logger can be directed to a specific appender to a separate audit log file using the normal logging configuration mechanism.

Database Table Auditing

When using database table auditing, audit logs are stored in five tables whose structure is described in code block below (part of DB script for H2 database). You can find table structures for different DB vendors in out git, or in distribution packages in folder config/sql/midpoint/<version>.

CREATE TABLE m_audit_delta (
  checksum          VARCHAR(32) NOT NULL,
  record_id         BIGINT      NOT NULL,
  delta             BLOB,
  deltaOid          VARCHAR(36),
  deltaType         INTEGER,
  fullResult        BLOB,
  objectName_norm   VARCHAR(255),
  objectName_orig   VARCHAR(255),
  resourceName_norm VARCHAR(255),
  resourceName_orig VARCHAR(255),
  resourceOid       VARCHAR(36),
  status            INTEGER,
  PRIMARY KEY (record_id, checksum)
CREATE TABLE m_audit_event (
  attorneyName      VARCHAR(255),
  attorneyOid       VARCHAR(36),
  channel           VARCHAR(255),
  eventIdentifier   VARCHAR(255),
  eventStage        INTEGER,
  eventType         INTEGER,
  hostIdentifier    VARCHAR(255),
  initiatorName     VARCHAR(255),
  initiatorOid      VARCHAR(36),
  initiatorType     INTEGER,
  message           VARCHAR(1024),
  nodeIdentifier    VARCHAR(255),
  outcome           INTEGER,
  parameter         VARCHAR(255),
  remoteHostAddress VARCHAR(255),
  result            VARCHAR(255),
  sessionIdentifier VARCHAR(255),
  targetName        VARCHAR(255),
  targetOid         VARCHAR(36),
  targetOwnerName   VARCHAR(255),
  targetOwnerOid    VARCHAR(36),
  targetOwnerType   INTEGER,
  targetType        INTEGER,
  taskIdentifier    VARCHAR(255),
  taskOID           VARCHAR(255),
  timestampValue    TIMESTAMP,
CREATE TABLE m_audit_item (
  changedItemPath VARCHAR(255) NOT NULL,
  record_id       BIGINT       NOT NULL,
  PRIMARY KEY (record_id, changedItemPath)
CREATE TABLE m_audit_prop_value (
  name      VARCHAR(255),
  record_id BIGINT,
  value     VARCHAR(1024),
CREATE TABLE m_audit_ref_value (
  name            VARCHAR(255),
  oid             VARCHAR(36),
  record_id       BIGINT,
  targetName_norm VARCHAR(255),
  targetName_orig VARCHAR(255),
  type            VARCHAR(255),


Auditing implementation in midPoint was inspired by XDAS and it is conceptually compatible with XDAS. The actual XDAS support in midPoint is planned for the future.

XDAS is a specification of distributed auditing system developed by Open Group.

The XDAS specification asks for a common audit log format and a common taxonomy of audit log events.

The XDAS system is composed from several components. The components can be placed inside a single system or distributed across an organization.

Good introduction to XDAS architecture is provided by the OpenXDAS Project

Determining Remote Host Address

Normally, the remote host address is determined from the HTTP connection; as returned by the HttpServletRequest.getRemoteAddr() method. However, there are situations where a trustworthy proxy server is used, so the "real" client host address can be obtained from an HTTP header created by it. MidPoint can be set up to use such a header (if present) using the following configuration:


If there's no such header, network-level client address is used.

If the header contains more values (separated by commas), the first i.e. leftmost one is used.

Resource oid column

This feature is experimental. It means that it is not intended for production use. The feature is not finished. It is not stable. The implementation may contain bugs, the configuration may change at any moment without any warning and it may not work at all. Use at your own risk. This feature is not covered by midPoint support. In case that you are interested in supporting development of this feature, please consider purchasing midPoint Platform subscription.

If we need work with resource oid in reporting, we can allow store resource oid for audit record to database. For it we need add next snippet of code to system configuration xml.


Table in database is already created by next sql command.

CREATE TABLE m_audit_resource (
  resourceOid       VARCHAR(255) NOT NULL,
  record_id       BIGINT       NOT NULL,
  PRIMARY KEY (record_id, resourceOid)

Custom column

This feature is experimental. It means that it is not intended for production use. The feature is not finished. It is not stable. The implementation may contain bugs, the configuration may change at any moment without any warning and it may not work at all. Use at your own risk. This feature is not covered by midPoint support. In case that you are interested in supporting development of this feature, please consider purchasing midPoint Platform subscription.

When we need some other information in audit table, then we can adding custom column to table in database. We can use new column for tag some special audit records for reporting. 

Custom column have three parts of configuration: 

  1. Creating column of m_audit_event table in database by sql command.
  2. Adding of configuration for every custom column to config.xml file in Midpoint home directory.
  3. Adding of configuration of details how an audit event record property is created to system configuration file.

ALTER TABLE m_audit_event ADD custFoo VARCHAR(255);

CREATE INDEX iAuditEventCustFoo
	ON m_audit_event (custFoo);

When we want search by our column, we add index for it. Please for name of our new column use 'custXXX' where XXX represents your name. It is important in order to we obviate conflict with already exist columns. 


After adding of this configuration is needed restart of midpoint.


We can use script in expression for obtaining some special information. In script we can use variable 'target' , which represent target object of audit record and 'auditRecord' type AuditEventRecord, which represent audit record itself.

Next example about custom column you can see on

Auditing of create/termination session event for channels rest and actuator

From version 4.1 Midpoint support flexible authentication, so we can configure different authentication for different channels. You can find configuration on Flexible Authentication Configuration.

From version 4.2 channels for rest and actuator default don't create audit records about session creation or termination. You can turn on it via variable in System Configuration audit->eventRecording->recordSessionlessAccess.

Separate repository configuration for audit

By default audit uses the same data source like the main repository. From version 4.2 it is possible to setup separate repository. For more and examples see: Audit configuration#Audittoseparaterepository