PingAuthorize

Installing and uninstalling PingAuthorize

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

Seeing PingAuthorize in action

To quickly see PingAuthorize in action, see Getting started with PingAuthorize (tutorials).

Components

Policy Editor

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

PingAuthorize Server

Enforces policies to control fine-grained access to data.

Each configured REST application programming interface (API) accesses data through PingAuthorize Server, which applies the data-access policies to allow, block, filter, or modify protected resource and data attributes.

Deployment methods

You can deploy PingAuthorize in either of the following ways.

Deployment method Recommended for

Docker

Server administrators familiar with Docker who want to use orchestration to manage their environments.

For more information, see Docker deployment.

Manual

Server administrators familiar with their operating systems who want to tweak and maintain their environments themselves.

For more information, see Manual installation.

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. The policy is enforced by the SCIM service. See SCIM API request and response flow for more information.

Diagram of the SCIM inbound and outbound request flow, from the HTTP client to the PingAuthorize SCIM API and policy engine to the user stores and back again—with calls out from PingAuthorize to policy information points as needed

API security gateway as reverse proxy

You can configure PingAuthorize Server’s API security gateway as a reverse proxy to an existing JavaScript Object Notation (JSON) REST API. In this architecture, PingAuthorize Server acts as an intermediary between clients and existing API services. The policy is enforced by the API security gateway. See API gateway request and response flow for more information.

Diagram of the reverse proxy inbound and outbound request flow, from the HTTP client to the PingAuthorize policy engine to the API and back again—with calls out from PingAuthorize to policy information points as needed

API security gateway in sideband configuration

You can configure PingAuthorize Server’s API security gateway as an extension to an existing API lifecycle management gateway, which is commonly known as a sideband configuration. In this architecture, the API lifecycle management gateway functions as the intermediary between clients and existing API services. However, API request and response data still flows through PingAuthorize Server to enforce policy. See API gateway integration for more information.

Diagram of the sideband inbound and outbound request flow, from the HTTP client to the API gateway to the PingAuthorize policy engine in sideband mode, which calls out to policy information points as needed, then back to the API gateway, on to the API resource, back to the API gateway, and finally returning as a response to the HTTP client

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. See About the Authorization Policy Decision APIs for more information.

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

Policy decision environments

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

Development environment (external)

PingAuthorize Server and the Policy Editor are used together during the development of policies, with the PingAuthorize Server enforcing policy decisions, and the Policy Editor serving as the external PDP.

Other pre-production and production environments (embedded)

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

The following sections describe these policy decision environments in more detail.

Development environment

To allow teams to test data-access policies during their development, PingAuthorize Server is configured to obtain policy decisions from the Policy Editor. To enable this configuration, set the Policy Decision Service PDP Mode to external.

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 mode inbound and outbound request flow, from the HTTP client to the PingAuthorize policy engine to the Policy Editor, which calls out to policy information points as needed, then back to policy engine, on to the API resource, back to the policy engine, and finally returning as a response to the HTTP client

As test API requests are proxied through PingAuthorize Server’s API security gateway, policy decisions are obtained from the Policy Editor and are enforced by the API security gateway.

Other pre-production and production environments

The Policy Editor is not a part of so-called "higher" environments. Rather, for these environments, the policy administrator bundles policies into a deployment package and then directly integrates them with the PDP. Embedding the policies in the PDP helps to reduce latency in the decision request-response flow. To enable this configuration, set the Policy Decision Service PDP Mode to embedded.

The Policy Editor can deploy policy deployment packages for integration with 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 mode inbound and outbound request flow, from the HTTP client to the PingAuthorize policy engine with deployed policies, which calls out to policy information points as needed, then back to policy engine, on to the API resource, back to the policy engine, and finally returning as a response to the HTTP client