Understanding the Audit Message Logical Schema

This chapter describes the logical audit message layout as presented at the user interface level. There is also a section that describes the mapping of the message logical schema to the database schema, which consists of several tables.

The database schema is proprietary but is modeled on the RFC 3881 standard (Security Audit and Access Accountability Message XML) with some extensions. You can find more information about this standard at http://www.faqs.org/rfcs/rfc3881.html.

A message in DirX Audit consists of five sections:

Identification section – identification of the audit message with some basic information.

Where From section – location where the message originated.

Who section – a user, hardware device or software process that originated the event (subject or active participant).

What section (can occur multiple times) – object of the message (passive participant).

Original Message section – the entire original message that the audited system provided.

The following figure illustrates this layout and lists the attributes in each section:

Audit Message Logical Schema
Figure 1. Audit Message Logical Schema

The next sections describe the attributes of these sections and how they are used by applications like DirX Identity or DirX Access.

This chapter also describes the mapping of the DirX Audit message logical schema to the database schema.

About the Identification Section

The Identification section describes the message itself with some basic information. The attributes of this section are:

When – (required) the universal coordinated time (UTC) when the event originated.

  • Access – delivers a date and time stamp.

  • Identity – delivers a date and time stamp.

Operation – (optional) an indicator for the type of action performed during the message
(C – Create, R – Read, U – Update, D – Delete, E – Execute).

  • Access – uses all codes.

  • Identity – uses all codes besides R (Read).

UID – (optional) a unique identifier of the message. If this value is not supplied, DirX Audit Server calculates one.

  • Access – delivers a unique identifier per message.

  • Identity – delivers a unique identifier per message. This identifier can be part of the Cause field or the Identification – Extension – Value field, where Identification – Extension – Type is equal to IDENTIFICATION_CAUSE, of other messages to indicate relationship.

Cause – (optional) a unique identifier of the message that triggered this message.

  • Access – the identifier of a user session.

  • Identity – the identifier of the parent message, if any.

Outcome – (required) whether the message succeeded (0) or failed (4, 8, 12).

  • Access – delivers 0 for OK, 4 for Minor Failure, 8 for Serious Failure and 12 for Major Failure.

  • Identity – delivers 0 for OK and 8 for all other values.

Sensitivity – (optional) an arbitrary string value indicating the sensitivity of the message.

  • Access – not set by default.

  • Identity – not set by default.

Type – (optional) the type of the audited message.

  • Access – delivers additional information in this field: more values are possible.

  • Identity – delivers additional information in this field: manual, on event, on request, on schedule.

Source – (optional) an identification of the audited system.

  • Access – delivers additional information in this field: DirX Access.

  • Identity – delivers additional information in this field: DirX Identity.

Category – (optional) the category of the audited message.

  • Access – delivers additional information in this field: Authentication, Authorization, Configuration, Federation, Policy, ServerLifecycle, Sso, User and so on.

  • Identity – delivers additional information in this field: Object, Assignment, Workflow and so on.

About the Identification – Extension Section

This section can occur multiple times. It is an extensible structure containing type – value pairs.
The attributes of this section are:

Type – (required) a type of the extension.

Value – (required) a value of the extension.

About the Where From Section

The Where From section describes the location at which the message originated.
The attributes of this section are:

Application – (optional) the name of the application where the message originated.

  • Access – delivers the component name.

  • Identity – delivers the component name.

Address – (required) the address of the audit source (for example, the LDAP server).

  • Access – the physical (TCP/IP) or logical (DNS) address of the machine where the message occurred.

  • Identity – the physical (TCP/IP) or logical (DNS) address of the machine where the message occurred.

Type – (optional) the type of the audit source.

  • Access – not used.

  • Identity – not used.

About the Where From – Extension Section

This section can occur multiple times. It is an extensible structure containing type – value pairs. The attributes of this section are:

Type – (required) a type of the extension.

Value – (required) a value of the extension.

About the Who Section

The Who section provides information about the actor who triggered the message. In the RFC 3881 standard, this section is called the Active Participant. The attributes of this section are:

Name – (required) the human-meaningful name of the subject.

  • Access – the human-readable name of the user or other meaningful information.

  • Identity – the name of the subject. You can set up this information for the service layer via audit policies if you set the Name property.

