Audit logging reference
AM writes log messages generated from audit events triggered by its components, instances, and other Ping Identity Platform products.
Audit log format
This section presents the audit log format for each topic-based file, event names, and audit constants used in its log messages.
Access log format
Schema property | Description | ||
---|---|---|---|
|
A universally unique identifier (UUID) for the message object,
such as |
||
|
The timestamp when AM logged the message, in UTC format to millisecond precision:
|
||
|
The name of the audit event.
For example, |
||
|
The UUID of the transaction, which identifies an external request when it comes into the system boundary.
Any events generated while handling that request will be assigned that transaction ID,
so that you may see the same transaction ID even for different audit event topics.
For example, Trusted AM deployments with multiple instances, components, and Ping Identity Platform products can propagate the
transaction ID through each call across the stack.
AM reads the |
||
|
The universal identifier for authenticated users.
For example, |
||
|
A unique random string generated as an alias for each AM session ID and OAuth 2.0 token. For example, For OAuth 2.0 tokens, whenever AM generates an access or grant token,
it also generates unique random value and logs it as an alias.
In this way, it is possible to trace back an access token back to its originating grant token,
trace the grant token back to the session in which it was created, and then trace how the session was authenticated.
An example of a [ "1979edf68543ead001", "8878e51a-f2aa-464f-b1cc-b12fd6daa415", "3df9a5c3-8d1e-4ee3-93d6-b9bbe58163bc" ]
|
||
|
The IP address of the AM server.
For example, |
||
|
The port number used by the AM server.
For example, |
||
|
The client hostname. This field is only populated if reverse DNS lookup is enabled. |
||
|
The client IP address. |
||
|
The client port number. |
||
|
The list of roles for the authorized user. |
||
|
The component part of the authorized ID. |
||
|
The protocol associated with the request operation.
Possible values: |
||
|
The request operation.
For common REST operations, possible values are: For PLL operations, possible values are:
|
||
|
The detailed information about the request operation. For example:
Example values for an OAuth 2.0 app tree flow:
Example values for an SAML 2.0 app tree flow:
|
||
|
The HTTP method requested by the client.
For example, |
||
|
The path of the HTTP request.
For example, |
||
|
The HTTP query parameter string. For example:
|
||
|
The HTTP header for the request. For example:
|
||
|
A JSON map of key-value pairs and appears as its own property to allow for denylisting fields or values. |
||
|
Not used in AM. |
||
|
The response status of the request.
For example, |
||
|
The response status code, depending on the protocol. For common REST, HTTP failure codes are displayed but not HTTP success codes. For PLL endpoints, PLL error codes are displayed. |
||
|
The message associated with |
||
|
The time to execute the access event, usually in millisecond precision. |
||
|
The elapsed time units of the response.
For example, |
||
|
The AM service utilized.
For example, |
||
|
The realm where the operation occurred.
For example, the Top Level Realm ( |
Activity log format
Property | Description | ||
---|---|---|---|
|
A universally unique identifier (UUID) for the message object,
such as |
||
|
The timestamp when AM logged the message, in UTC format to millisecond precision:
|
||
|
The name of the audit event.
For example, |
||
|
The UUID of the transaction, which identifies an external request when it comes into the system boundary.
Any events generated while handling that request will be assigned that transaction ID,
so that you may see the same transaction ID for same even for different audit event topics.
For example, |
||
|
The universal identifier for authenticated users.
For example, |
||
|
An array containing a random context ID
that identifies the session and a random string generated from an OAuth 2.0/OpenID Connect 1.0 flow
that could track an access token ID or an grant token ID.
For example,
|
||
|
The user to run the activity as.
May be used in delegated administration.
For example, |
||
|
The identifier of an object that has been created, updated, or deleted.
For logging sessions, the session |
||
|
The state change operation invoked: |
||
|
Not used. |
||
|
Not used. |
||
|
Not used. |
||
|
Not used. |
||
|
The AM service utilized. For example, |
||
|
The realm where the operation occurred.
For example, the Top Level Realm ( |
Authentication log format
Property | Description | ||
---|---|---|---|
|
A universally unique identifier (UUID) for the message object,
such as |
||
|
The timestamp when AM logged the message, in UTC format to millisecond precision:
|
||
|
The name of the audit event.
For example, |
||
|
The UUID of the transaction, which identifies an external request when it comes into the system boundary.
Any events generated while handling that request will be assigned that transaction ID,
so that you may see the same transaction ID even for different audit event topics.
For example, |
||
|
The universal identifier for authenticated users.
For example, |
||
|
An array containing a unique random context ID. For example:
|
||
|
The result for an authentication tree. Possible values are |
||
|
The array of accounts used to authenticate, such as |
||
|
Not used |
||
|
The JSON representation of the authentication tree or node details. AM creates an event as each node completes and a final event at the end of the tree. For example:
|
||
|
The AM service utilized.
For example, |
||
|
The realm where the operation occurred.
For example, the Top Level Realm ( |
Config log format
Property | Description |
---|---|
|
A universally unique identifier (UUID) for the message object.
For example, |
|
The timestamp when AM logged the message, in UTC format to millisecond precision:
|
|
The name of the audit event.
For example, |
|
The UUID of the transaction, which identifies an external request when it comes into the system boundary.
Any events generated while handling that request will be assigned that transaction ID,
so that you may see the same transaction ID for different audit event topics.
For example, |
|
Not used. You can determine the value for this field by linking to the access event using the same |
|
Not used. |
|
The user to run the activity as.
May be used in delegated administration.
For example, |
|
The identifier of a system object that has been created, modified, or deleted.
For example, |
|
The state change operation invoked: |
|
The JSON representation of the object prior to the activity. For example:
|
|
The JSON representation of the object after the activity. For example:
|
|
The fields that were changed.
For example, |
|
Not used. |
|
Not used. |
|
The realm where the operation occurred.
For example, the Top Level Realm ( |
Audit log events
This table summarizes the predefined events for each topic:
Topic | Event name | Event description |
---|---|---|
|
|
When AM starts handling an HTTP request. |
|
|
When AM finishes handling an HTTP request. |
|
|
Event for an OIDC back-channel logout. |
|
|
Event for closing a connection factory. |
|
|
Event for a state change for the connection factory, such as when configuration changes lead to an attempt to reconnect. |
|
|
When a group is changed. |
|
|
When an identity is updated, such as a change to an attribute. |
|
|
Key Manager reload event. |
|
|
When a user is logged out by their username (client-side sessions only). |
|
|
Event for creating a new connection factory. |
|
|
When the self-service registration process is complete. |
|
|
When the self-service password reset process is complete. |
|
|
When an authenticated session is created. |
|
|
When an authenticated session is destroyed. |
|
|
When an authenticated session has been inactive for longer than configured idle timeout duration. |
|
|
Event for the explicit logout of an authenticated session. |
|
|
When an authenticated session exceeds the maximum configured lifetime. |
|
|
When an authenticated session property changes. |
|
|
Event for an OAuth 2.0 token exchange. |
|
|
Event for the initiation of a backchannel authentication request. |
|
|
Event for an authentication process logout. |
|
|
Event for the successful or failed completion of an authentication node login. |
|
|
Logged when authentication through a tree starts. If the tree includes a node that suspends the authentication journey,
this event is logged again after the suspension with a result of |
|
|
Logged when an authentication journey completes, whether successful or not.
|
|
|
When the |
|
|
When the AM configuration is updated. |
Audit log components
This table lists the predefined audit event components that make up log messages:
Event component | AM component, service, or feature |
---|---|
|
Web and Java agents |
|
Auditing service |
|
Authentication service |
|
Batch service |
|
Boot.json component |
|
Configuration |
|
CORS preflight component |
|
Core Token Service |
|
Dashboard service |
|
Trusted devices |
|
API documentation component |
|
Groups component |
|
ID repo event component |
|
Jato audit event component |
|
Monitoring |
|
Mobile authentication |
|
OAuth 2.0, OpenID Connect 1.0, and UMA |
|
Policies |
|
Push Notification service |
|
RADIUS server |
|
Realms and sub-realms |
|
Recording service |
|
SAML v2.0 |
|
Scripting service |
|
Secrets component |
|
User Self-Service service |
|
Service Config Cache audit event component |
|
Server information service |
|
Session service |
|
|
|
REST Secure Token Service |
|
Internet of Things component |
|
Users component |
Audit log fields
The following tables list all the available fields that you can use to filter audit logs. The log fields are listed in JSON notation.
Some fields may contain sensitive information and aren’t suitable for recording in audit logs. By default, AM has a preconfigured allowlist that defines which object fields can be logged.
The table indicates which fields appear on the default allowlist. If an allowlisted field contains an object, then listing the field means the whole object is allowlisted.
Access log fields
Field | Allowlisted by default |
---|---|
|
Yes |
|
Yes |
|
Yes |
|
|
|
Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
|
Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
|
Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
|
|
|
|
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
|
|
|
|
|
|
Yes |
|
|
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
|
|
Yes |
|
Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
|
Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
|
|
|
Yes |
|
|
|
|
|
Yes |
|
|
|
|
|
|
|
Yes |
|
|
|
|
|
Yes |
|
|
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
Activity log fields
Field | Allowlisted by default |
---|---|
|
Yes |
|
|
|
|
|
Yes |
|
Yes |
|
Yes |
|
|
|
|
|
Yes |
|
Yes |
|
|
|
|
|
|
|
|
|
Yes |
|
Yes |
|
|
|
Yes |
|
|
|
|
|
Yes |
|
|
|
Yes |
|
Yes |
|
|
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
|
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
|
|
|
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
|
|
|
|
|
|
|
|
Yes |
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
|
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
Config log fields
Field | Allowlisted by default |
---|---|
|
Yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
Yes |
|
JDBC audit log tables
AM writes audit events to relational databases using the JDBC audit event handler. This section presents the columns for each audit table.
am_auditaccess
Column | Datatype | Description |
---|---|---|
|
|
A universally unique identifier (UUID) for the message object,
such as |
|
|
The timestamp when AM logged the message, in UTC format to millisecond precision:
|
|
|
The UUID of the transaction, which identifies an external request when it comes into the system boundary.
Any events generated while handling that request will be assigned that transaction ID,
so that you may see the same transaction ID for different audit event topics.
For example, Trusted AM deployments with multiple instances, components, and Ping Identity Platform products
can propagate a transaction ID through each call across the platform.
AM reads the |
|
|
The name of the audit event.
For example, |
|
|
The universal identifier for the authenticated user.
For example, |
|
|
The tracking IDs of the event, used by all topics. |
|
|
The IP address of the AM server. |
|
|
The port number used by the AM server.
For example, |
|
|
The client hostname. This column is only populated if reverse DNS lookup is enabled. |
|
|
The client IP address. |
|
|
The client port number. |
|
|
The protocol associated with the request operation.
Possible values: |
|
|
The request operation. For common REST operations, possible values: For PLL operations, possible values: |
|
|
The detailed information about the request operation. For example:
|
|
|
The HTTP method requested by the client.
For example, |
|
|
The HTTP method requested by the client.
For example, |
|
|
The path of the HTTP request.
For example, |
|
|
The HTTP query parameter string. For example:
|
|
|
The HTTP headers for the request. For example:
|
|
|
A JSON map of key-value pairs and appears as its own property to allow for denylisting fields or values. For example:
The line feeds and truncated values in the example are for readability purposes. |
|
|
Captures the headers returned by AM to the client (that is, the inverse of |
|
|
The response status of the request.
For example, |
|
|
The response status code, depending on the protocol. For common REST, HTTP failure codes are displayed but not HTTP success codes. For PLL endpoints, PLL error codes are displayed. |
|
|
The message associated with the response status code.
For example, a response status code of 401 has a response detail of |
|
|
The time to execute the access event, usually in millisecond precision. |
|
|
The elapsed time units of the response.
For example, |
|
|
The AM service utilized.
For example, |
|
|
The realm where the operation occurred.
For example, the Top Level Realm ( |
am_auditauthentication
Column | Datatype | Description |
---|---|---|
|
|
A universally unique identifier (UUID) for the message object,
such as |
|
|
The timestamp when AM logged the message, in UTC format to millisecond precision:
|
|
|
The UUID of the transaction, which identifies an external request when it comes into the system boundary.
Any events generated while handling that request will be assigned that transaction ID,
so that you may see the same transaction ID for different audit event topics.
For example, Trusted AM deployments with multiple instances, components, and Ping Identity Platform products
can propagate a transaction ID through each call across the platform.
AM reads the |
|
|
The name of the audit event.
For example, |
|
|
The universal identifier for authenticated users.
For example, |
|
|
The tracking IDs of the event, used by all topics. |
|
|
The result for an authentication tree. Possible values are |
|
|
The array of accounts used to authenticate, such as |
|
|
Not used. |
|
|
The JSON representation of the authentication tree or node details. AM creates an event as each node completes and a final event at the end of the tree. For example:
|
|
|
The AM service utilized.
For example, |
|
|
The realm where the operation occurred.
For example, the Top Level Realm ( |
am_auditactivity
Column | Datatype | Description |
---|---|---|
|
|
A universally unique identifier (UUID) for the message object,
such as |
|
|
The timestamp when AM logged the message, in UTC format to millisecond precision:
|
|
|
The UUID of the transaction, which identifies an external request when it comes into the system boundary.
Any events generated while handling that request will be assigned that transaction ID,
so that you may see the same transaction ID for different audit event topics.
For example, Trusted AM deployments with multiple instances, components, and Ping Identity Platform products
can propagate a transaction ID through each call across the platform.
AM reads the |
|
|
The name of the audit event.
For example, |
|
|
The universal identifier for authenticated users.
For example, |
|
|
The tracking IDs of the event, used by all topics. |
|
|
The user to run the activity as.
May be used in delegated administration.
For example, |
|
|
The identifier of a system object that has been created, modified, or deleted.
For example, |
|
|
The state change operation invoked: |
|
|
The JSON representation of the object prior to the activity. For example:
|
|
|
The JSON representation of the object after the activity. For example:
|
|
|
The columns that were changed.
For example, |
|
|
Not used. |
|
|
The AM service utilized.
For example, |
|
|
The realm where the operation occurred.
For example, the Top Level Realm ( |
am_auditconfig
Column | Datatype | Description |
---|---|---|
|
|
A universally unique identifier (UUID) for the message object,
such as |
|
|
The timestamp when AM logged the message, in UTC format to millisecond precision:
|
|
|
The UUID of the transaction, which identifies an external request when it comes into the system boundary.
Any events generated while handling that request will be assigned that transaction ID,
so that you may see the same transaction ID for different audit event topics.
For example, Trusted AM deployments with multiple instances, components, and Ping Identity Platform products
can propagate a transaction ID through each call across the platform.
AM reads the |
|
|
The name of the audit event.
For example, |
|
|
The universal identifier for authenticated users.
For example, |
|
|
The tracking IDs of the event, used by all topics. |
|
|
The user to run the activity as.
May be used in delegated administration.
For example, |
|
|
The identifier of a system object that has been created, modified, or deleted.
For example, |
|
|
The state change operation invoked: |
|
|
The JSON representation of the object prior to the activity. For example:
|
|
|
The JSON representation of the object after the activity. For example:
|
|
|
The columns that were changed.
For example, |
|
|
Not used. |
|
|
The AM service utilized.
For example, |
|
|
The realm where the operation occurred.
For example, the Top Level Realm ( |