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:
| Method | URI path | Description |
|---|---|---|
| GET | / | entrypoint |
| POST | /authorize | authorization endpoint |
Endpoint addresses
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.