--- title: Security audit logging description: PingAccess audit logs record a select subset of transaction log information at runtime plus additional details meant to facilitate security auditing and regulatory compliance. component: pingaccess version: 9.0 page_id: pingaccess:configuring_and_customizing_pingaccess:pa_security_audit_logging canonical_url: https://docs.pingidentity.com/pingaccess/9.0/configuring_and_customizing_pingaccess/pa_security_audit_logging.html revdate: July 25, 2025 section_ids: audit-log-configuration: Audit log configuration --- # Security audit logging PingAccess audit logs record a select subset of transaction log information at runtime plus additional details meant to facilitate security auditing and regulatory compliance. You can find the audit logs in `/log/`. The audit log configuration table describes the elements that the audit logs record. You can configure these elements in `conf/log4j2.xml`. | | | | - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | Because log files can be viewed or modified using a variety of common applications, it's possible for log files to be manipulated to include untrusted or malicious data. You should take appropriate steps to secure your log files. Don't open them in applications that could allow for data execution, such as internet browsers or Microsoft Office products. Instead, open your log files in a common, lightweight text editor. | PingAccess generates these audit logs: * `pingaccess_engine_audit.log` Records transactions of configured resources. Additionally, the log records transaction details when PingAccess sends requests to PingFederate. For example, Security Token Service (STS) *(tooltip: \
\

An entity responsible for responding to WS-Trust requests for validation and issuance of security tokens used for SSO authentication to web services.\

\
)*, OAuth *(tooltip: \
\

A standard framework that enables an application (OAuth client) to obtain access tokens from an OAuth authorization server for the purpose of retrieving protected resources on a resource server.\

\
)* 2.0, and JSON Web Signature (JWS) *(tooltip: \
\

A signed instance of a JSON Web Token (JWT) based on IETF standard syntax and used for the exchange of signed content.\

\
)* requests. * `pingaccess_api_audit.log` Records PingAccess administrative application programming interface (API) *(tooltip: \
\

A specification of interactions available for building software to access an application or service.\

\
)* transactions. These transactions represent activity in the PingAccess administrative console. This log also records transaction activity if you're using scripts to configure PingAccess. * `pingaccess_agent_audit.log` Records transactions between PingAccess agents and the PingAccess engine. * `pingaccess_sideband_client_audit.log` Records transactions sent to and from the sideband client integration. * `pingaccess_sideband_audit.log` Records the end-user transactions that the sideband client request captures. ## Audit log configuration The following elements described in the audit log elements table are applicable only to the `pingaccess_engine_audit.log`: * `AUDIT.failedRuleName` * `AUDIT.failedRuleClass` * `AUDIT.failedRuleClass` * `AUDIT.failedRuleSetName` * `AUDIT.resource` | | | | - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | | To get information about the timing for backchannel calls, such as the OpenID Connect (OIDC) *(tooltip: \
\

An authentication protocol built on top of OAuth that authenticates users and enables clients (relying parties) of all types to request and receive information about authenticated sessions and users. OIDC is extensible, allowing clients to use optional features such as encryption of identity data, discovery of OpenID Providers (OAuth authorization servers), and session management.\

