PingAuthorize

PingAuthorize architectural overview

When planning your PingAuthorize dynamic authorization software deployment, you should review the components to install as well as the potential deployment methods, architectures, and environments.

Components

Policy Editor

The Policy Editor gives policy administrators the ability to develop and test data-access policies.

PingAuthorize Server

The PingAuthorize Server enforces policies to control fine-grained access to data.

When you configure a REST API to access data through the PingAuthorize Server, the server applies data-access policies that allow, block, filter, or modify protected resource and data attributes.

Implementation architectures

PingAuthorize Server supports the following implementation and data flow architectures for enforcing fine-grained access to data:

The following sections describe these architectures in more detail.

SCIM API to datastores

The PingAuthorize Server System for Cross-domain Identity Management (SCIM) service provides a REST API for data that is stored in one or more external datastores, based on the SCIM 2.0 standard. Authorization policies are enforced by the SCIM service. Learn more in SCIM API request and response flow.

Diagram of the SCIM inbound and outbound request flow, showing traffic moving from the HTTP client through the SCIM API to the backend user store, with calls to an external policy information point as needed.

API security gateway as reverse proxy

You can configure PingAuthorize Server’s API security gateway as a reverse proxy to an existing JSON REST API. In this architecture, PingAuthorize Server acts as an intermediary between clients and existing API services. Authorization policies are enforced by the API security gateway. Learn more in API gateway request and response flow.

Diagram of the reverse proxy inbound and outbound request flow, showing traffic moving from the HTTP client through the PingAuthorize API security gateway to the backend API, with calls to an external policy information point as needed.

API security gateway in sideband configuration

You can configure the PingAuthorize Server’s API security gateway as an extension to an existing API lifecycle management gateway, commonly known as a sideband configuration. In this architecture, the API lifecycle management gateway functions as the intermediary between clients and existing API services and enforces policy decisions made by the PingAuthorize Server. Learn more in API gateway integration.

Diagram of the sideband inbound and outbound request flow, showing traffic from the HTTP client through the API Gateway to the backend API, with calls made to the PingAuthorize decision engine and external policy information points as needed.

PDP APIs for non-API use cases

You can implement either of the PingAuthorize Server’s PDP APIs to support policy decisions in cases where you don’t need to protect an API resource. Learn more about Authorization Policy Decision APIs.

Diagram of the PDP API inbound and outbound request flow, showing traffic from the requestor through the servlet container to the PingAuthorize decision engine, and back again.

Policy decision environments

You can configure PingAuthorize for either of the following policy decision environments:

Development environment (external PDP)

Policies are developed in the Policy Editor. The Policy Editor serves as the external policy decision point (PDP), and the PingAuthorize Server serves as the policy enforcement point (PEP).

This configuration accelerates policy deployment by putting the decision point closer to your policy updates, making it ideal for development or testing environments.

External PDP mode is not intended for use in production environments.

The following image shows PingAuthorize Server configured in a reverse proxy architecture. The development environment supports all PingAuthorize implementation and data flow architectures.

Diagram of the external PDP mode inbound and outbound request flow, showing traffic from the HTTP client through the PingAuthorize server to the backend API, with calls made to the Policy Editor and external policy information points as needed.

Learn more about configuring PingAuthorize for development environments in Configuring external PDP mode.

Pre-production and production environments (embedded PDP)

Policies are developed in the Policy Editor and deployed to the PingAuthorize Server, which serves as both the PEP and the PDP. This configuration supports policy testing in pre-production environments and live policy decisions in production environments.

In these environments, the policy administrator bundles policies into a deployment package and then publishes them to the PingAuthorize Server. Embedding the policies in the PingAuthorize Server reduces latency in the decision request-response flow.

The Policy Editor can deploy policy deployment packages to the PingAuthorize Server using one of the following methods:

The following image shows PingAuthorize Server configured in the reverse proxy architecture. Pre-production and production environments support all PingAuthorize implementation and data flow architectures.

Diagram of the embedded PDP mode inbound and outbound request flow, showing traffic from the HTTP client through the PingAuthorize server to the backend API, with calls made to external policy information points as needed.

Learn more about configuring PingAuthorize for production environments in Configuring embedded PDP mode.