PingAuthorize Talk to us

Install · deployment patterns · config as code

Deployment

The extensions install into PingAuthorize like any Server SDK extension, and come with the configuration to run them: registration batches, a server profile kept as code, and patterns for the two places PingAuthorize most often runs.

Into your server

Install, register, serve

  1. Install the bundle built for your PingAuthorize major version with manage-extension --install.
  2. Register the extension with the dsconfig batch in the bundle's config/ directory, once its arguments are set for your environment.
  3. Serve it by adding it to a connection handler's http-servlet-extension list. The handler decides the port, the TLS posture and who can reach it.

Building container images on PingAuthorize 11? Install the bundle at image build time with manage-extension --install. Delivering it through the server profile stopped setup on 11.1 with "Server Already Configured".

Deployment patterns

Behind a TLS edge, or on Kubernetes with SPIRE

Container platforms

Behind a TLS edge

For platforms that terminate TLS for you with a publicly trusted certificate.

  • A plaintext HTTP handler on an unprivileged port serves only the AuthZEN Adapter, and the platform's edge adds TLS in front of it.
  • The admin configuration and directory REST servlets stay off that handler, so the public port exposes the AuthZEN API and nothing else.
  • Set a bearer api-key to guard every endpoint except the two discovery documents. Without it, the adapter admits any caller.
  • The metadata document honours X-Forwarded-Proto, -Host and -Port, so clients discover your public URLs rather than the container's.
dsconfig set-connection-handler-prop \
  --handler-name "HTTP Connection Handler" \
  --set enabled:true --set listen-port:1080 \
  --set "http-servlet-extension:AuthZEN Adapter"
Kubernetes

With SPIRE

For clusters where every workload already has a SPIFFE identity.

  • The SPIFFE CSI driver mounts the SPIRE agent's Workload API socket into the PingAuthorize pod.
  • A dedicated mTLS handler presents the server's SVID and admits only client SVIDs from the trust bundle, optionally pinned to named workloads.
  • The AuthZEN Adapter admits listed workloads by SPIFFE ID, and spiffe-required removes the key fallback.
  • The decision APIs move to the mTLS handler, and the adapter reaches the engine on a loopback-only handler.
See the lock-down recipe

Config as code

A server profile, not a runbook

A PingAuthorize server profile applies dsconfig batches in order at setup, so every new server comes up configured the same way. The secrets those batches need - the policy server secret, the decision API secret and the adapter's API key - are environment variables substituted at setup.

  • Licensing at boot. Images fetch a PingAuthorize licence with Ping DevOps credentials instead of carrying a licence file.
  • Policy on startup. The Policy Editor image imports a policy snapshot as it starts, and the snapshot's file name becomes the branch the decision service evaluates.
  • Embedded or external. The AuthZEN translation happens in-process either way, whether policy is embedded in the server or served from a separate Policy Editor.
The profile configuresWith
Policy server connectionURL, shared secret, decision node and branch
Decision APIShared secret, its header, and a correlation-id response header
Policy decision servicePDP mode and Trust Framework version
Decision loggingQuery logger views for attributes, decision tree, request and services
Health checkThe Available State servlet at /healthcheck
AuthZEN AdapterRegistration, arguments and the handlers that serve it

Version-matched bundles

A bundle your server will accept, checked before it ships

PingAuthorize rejects a bundle built for the wrong major version with little more than unrecognized or unsupported extension type - at install, long after the build. The deployment build makes that choice for you, then checks it:

  1. Reads the PingAuthorize version from the image the server profile deploys onto.
  2. Builds the matching variant: javax for PingAuthorize 10, jakarta for PingAuthorize 11.
  3. Refuses the bundle unless its UnboundID-Server-SDK-Version matches the image's major version.
  4. Refuses it unless the compiled adapter references the servlet namespace that version expects.
  5. Only then stages it into the server profile.

Why it matters. A version mismatch otherwise surfaces on the server, during a deployment, with an error that does not say what is wrong. Caught at build time, it never leaves the workstation.

Purpose-bound delegation

Policy and a service beside the server, not a change to it

The purpose-bound delegation design adds nothing to PingAuthorize itself. It runs PingAuthorize 11 in embedded-PDP mode with the AuthZEN Adapter installed as above, a policy deployment package that holds the bank's purpose map, secondary-use list and the ten rules, and a small purpose service the policy calls for federation facts and the model's reading. The language model runs beside it, inside the network; nothing about a customer's task leaves.

Every authorization server and enforcement point in the design asks PingAuthorize through the adapter's standard AuthZEN endpoints, so the same PDP can serve a bank's other AuthZEN callers unchanged.

  • PingAuthorize 11.1, embedded PDP, the AuthZEN Adapter, and the policy as a deployment package.
  • Purpose service: federation facts with no model, then the judge, reachable only from the PDP.
  • The model: an open-weights 3B model on Ollama by default, on CPU if need be; a hosted typed decision model can take its place behind the same interface.
  • An authorization server that does RFC 8693 token exchange and asks PingAuthorize before it issues - PingFederate in the hosted demo.