\
)* `UserInfo` endpoint *(tooltip: \
\

One end in a communication channel, typically a URI.\

\
)* call, use the `exchangeID` property to match related log entries and the `AUDIT.roundTripMS` and `AUDIT.proxyroundTripMS` properties to view the timing. | > **Collapse: Audit log elements** > > | Element | Description | > | ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | > | `%d` | Transaction time. | > | `exchangeId` | Identifies the ID for a specific request-response pair. | > | `AUDIT.applicationID` | Specifies the ID of the requested application. | > | `AUDIT.applicationName` | Specifies the name of the requested application. | > | `AUDIT.resourceID` | Specifies the ID of the requested resource. | > | `AUDIT.resourceName` | Specifies the name of the requested resource. | > | `AUDIT.pathPrefix` | Specifies the path prefix of the requested application or resource. | > | `AUDIT.pathPrefixType` | Specifies the pattern type of the path prefix, `Wildcard` or `Regex`. | > | `AUDIT.authMech` | The mechanism used for authentication:- Engine Auditing > > `Cookie` (WAM session), `OAuth`, `unknown` (for example, pass-through or static assets). Pass-through assets are resources with no policies or web session configured. > > - Admin Auditing > > `Basic`, `OAuth`, `Cookie`, `unknown`(`unknown` displays only in an authentication failure). | > | `AUDIT.client` | The Internet Protocol (IP) *(tooltip: \
\

The method by which data is sent across the internet from the source host to the destination host.\

\
)* address of the requesting client. | > | `AUDIT.failedRuleName` | The name of the rule that failed. If there was no rule failure, this field will be blank. | > | `AUDIT.failedRuleType` | The type of rule that failed. If there was no rule failure, this field will be blank. | > | `AUDIT.failedRuleClass` | The Java class of the rule that failed. If there was no rule failure, this field will be blank. | > | `AUDIT.failedRuleSetName` | The name of the containing rule set that failed. If there was no rule failure, this field will be blank. | > | `AUDIT.host` | The PingAccess host name or IP address. | > | `AUDIT.targetHost` | The backend target that processed the request and generated a response to the PingAccess engine.This variable is unset when PingAccess generated the response directly. | > | `AUDIT.method` | The HTTP method of the request. For example, `GET`. | > | `AUDIT.resource` | The name of the resource used to fulfill the request. | > | `AUDIT.responseCode` | The HTTP status code of the response. For example, `200`. | > | `AUDIT.requestUri` | The request Uniform Resource Identifier (URI) *(tooltip: \
\

Identifies a web resource with a string of characters conforming to a specified format.\

\
)* portion of the request. For example, `/foo/bar`. | > | `AUDIT.subject` | The subject of the transaction. | > | `AUDIT.trackingId` | The PingFederate tracking ID. You can use this element to help correlate audit information in the PingAccess audit log with information recorded in the PingFederate audit log.This value depends on whether the application type is `Web` or `API`:- If the application type is `Web`, the value is formatted as `tid:`. The *\* can be used by the [Session Revocation API endpoint](https://docs.pingidentity.com/pingfederate/latest/developers_reference_guide/pf_session_revocation_api_endpoint.html) to revoke the session without disabling the user in the identity store. > > - If the application type is `API`, the value is formatted as `atid:`. The *\* value is derived from the OAuth Access token for the session and serves only as an identifier. It can't be used for session revocation. | > | `AUDIT.reqReceivedMillisec` | The time in milliseconds since 1970 that a client request was first received. | > | `AUDIT.reqSentMillisec` | The time in milliseconds since 1970 that the agent or engine sent a backchannel *(tooltip: \
\

A direct, cross-domain communication path using a protocol that doesn't rely on a browser as an intermediary.\

\
)* or proxy request. | > | `AUDIT.respReceivedMillisec` | The time in milliseconds since 1970 that the agent or engine received a response from a backchannel call or proxy request. | > | `AUDIT.respSentMillisec` | The time in milliseconds since 1970 that a response was sent back to the client. | > | `AUDIT.roundTripMS` | The `respSentMillisec` time minus the `reqReceivedMillisec` time.This represents the total number of milliseconds that it took PingAccess to respond to a client's request, including the `proxyRoundTripMS`. | > | `AUDIT.proxyRoundTripMS` | The `respReceivedMillisec` time minus the `reqSentMillisec` time. This represents the total number of milliseconds that PingAccess was waiting for another entity to respond to a backchannel call or proxy request. | > | `AUDIT.siteUnavailableInfo` | If a site is unavailable, this is reason why the last attempted site target is unavailable. | > | `AUDIT.agentName` | The name of the agent. | > | `AUDIT.responder` | The component that generated the response. Valid values are `PingAccess`, `PingOne`, `Site`, `Third Party Service`, `OpenID Provider`, and `Authorization Server`. The PingOne responder type refers only to the PingOne Protect integration. When you're using PingOne as a token provider, PingAccess labels backchannel communications as either OpenID Provider or Authorization Server, depending on the context of the transaction. | > | `AUDIT.clientCertSerialNum` | The serial number of the client certificate. | > | `AUDIT.clientCertSubjectDn` | The subject of the client certificate as an X.500 domain name. | > | `AUDIT.clientCertIssuerDn` | The issuer of the client certificate as an X.500 domain name. | > | `AUDIT.sidebandName` | The name of the requesting sideband client. | > | `AUDIT.sidebandDecision` | The policy decision returned in response to the sideband client request. Valid values are `accept` and `reject`. | > | `agent{a-header-value-key}` | The `vnd-pi-agent` header value for a given key. This represents the header value that an agent sends to PingAccess. Well-known keys are:- v > > The version of the agent that's making the request. > > - h > > The host name of the server where the agent resides. > > - t > > The type of agent or the type of platform where the agent resides.This information isn't sent by default. You can find more information about logging these details in [Agent inventory logging](pa_agent_inventory_logging.html). | > | `appRequestHeader{a-header-name}` | The HTTP request header value for the given HTTP request header name. Represents the header value that PingAccess sends to the backend site. | > | `appResponseHeader{a-header-name}` | The HTTP response header value for the given HTTP request header name. Represents the header value that the application sent PingAccess. | > | `clientRequestHeader{a-header-name}` | The HTTP request header value for the given HTTP request header name. Represents the header value that the client sent PingAccess. | > | `clientResponseHeader{a-header-name}` | The HTTP response header value for the given HTTP request header name. Represents the header value that PingAccess returned to the client. |