UID – (optional) the unique identifier of the subject.

  • Access – the subject identifier.

  • Identity – the dxrUID attribute of the subject. This value is an auto-generated number in DirX Identity.

DN – (optional) the structured identifier of the subject.

  • Access – the distinguished name (DN) of the subject who originated the message.

  • Identity – the distinguished name (DN) of the subject who originated the message.

From Address – (optional) the logical network location of the application activity.

  • Access – for authentication messages, the address at which the authentication was performed.

  • Identity – the address of the client application (when available).

From Type – (optional) an identifier for the type of network access point (1 – Machine Name, 2 – IP Address).

  • Access – a value according to the From Address field or the fixed value 0.

  • Identity – a value according to the From Address field or the fixed value 0.

Role – (optional) the role the subject played when performing the message, as assigned in role-based access control security.

  • Access – a list of the user’s roles.

  • Identity – not used.

About the Who – Extension Section

This section can occur multiple times. It is an extensible structure containing type – value pairs.
The attributes of this section are:

Type – (required) a type of the extension.

Value – (required) a value of the extension.

  • Access – information such as credential information.

  • Identity – You can set up this information for the service layer via audit policies. It is recommended to follow personal data protection rules and use pseudonyms.
    Examples: cn=D638471, employeeNumber=1058347296.

About the What Section

The What section provides information about the changed object(s) of the message. In the RFC 3881 standard, this section is called the Participant Object. The attributes of this section are:

Name – (required) an instance-specific descriptor of the audited object (for example, a person’s identifier).

  • Access – information about the resource the user tried to access (for example, a URL).

  • Identity – the name of the object. You can set up this information for the service layer via audit policies if you set the Name property.

UID – (optional) the unique identifier of the object.

  • Access – not used.

  • Identity – the dxrUID attribute of the subject. This value is an auto-generated number in DirX Identity.

DN – (optional) the structured identifier of the object.

  • Access – the fixed value N/A.

  • Identity – the distinguished name (DN) of the object.

Sensitivity – (optional) the policy-defined sensitivity for the object, such as VIP, high importance objects, or similar topics.

  • Access – not used.

  • Identity – not used.

Lifecycle – (optional) an identifier for the object’s life-cycle stage.

  • Access – not used.

  • Identity – information about the change operation on the “what” object that relates its life-cycle in the Identity Store. For example, when a user-role assignment is removed, the operation for the entire message is “Delete”. However, there are four “what” objects associated with this operation: the workflow, the user, the role, and the assignment. The Lifecycle value for “assignment” is Delete (the assignment was removed from the Identity Store), while the value for workflow, object and user is “Info” (their life-cycles in the Identity Store were not affected).

Query – (optional) the current query for a query-type object.

  • Access – not used.

  • Identity – not used.

Type – (required) a type identifier of the contained object.

  • Access – the type of the object.

  • Identity – the type of the object. You can set up this information for the service layer via audit policies if you set the Audit Type property.

About the What – Extension Section

This section can occur multiple times. It contains additional identifying information in type-value pairs. The attributes of this section are:

Type – (required) a type of the extension.

Value – (required) a value of the extension.

  • Access – not used.

  • Identity – You can set up this information for the service layer via audit policies. It is recommended to follow personal data protection rules and use pseudonyms.
    Examples: cn=D638471, employeeNumber=1058347296.

About the What – Detail Section

The section can occur multiple times. It contains specific details about what was accessed on the object. Operation, type and value show exactly what was changed on the object.

  • Access – all detail information.

  • Identity – all detail information.

The attributes of this section are:

Operation – (optional) the operation applied when the object was changed.

Type – (required) the type on what the change was applied.

Value – (optional) the value applied when the object was changed.

About the Database Schema

The DirX Audit message logical schema is mapped to the database schema. The following table describes how message attributes are mapped to tables and their columns in the database schema.

Section
Attribute		 Table
Column

Identification -
When

DAT_AUDITMESSAGES
IDENTIFICATION_WHEN

Identification -
Operation

DAT_AUDITMESSAGES
IDENTIFICATION_OP

Identification -
UID

DAT_AUDITMESSAGES
IDENTIFICATION_UID

Identification -
Cause

DAT_AUDITMESSAGES
IDENTIFICATION_CAUSE

Identification -
Outcome

DAT_AUDITMESSAGES
IDENTIFICATION_OUTCOME

Identification -
Sensitivity

