Audit logging reference
AM writes log messages generated from audit events triggered by its components, instances, and other ForgeRock-based stack 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 | ||
---|---|---|---|
|
Specifies a universally unique identifier (UUID) for the message object,
such as |
||
|
Specifies the timestamp when AM logged the message, in UTC format to millisecond precision:
|
||
|
Specifies the name of the audit event.
For example, |
||
|
Specifies 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, AM supports a feature where trusted AM deployment with multiple instances, components,
and ForgeRock stack products can propagate the transaction ID through each call across the stack.
AM reads the |
||
|
Specifies the universal identifier for authenticated users.
For example, |
||
|
Specifies a unique random string generated as an alias for each AM session ID and OAuth 2.0 token.
In releases prior to OpenAM 13.0.0, the OpenAM 13.0.0 extended this property to handle OAuth 2.0 tokens.
In this case, 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" ]
|
||
|
Specifies the IP address of the AM server.
For example, |
||
|
Specifies the port number used by the AM server.
For example, |
||
|
Specifies the client hostname. This field is only populated if reverse DNS lookup is enabled. |
||
|
Specifies the client IP address. |
||
|
Specifies the client port number. |
||
|
Specifies the list of roles for the authorized user. |
||
|
Specifies the component part of the authorized ID, such as |
||
|
Specifies the protocol associated with the request operation.
Possible values: |
||
|
Specifies the request operation.
For Common REST operations, possible values are: For PLL operations, possible values are:
|
||
|
Specifies the detailed information about the request operation. For example:
|
||
|
Specifies the HTTP method requested by the client.
For example, |
||
|
Specifies the path of the HTTP request.
For example, |
||
|
Specifies the HTTP query parameter string. For example:
|
||
|
Specifies the HTTP header for the request. For example:
|
||
|
Specifies a JSON map of key-value pairs and appears as its own property to allow for denylisting fields or values. |
||
|
Not used in AM. |
||
|
Specifies the response status of the request.
For example, |
||
|
Specifies 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. |
||
|
Specifies the message associated with |
||
|
Specifies the time to execute the access event, usually in millisecond precision. |
||
|
Specifies the elapsed time units of the response.
For example, |
||
|
Specifies the AM service utilized.
For example, |
||
|
Specifies the realm where the operation occurred.
For example, the Top Level Realm ( |
Activity log format
Property | Description | ||
---|---|---|---|
|
Specifies a universally unique identifier (UUID) for the message object,
such as |
||
|
Specifies the timestamp when AM logged the message, in UTC format to millisecond precision:
|
||
|
Specifies the name of the audit event.
For example, |
||
|
Specifies 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, |
||
|
Specifies the universal identifier for authenticated users.
For example, |
||
|
Specifies 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,
|
||
|
Specifies the user to run the activity as.
May be used in delegated administration.
For example, |
||
|
Specifies the identifier of an object that has been created, updated, or deleted.
For logging sessions, the session |
||
|
Specifies the state change operation invoked: |
||
|
Not used. |
||
|
Not used. |
||
|
Not used. |
||
|
Not used. |
||
|
Specifies the AM service utilized. For example, |
||
|
Specifies the realm where the operation occurred.
For example, the Top Level Realm ( |
Authentication log format
Property | Description | ||
---|---|---|---|
|
Specifies a universally unique identifier (UUID) for the message object,
such as |
||
|
Specifies the timestamp when AM logged the message, in UTC format to millisecond precision:
|
||
|
Specifies the name of the audit event.
For example, |
||
|
Specifies 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, |
||
|
Specifies the universal identifier for authenticated users.
For example, |
||
|
Specifies an array containing a unique random context ID. For example:
|
||
|
Depending on the event being logged, specifies the outcome of:
Possible values are |
||
|
Specifies the array of accounts used to authenticate, such as |
||
|
Not used |
||
|
Specifies the JSON representation of the details of an authentication module, chain, tree or node. AM creates an event as each module or node completes and a final event at the end of the chain or tree. Examples:
|
||
|
Specifies the AM service utilized.
For example, |
||
|
Specifies the realm where the operation occurred.
For example, the Top Level Realm ( |
Config log format
Property | Description |
---|---|
|
Specifies a universally unique identifier (UUID) for the message object.
For example, |
|
Specifies the timestamp when AM logged the message, in UTC format to millisecond precision:
|
|
Specifies the name of the audit event.
For example, |
|
Specifies 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. |
|
Specifies the user to run the activity as.
May be used in delegated administration.
For example, |
|
Specifies the identifier of a system object that has been created, modified, or deleted.
For example, |
|
Specifies the state change operation invoked: |
|
Specifies the JSON representation of the object prior to the activity. For example:
|
|
Specifies the JSON representation of the object after the activity. For example:
|
|
Specifies the fields that were changed.
For example, |
|
Not used. |
|
Not used. |
|
Specifies 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. |
|
|
A 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 SSO session is created. |
|
|
When an SSO session is destroyed. |
|
|
When an SSO session has been inactive for longer than configured idle timeout duration. |
|
|
Event for the explicit logout of an SSO session. |
|
|
When an SSO session exceeds the maximum configured lifetime. |
|
|
When an SSO session property changes. |
|
|
Event for an OAuth 2.0 token exchange. |
|
|
Event for the successful or failed completion of an authentication chain login. |
|
|
Event for the successful or failed completion of an authentication module login. |
|
|
Event for an authentication process logout. |
|
|
Event for the successful or failed completion of an authentication node login. |
|
|
Event for the successful or failed completion of an authentication tree login. |
|
|
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 |
|
User Self-Service service |
|
Secrets component |
|
Service Config Cache audit event component |
|
Server information service |
|
Session service |
|
|
|
Secure Token Service: REST and SOAP |
|
Internet of Things component |
|
Users component |
Audit log failure reasons
The following predefined authentication failure reasons are written to the audit log.
These failure reasons are audited only for authentication using modules and chains, not for authentication using trees. |
Failure | Description |
---|---|
|
User account has expired. |
|
Authentication type is denied. |
|
Level-based authentication: Invalid authentication level. |
|
Invalid credentials entered. |
|
Realm does not exist. |
|
Maximum number of failure attempts exceeded. User is locked out. |
|
Incorrect/invalid credentials presented. |
|
Login timed out. |
|
Limit for maximum number of allowed sessions has been reached. |
|
Authentication module is denied. |
|
Authentication chain does not exist. |
|
No user profile found for this user. |
|
Realm is not active. |
|
Cannot create a session. |
|
User is not active. |
|
Role-based authentication: user does not belong to this role. |
|
The user ID was not found. |
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 are not 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 |
|
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 |
---|---|---|
|
|
Specifies a universally unique identifier (UUID) for the message object,
such as |
|
|
Specifies the timestamp when AM logged the message, in UTC format to millisecond precision:
|
|
|
Specifies 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, AM supports a feature where a trusted AM deployment with multiple instances, components,
and ForgeRock products can propagate a transaction ID through each call across the stack.
AM reads the |
|
|
Specifies the name of the audit event.
For example, |
|
|
Specifies the universal identifier for the authenticated user.
For example, |
|
|
Specifies the tracking IDs of the event, used by all topics. |
|
|
Specifies the IP address of the AM server. |
|
|
Specifies the port number used by the AM server.
For example, |
|
|
Specifies the client hostname. This column is only populated if reverse DNS lookup is enabled. |
|
|
Specifies the client IP address. |
|
|
Specifies the client port number. |
|
|
Specifies the protocol associated with the request operation.
Possible values: |
|
|
Specifies the request operation. For Common REST operations, possible values: For PLL operations, possible values: |
|
|
Specifies the detailed information about the request operation. For example:
|
|
|
Specifies the HTTP method requested by the client.
For example, |
|
|
Specifies the HTTP method requested by the client.
For example, |
|
|
Specifies the path of the HTTP request.
For example, |
|
|
Specifies the HTTP query parameter string. For example:
|
|
|
Specifies the HTTP headers for the request. For example:
|
|
|
Specifies a JSON map of key-value pairs and appears as its own property to allow for blacklisting fields or values. For example:
Note: 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 |
|
|
Specifies the response status of the request.
For example, |
|
|
Specifies 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. |
|
|
Specifies the message associated with the response status code.
For example, a response status code of 401 has a response detail of |
|
|
Specifies the time to execute the access event, usually in millisecond precision. |
|
|
Specifies the elapsed time units of the response.
For example, |
|
|
Specifies the AM service utilized.
For example, |
|
|
Specifies the realm where the operation occurred.
For example, the Top Level Realm ( |
am_auditauthentication
Column | Datatype | Description |
---|---|---|
|
|
Specifies a universally unique identifier (UUID) for the message object,
such as |
|
|
Specifies the timestamp when AM logged the message, in UTC format to millisecond precision:
|
|
|
Specifies 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, AM supports a feature where a trusted AM deployment with multiple instances, components,
and ForgeRock products can propagate a transaction ID through each call across the stack.
AM reads the |
|
|
Specifies the name of the audit event.
For example, ` AM-LOGIN-MODULE-COMPLETED` and |
|
|
Specifies the universal identifier for authenticated users.
For example, |
|
|
Specifies the tracking IDs of the event, used by all topics. |
|
|
Depending on the event being logged, specifies the outcome of:
Possible values are |
|
|
Specifies the array of accounts used to authenticate, such as |
|
|
Not used. |
|
|
Specifies the JSON representation of the details of an authentication module, chain, tree or node. AM creates an event as each module or node completes and a final event at the end of the chain or tree. For example:
|
|
|
Specifies the AM service utilized.
For example, |
|
|
Specifies the realm where the operation occurred.
For example, the Top Level Realm ( |
am_auditactivity
Column | Datatype | Description |
---|---|---|
|
|
Specifies a universally unique identifier (UUID) for the message object,
such as |
|
|
Specifies the timestamp when AM logged the message, in UTC format to millisecond precision:
|
|
|
Specifies 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, AM supports a feature where a trusted AM deployment with multiple instances, components,
and ForgeRock products can propagate a transaction ID through each call across the stack.
AM reads the |
|
|
Specifies the name of the audit event.
For example, |
|
|
Specifies the universal identifier for authenticated users.
For example, |
|
|
Specifies the tracking IDs of the event, used by all topics. |
|
|
Specifies the user to run the activity as.
May be used in delegated administration.
For example, |
|
|
Specifies the identifier of a system object that has been created, modified, or deleted.
For example, |
|
|
Specifies the state change operation invoked: |
|
|
Specifies the JSON representation of the object prior to the activity. For example:
|
|
|
Specifies the JSON representation of the object after the activity. For example:
|
|
|
Specifies the columns that were changed.
For example, |
|
|
Not used. |
|
|
Specifies the AM service utilized.
For example, |
|
|
Specifies the realm where the operation occurred.
For example, the Top Level Realm ( |
am_auditconfig
Column | Datatype | Description |
---|---|---|
|
|
Specifies a universally unique identifier (UUID) for the message object,
such as |
|
|
Specifies the timestamp when AM logged the message, in UTC format to millisecond precision:
|
|
|
Specifies 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, AM supports a feature where a trusted AM deployment with multiple instances, components,
and ForgeRock products can propagate a transaction ID through each call across the stack.
AM reads the |
|
|
Specifies the name of the audit event.
For example, |
|
|
Specifies the universal identifier for authenticated users.
For example, |
|
|
Specifies the tracking IDs of the event, used by all topics. |
|
|
Specifies the user to run the activity as.
May be used in delegated administration.
For example, |
|
|
Specifies the identifier of a system object that has been created, modified, or deleted.
For example, |
|
|
Specifies the state change operation invoked: |
|
|
Specifies the JSON representation of the object prior to the activity. For example:
|
|
|
Specifies the JSON representation of the object after the activity. For example:
|
|
|
Specifies the columns that were changed.
For example, |
|
|
Not used. |
|
|
Specifies the AM service utilized.
For example, |
|
|
Specifies the realm where the operation occurred.
For example, the Top Level Realm ( |