Additional domain properties

The Access Decision Service (ADS) requires a valid authorization domain to evaluate an access request and produce an authorization decision. The retrieval of the authorization domain can be made at startup or during runtime. Additionally, ADS can retrieve the authorization domain from external sources such as the Axiomatics Services Manager (ASM), Authorization Domain Manager (ADM), or any other remote endpoint.

By default, ADS attempts to retrieve a valid authorization domain only once during startup. You can change this default behavior using the properties listed below:

Properties	Description
domain	This sub-section defines the authorization domain configuration.
├─ path	Defines the location of the authorization domain configuration, either locally or as an HTTP/HTTPS path.
├─ refreshInterval	The time interval duration between each refresh of the domain configuration during runtime. Read more in the Runtime updating of domain configurations section. Info: The value must be expressed as an integer number and a time unit (m, min, mins, minute, minutes, s , second, seconds, h, hour, hours, d, day, or days).
├─ reportNotReadyOnDomainRefreshError	When set to true, ADS reports as not ready if an error occurs during a domain refresh. Default value is false. For more details, refer to Healthcheck report on failed domain updates section.
└─ startup	Configuration settings related to domain retrieval at service startup, including optional retry behavior.
├─ maxRetries	The number of retries that ADS will attempt to read a valid authorization domain at startup, until it succeeds.
├─ retryInterval	The duration between each retry attempt at startup. Info: The value must be expressed as an integer number and a time unit. Its minimum value is 1 second.

domain: 
    path: <path_to_file>/domain.yaml
    refreshInterval: 5 seconds
    reportNotReadyOnDomainRefreshError: true
    startup:
        maxRetries: 5
        retryInterval: 5 seconds

Retry mechanism

At startup, ADS tries to fetch a valid authorization domain using a retry mechanism. It will attempt to connect up to the number of times specified by maxRetries, and it will wait for the duration set by retryInterval between each attempt.

The retry mechanism is designed to time out when the total duration (maxRetries * retryInterval) is reached. To prevent ADS from stopping its attempts prematurely, it's recommended to set the retryInterval higher than your network's timeout.

Runtime updating of domain configurations

In addition to the default behavior of reading the domain configuration only at start-up, ADS can be configured to update the domain configuration during runtime by polling its source at regular intervals. This allows for the updating of policies or attribute connectors without having to stop and redeploy ADS each time the domain configuration is updated. This may be particularly useful during policy development and testing.

note

Domain refresh and runtime domain updates are enabled only after the domain is successfully initialized at startup.

The updating process involves no downtime. ADS keeps accepting and processing requests while reconfiguring, and a running ADS processes any given request only once, until completion, using its most recent working configuration, that is, the processing of a request is not halted or retried when a domain configuration is updated.

The refresh feature will only reload the domain if its content has changed. Since ADS uses dynamic cache management the cache clears only when necessary, based on specific domain changes.

Healthcheck report on failed domain updates

You can configure the ADS readiness probe to return a 503 - Service Unavailable error when the service fails to refresh the domain. The probe depends on successful domain initialization and continues to return a 503 error until initialization completes.

To enable this behavior, set the reportNotReadyOnDomainRefreshError property to true.

This property has no effect if runtime domain configuration updates are disabled.