PingAuthorize

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.

To prevent invalidation of HTTP service response caches caused by changes to the cache key, you can exclude certain headers that you expect to change from service cache entries. For more information, see Connecting a service and Service caching.

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.