Configuration Properties

The PowerAuth Server uses the following public configuration properties:

Database Configuration

PowerAuth Service Configuration

Activation and Cryptography Configuration

HTTP Configuration

Spring Vault Configuration

Correlation HTTP Header Configuration

Monitoring and Observability

The WAR file includes the micrometer-registry-prometheus dependency. Discuss its configuration with the Spring Boot documentation.

Scheduled Jobs Configuration

Callback URL Events Configuration

PowerAuth monitors status of operations and activations. When their status changes, configured callbacks are triggered. The following properties allow you to configure the maximum number of attempts and the exponential backoff algorithm for dispatching a callback event. The default values are set with respect to the behavior of previous PowerAuth version. However, it is possible to override these defaults or configure each callback settings individually using the Callback URL Management API.

In certain scenarios, repeatedly attempting to dispatch callback events may be pointless due to system failure on the receiver’s side. To address this, if multiple callback events with the same configuration fail consecutively, the service temporarily halts further dispatch attempts and marks these events as failed without retrying. The number of consecutive failures allowed before stopping dispatch is defined by the failureThreshold property, while the halt period is configurable via the failureResetTimeout property. After this period, a callback dispatch attempt will be made again to check the receiver’s availability. If the failureThreshold is set to -1, the functionality is not enabled.

PowerAuth dispatches a callback as soon as a change in operation or activation status is detected. Each newly created callback is passed to a configurable thread pool executor for dispatch. Even if the thread pool’s queue is full, the callback will eventually be dispatched. Keep in mind that dispatching a callback involves database operations. Imbalanced settings of the thread pool size and database connection pool size can lead to system disruptions.

Callback events are periodically monitored to detect any stale callback events that might have become stuck during processing due to rare circumstances. When a currently processed callback event exceeds the defined forceRerunPeriod without completion, it is automatically scheduled to be rerun. By default, the force rerun period is calculated as the sum of the HTTP connection timeout, the HTTP response timeout, and an additional ten-second delay. This does not apply to callback events with max attempts set to 1, such callback events are never scheduled to be rerun.

The backoff period after the N-th attempt is calculated as follows:

exponentialBackoff = initialBackoff * backoffMultiplier^(N-1)
backoffPeriod = min(exponentialBackoff, maxBackoff)