HTTP services
The policy decision point (PDP) can perform requests to HTTP services. These requests can send and receive text, JavaScript Object Notation (JSON), and Extensible Markup Language (XML) content.
HTTP authentication supports using a simple username and password, bearer token, or OAuth 2.0 client credentials flow.
You can send custom headers with any request, which you can make dynamically in various ways by interpolating attribute values into various parameters. For more information, see Attribute interpolation.
Core settings
- URL
-
URL for the REST endpoint that the PDP accesses. The Policy Manager can interpolate attributes anywhere in the URL.
Because no escaping of attribute values takes place, make certain that this action is completed in the attribute definition to prevent non-valid characters in the URL.
- HTTP Method
-
Method to send in the HTTP request.
- Content Type
-
Content-Type header to send, which relates to the body of the request.
- Body
-
Body to send with the request. The Policy Manager can interpolate attributes anywhere in the body with no escaping.
Authentication
The Authentication list contains the following HTTP authentication types, which correspond to an authorization header sent with the request:
- None
-
Default value that indicates the PDP sends no authorization header.
- Basic
-
Reveals the choices for attributes whose values function as the username and password of an HTTP request with basic authentication.
- Bearer Token
-
Reveals a token selector. The PDP sends the selected attribute as the authorization token in an HTTP request with bearer authentication.
- OAuth 2.0 (Client Credentials)
-
Reduces configuration complexity and time to production when connecting to HTTP services that require OAuth authentication. Reveals four configuration options.
This flow sends information to the authorization server in a
POST
request in the body. If the authorization server expects a different format, the flow will not complete successfully.-
Token Endpoint
Authorization server’s endpoint that can grant an access token.
PingAuthorize caches the token and reuses it if it is not expired.
-
Client Id
Unique string representing the client identifier. This value can be either a constant or an interpolated attribute to resolve the value at runtime.
-
Client Secret
Attribute that will resolve to the client secret.
You can resolve the Client Id and Client Secret attributes from the PingAuthorize configuration.
-
Scope (optional)
A comma-separated list of scopes representing the scope of the access request.
-
Headers
You can add any number of custom headers to the request. The header names are fixed strings, but their values can be constants or attribute values. To switch between constant and attribute, toggle C / A, which is next to a header value.
Certificate validation
With certificate validation, you can define TLS and Mutual-TLS (M-TLS) certificates and keys when connecting to the TLS (or SSL) based service.
When using external PDP mode, you can declare local file-based trust stores and key stores by providing an options file during setup. For more information, see Specifying custom configuration with an options file.
When using embedded PDP mode, you can declare local file-based trust stores and key stores by assigning trust manager providers and key manager providers to the Policy Decision Service. For more information, see Use policies in a production environment.
- Server (TLS)
-
Applies when validating the certificate or certificate chain sent from the server. You have three options when validating a server certificate:
-
No Validation
Skips validating the server certificates and initiates connection without any restriction.
-
Default
This option is the default for Server (TLS).
Uses the default trust store provided by the runtime environment.
Use this if you are trying to connect to a service that has a certificate issued from a valid certificate authority.
-
Custom
Allows the user to define a custom certificate or certificate chain that is stored in a trust store:
-
Truststore name
The name given to the trust store in
configuration.yml
. -
Alias
Certificates in the trust stores are mapped by alias. You must set the alias in the trust store to specify which certificate to use for validation.
Attributes can be interpolated anywhere in the value.
-
Alias password
If the certificate is password protected, it might need to provide the password.
Attributes can be interpolated anywhere in the value.
-
-
- Client (M-TLS)
-
Some services might require the client to provide a client certificate when initializing the connection. To provide a client certificate, enable this setting and provide a custom key store to be sent to the service:
-
Keystore name
The name given to the key store in
configuration.yml
. -
Alias
Key-value pairs and the certificate entry in the key stores are mapped by alias. You must set the alias in the key store to specify which entry to use for validation.
Attributes can be interpolated anywhere in the value.
-
Alias password
If the certificate entry is password protected, it might need to provide the password.
Attributes can be interpolated anywhere in the value.
-