Service connections in PingAuthorize enable you to augment authorization events with real-time data. For example, you might use signals from a risk service in policies to determine if a device requires step-up authentication.

You can integrate with HTTP, LDAP, and database services. Learn more about service settings in Common settings.

To add a new service:

  1. Go to the Trust Framework.
  2. On the Services tab, click the + icon and select Add new Service.
  3. Enter a unique name for the service.

    Periods (.) are not allowed in the name.

  4. Optional: For Description, enter a description of the service's purpose.

    The description is only visible on the Services tab, but it can help policy authors understand how to use services in policies.

  5. Optional: To nest the service under a parent in the tree, in the Parent list, select a parent service.

    Nesting helps group related services together. You can move the service to another location in the tree by selecting a different parent service. To remove nesting, click the Delete icon and leave Parent blank.

  6. Select a Service Type.
    • None: This is for a parent service. Nest other services under a parent to help organize services in the tree structure. There are no additional settings to complete for this type of service.
    • Database: Connections to database sources are currently unsupported.
    • HTTP: Connects to HTTP endpoints accessible over the public internet. For details about HTTP service settings, see HTTP services.
    • LDAP: Connects to LDAP sources and retrieves information through database queries. Learn more about LDAP service settings, in LDAP services.
  7. Optional: In the Value Settings section, define the data Type for the data returned by the service, and select the Secrets checkbox to encrypt that data in PingAuthorize logs.

    Depending on which mode you have configuredPingAuthorize in, service data secrets are recorded in one of two logs:

    • Embedded PDP mode: The service data values are encrypted in PingAuthorize/policy-decision.log.
    • External PDP mode: The service data values are encrypted in the decision-audit.log file distributed with the Policy Editor, but not PingAuthorize/policy-decision.log.

    To decrypt a service's data values, run the following command. In this example, RSNH/SPsNJSFQyyLSxdKsw== represents the encrypted service value string, and 54655374506153735068526153653939 represents the encryption key in hexadecimal. By default, the encryption key is TeStPaSsPhRaSe99 and cannot be changed.

    'echo -n "RSNH/SPsNJSFQyyLSxdKsw==" | base64 -d | openssl enc -aes-128-ecb -d -K "54655374506153735068526153653939"
  8. Optional: In the Timeout and Retry section, enter a Request Timeout value if you want to change the time in milliseconds that PingAuthorize waits for a service request to complete.

    The default timeout is 2000. If the timeout elapses before there is a successful service response, the service request is canceled, resulting in a timeout error.

  9. Optional: In the Rate Limits section, enter a Requests per Second value to change the maximum number of requests that decision points can make to the service per second.

    The default value is 1000000.

  10. Optional: Enable caching for the service.

    Caching improves system performance by storing data returned from a service and reusing it on subsequent service requests until the cache expires. Learn more in Service caching.

    1. Select the Enable Caching checkbox.
    2. For the Time to Live, enter the number of minutes that you want to store data retrieved from the service in the cache.
      Screen capture of the Cache Settings section of a service with the Enable Caching checkbox selected.

      The maximum time to live is 1440 minutes or 1 day.

    3. Optional: If you are enabling caching for an HTTP service, click + Header and select headers to exclude from the cache key.
      Screen capture of the Cache Settings section of a service with the Enable Caching checkbox selected and an example header exclusion

      Because the service cache is invalidated by any changes to the cache key, removing headers preserves the validity of the cache even when values of those headers change.