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).
- 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.
REST APIs access data through PingAuthorize Server, which applies the data-access policies to allow, block, filter, or modify data resources and data attributes.
You can deploy PingAuthorize in either of the following ways.
|Deployment method||Recommended for|
Server administrators familiar with Docker who want to use orchestration to manage their environments.
For more information, see Docker deployment.
Server administrators familiar with their operating systems who want to tweak and maintain their environments themselves.
For more information, see Manual installation.
PingAuthorize Server supports the following implementation and data flow architectures for enforcing fine-grained access to data:
- System for Cross-domain Identity Management (SCIM) API to datastores
- API security gateway as reverse proxy
- API security gateway in sideband configuration
- Policy Decision Point (PDP) APIs, for non-API use cases
The following sections describe these architectures in more detail.
SCIM API to datastores
The PingAuthorize Server 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.
API security gateway as reverse proxy
You can configure PingAuthorize Server's API security gateway as a reverse proxy to an existing JSON-based 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.
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.
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.
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.
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 the Reverse Proxy architecture. The development environment supports all PingAuthorize implementation and data flow architectures.
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:
- Exporting the deployment package as a static file
- Publishing via the Deployment Manager to a cloud package store (AWS S3, Azure)
- Publishing via the Deployment Manager to a file system package store
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.