As you plan your PingAuthorize 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.
REST APIs access data through PingAuthorize Server, which applies the data-access policies to allow, block, filter, or modify data resources and data attributes.
Deployment methods
You have two options to deploy PingAuthorize.
| Deployment method | Recommended for |
|---|---|
|
Docker |
Server administrators familiar with Docker who want to use orchestration to manage their environments. For more information, see Docker installation. |
|
Manual |
Server administrators familiar with their operating systems who want to tweak and maintain their environments themselves. For more information, see Manual installation. |
Deployment architectures
PingAuthorize Server supports the following deployment 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
The following sections describe these deployment 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.
API Security Gateway as reverse proxy
You can deploy PingAuthorize Server's API security gateway as a reverse proxy to an existing JSON-based REST API. In this configuration, PingAuthorize Server acts as an intermediary between clients and existing API services. The policy is enforced by the API security gateway.
API Security Gateway in Sideband configuration
You can deploy 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 configuration, 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.
Deployment environments
You can deploy PingAuthorize Server in either of the following environments:
- Development environment
- PingAuthorize Server and the Policy Editor are used together during the development of policies.
- Other pre-production and production environments
- After policies are developed, they are tested in other pre-production environments and eventually put into production.
The following sections describe these deployment 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. The development environment supports all deployment architectures. In this configuration, the Policy Decision Service is set to External mode.
The following image shows PingAuthorize Server configured in the Reverse Proxy architecture.
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. Instead, the policy is exported from the Policy Editor and is imported into PingAuthorize Server.
In the following configuration, the Policy Decision Service is set to Embedded mode.