Several features require the the Curity Identity Server to make HTTP requests to external services.
For example, the SCIM data sources must make HTTP requests to SCIM APIs, while the JSON data source consumes a JSON-based REST API.
For this reason, the server provides configurable HTTP clients which can be used to connect to these different external services.
HTTP clients are configured separately from where they are used, under Facilities. This allows the same HTTP client to be used in multiple places.
Facilities
Note
This section describes the HTTP client high level configuration. For details, see the Configuration Reference.
The following aspects of a HTTP client may be configured:
The scheme defines whether https or http should be used.
https
http
Use HTTPS wherever feasible. Avoid HTTP as much as possible, since it is unencrypted and insecure.
Warning
Sensitive data (including all OAuth and authenticators payloads) should only ever use https between servers.
A connection pool can be enabled so that TCP connections to the same host may be re-used by a HTTP client to make separate HTTP requests.
By default, no connection pool is used.
When enabled, HTTP clients can re-use TCP connections to the same host for separate HTTP requests.
HTTP clients may cache responses if configured with a cache.
Responses are only cached when the origin server explicitly sends the appropriate headers (heuristics caching is not currently supported).
Currently, only in-memory (per node) cache is supported.
Different HTTP clients can have different authentication methods.
Available authentication methods:
Basic authentication OAuth client credentials Client certificates (see below)
When HTTPS is used, the HTTP client will use TLS to establish encrypted connections.
Server certificates can be verified with a configured trust store, or with the default Java trust store.
A client-keystore can also be configured so that the client can utilize mutual TLS.
client-keystore
Hostname verification can be disabled for debugging purposes.
For more details about truststores and keystores, see Cryptography.
A proxy server can be configured for each HTTP client. Optionally, user credentials can be configured for proxy authentication.
HTTP clients can be configured to expose metrics about requests and about the connection pool (if enabled). Request metrics are defined based on the class of response status codes (successful, client error and server error) and include labels for the HTTP client and target host. Connection pool metrics expose measurements such as the pool size and the used connections, and include a label for the HTTP client. For details on the available metrics refer to Monitoring.
Note that request metrics are captured from the perspective of HTTP client consumers, which may not match the requests actually sent to the target host. For example, if a request is retried, metrics account for a single request.