DAT_AUDITMESSAGES
IDENTIFICATION_SENSITIVITY

Identification -
Type

DAT_AUDITMESSAGES
IDENTIFICATION_TYPE

Identification -
Source

DAT_AUDITMESSAGES
IDENTIFICATION_SOURCE

Identification -
Category

DAT_AUDITMESSAGES
IDENTIFICATION_CATEGORY

Identification - Extension -
Type

DAT_IDENTIFICATION_EXTENSIONS
TYPE

Identification - Extension -
Value

DAT_IDENTIFICATION_EXTENSIONS
VAL

Where From -
Application

DAT_AUDITMESSAGES
WHEREFROM_APPLICATION

Where From -
Address

DAT_AUDITMESSAGES
WHEREFROM_ADDRESS

Where From -
Type

DAT_AUDITMESSAGE_ADDITIONS
WHEREFROM_TYPE

Where From - Extension -
Type

DAT_WHEREFROM_EXTENSIONS
TYPE

Where From - Extension -
Value

DAT_WHEREFROM_EXTENSIONS
VAL

Who -
Name

DAT_AUDITMESSAGES
WHO_NAME

Who -
UID

DAT_AUDITMESSAGES
WHO_UID

Who -
DN

DAT_AUDITMESSAGE_ADDITIONS
WHO_DN

Who -
From Address

DAT_AUDITMESSAGE_ADDITIONS
WHO_FROMADDRESS

Who -
From Type

DAT_AUDITMESSAGE_ADDITIONS
WHO_FROMTYPE

Who -
Role

DAT_AUDITMESSAGE_ADDITIONS
WHO_ROLE

Who - Extension -
Type

DAT_WHO_EXTENSIONS
TYPE

Who - Extension -
Value

DAT_WHO_EXTENSIONS
VAL

What -
Name

DAT_WHATS
WHAT_NAME

What -
UID

DAT_WHATS
WHAT_UID

What -
DN

DAT_WHATS
WHAT_DN

What -
Sensitivity

DAT_WHATS
WHAT_SENSITIVITY

What -
Lifecycle

DAT_WHATS
WHAT_LIFECYCLE

What -
Query

DAT_WHATS
WHAT_QUERY

What -
Type

DAT_WHATS
WHAT_TYPE

What - Extension -
Type

DAT_WHAT_EXTENSIONS
TYPE

What - Extension -
Value

DAT_WHAT_EXTENSIONS
VAL

What - Detail -
Operation

DAT_WHAT_DETAILS
OP

What - Detail -
Type

DAT_WHAT_DETAILS
TYPE

What - Detail -
Value

DAT_WHAT_DETAILS
VAL

Original Message

DAT_ORIGINALMESSAGES
ORIGINALMESSAGE
DirX Audit Message Database Schema
Figure 2. DirX Audit Message Database Schema

About the Audit Event

The audit event contains data digested from the audit message on the logical operation, type and details. For example, it can provide information that the audit message represents an Add Assignment (Operation) on the User to Role (Type) and identifications of both user and role (Details).

The following table describes how audit event attributes are mapped to the table and its columns in the database schema.

Attribute Table.Column

Operation

DAT_AUDITEVENTS.OP

Type

DAT_AUDITEVENTS.TYPE

Detail

DAT_AUDITEVENTS.DETAIL

About the Context Record

The context record contains data on the causing event for most audit events. In particular, it holds names of requesters and approvers in approval activities like Request Add Assignment and Request Add Object.

DirX Audit Message Context Record
Figure 3. DirX Audit Message Context Record

The following table describes how context record attributes are mapped to tables and their columns in the database schema.

Attribute Table.Column

Requestor - Name

DAT_CONTEXTRECORDS.REQUESTOR_NAME

Requestor - UID

DAT_CONTEXTRECORDS.REQUESTOR_UID

User - Name

DAT_CONTEXTRECORDS.USER_NAME

User - UID

DAT_CONTEXTRECORDS.USER_UID

Cause - Operation

DAT_CONTEXTRECORDS.CAUSE_OP

Cause - Type

DAT_CONTEXTRECORDS.CAUSE_TYPE

Cause - Detail

DAT_CONTEXTRECORDS.CAUSE_DETAIL

Cause - Rules

DAT_CONTEXTRECORDS.CAUSE_RULES

Approver - Name

DAT_APPROVERS.APPROVER_NAME