Skip to main content
Version: 1.12

Endpoint address

This is the interface by which the client contacts ADS for authorization services.

ADS provides a REST API for HTTPS or HTTP. The following REST endpoints can be used:

MethodURI pathDescription
GET/entrypoint
POST/authorizeauthorization endpoint

Endpoint addresses

note

For migration purposes, ADS provides an endpoint compatible with legacy PDP clients at /asm-pdp/authorize (for REST) or /asm-pdp/pdp (for SOAP). However, it is deprecated and should only be used to provide compatibility with legacy PDP installations during migration. It will be removed in a later version of ADS.

Application endpoints​

The functional part of Access Decision Service is located at the applicationConnectors property in the deployment configuration yaml file. The endpoints are as noted above. See Service connectors for configuration information.

Administration endpoints​

The non-functional parts are located at the adminConnectors property in the deployment configuration yaml file. See Service connectors for configuration information.

Healthcheck​

GET /healthcheck (an endpoint to determine the state of the application)

  • The healthcheck can be used as a readiness check, in which case it returns HTTP Status 200 OK.
  • The healthcheck will display the domain identifier (for both versions of the domain document format) of the domain that is currently in use to answer new requests. If the domain is retrieved via http, the healthcheck can serve as a verification that the correct domain has been retrieved.
  • The healthcheck will provide information about the last occurrence of a reconfiguration trigger (that is, a timestamp) as well as the reconfiguration attempt itself and its status (a timestamp and whether the reconfiguration was successful). If there was an unsuccessful domain reconfiguration attempt, an error message about the cause of the failure is included.

For an example of the healthcheck in use, see Checking that ADS is running.

Probes​

ADS reports its health status during different stages of its lifecycle to ensure its robustness in an orchestrated deployment. In this regard, ADS exposes three types of probes to check the health of a container through the following endpoints:

  • /healthcheck/liveness

  • /healthcheck/startup

  • /healthcheck/readiness

Liveness Probes

Liveness probes are used to check whether the application is healthy. If the liveness probe fails, the container may be restarted to revive the application.

Startup Probes

Startup probes are used to check whether the application within a container is started or not. If the startup probe fails, the container is stopped, and it follows the pod's restart policy.

Readiness Probes:

Readiness probes are used to check whether the container is ready to start accepting traffic or not. If the readiness probe fails, the container is not added to the service endpoint.

Metrics​

When the Prometheus monitoring application is used as a metrics backend for ADS, it pulls (or scrapes) data via an administration endpoint.

GET /admin/metrics/prometheus

The configuration of ADS for metrics data collection is described in the section Metrics.

System information​

GET /admin/system/info (an endpoint to access system information)

The endpoint returns a response with HTTP Status 200 OK and a JSON payload. The payload includes data on:

  • ADS instance identity
  • Application Name
  • Application Vendor
  • Application Version
  • Application Build Version
  • CLI Arguments
  • Domain id
  • Domain name (if configured)
  • Java Home Directory
  • Java Vendor
  • Java Version
  • Operating System Architecture
  • Operating System Name
  • Operating System Version

System information

The information may be useful to have when communicating with customer support. This system information is also included as one line in the log during ADS start-up. See Application version information for more information.