Introduction to Authorization

PingOne Authorize is a cloud-based authorization service that controls what end users can see and do inside of applications and APIs.

Modern customer experiences demand sophisticated authorization controls balanced with continuous security, consistently applied across an exploding number of applications. PingOne Authorize allows organizations to centrally configure authorization requirements, ranging from simple rules to real-time, fine-grained policies. Rather than scatter control among IT infrastructure and application code, centralized authorization enables Identity and Access Management (IAM) teams and stakeholders to collaborate and quickly adapt to new requirements, use cases, and regulations.

PingOne Authorize has the following capabilities:

API Access Management: API Access Management addresses the needs of IAM teams by simplifying common API access control use cases and eliminating the guesswork of OAuth and OpenID Connect.
Dynamic Authorization: Dynamic Authorization addresses the needs of application owners and stakeholders, empowering them to leverage real-time data in fine-grained policies that go well beyond identity and roles. PingOne Authorize can integrate with other PingOne services, such as PingOne Protect, and exploit information in a PingOne user profile to augment authorization events in real-time.

Use the PingOne Authorize connector to make policy-based authorization decisions in your PingOne DaVinci flows. Learn more in PingOne Authorize Connector.

Learn about Ping Identity’s on-premise dynamic authorization solution in PingAuthorize.

Dynamic authorization

With dynamic authorization, centralized rules and policies control what users can see and do in your application. Policies evaluate context to determine access, including preferences, devices, risk scores, history, behaviors, transactions, and financial data. You can pull in additional signals in real-time when transactions are made.

Dynamic authorization offers significant benefits over role-based control:

Enhanced visibility and control: Replace hundreds of roles with a few policies that are centrally managed across sensitive applications. This streamlines your access management process and makes it easy to update and deploy policies across your organization.
Greater business agility: Take authorization out of your applications and centralize it to deliver a better user experience more quickly. Any stakeholder can collaborate on policy without code changes or application downtime. Your organization can react quickly to business challenges or changing regulatory requirements, increasing your agility and flexibility.
Improved security and regulatory compliance: Central monitoring and tracking of user activity and data access provides greater insight into user behavior and suspicious activities. Safeguard your sensitive data and address your customer’s growing data privacy concerns by giving them greater control over and insight into their data and how it’s used.
Lower costs: Bring new solutions to market faster because you don’t have to wait for code changes on the backend. The capability to update your authorization logic in seconds allows your organization to focus on core competencies instead of access control.

How dynamic authorization works

Dynamic authorization externalizes access decisions to a decision service that determines what a user can see and do based on centrally managed policies and additional information gathered from information points. Attributes and rules are used in policies to instantiate business logic.

The following components are involved in dynamic authorization.

Component	Description
Admin console	Enables centralized authoring and management of policies, including a built-in decision endpoint for testing. This is sometimes known as a Policy Administration Point (PAP).
Decision integration point	Intercepts requests to protected resources and packages relevant information into a decision request, then sends the request to the decision service. Also passes the decision response back to the application. This is sometimes known as a Policy Enforcement Point (PEP). An API gateway is one type of decision integration point.
Decision service	Receives a decision request, evaluates the request against relevant policies, and returns a decision response that permits or denies access, or causes other systems to take additional actions. This is sometimes known as a Policy Decision Point (PDP), and in PingOne Authorize, it’s part of the admin console.
Information point	Provides the decision service with additional information used to make an informed decision. This is sometimes known as a Policy Information Point (PIP). You define information points, such as data APIs, as attributes and services in the Trust Framework.

Component

Description

Admin console

Enables centralized authoring and management of policies, including a built-in decision endpoint for testing. This is sometimes known as a Policy Administration Point (PAP).

Decision integration point

Intercepts requests to protected resources and packages relevant information into a decision request, then sends the request to the decision service. Also passes the decision response back to the application. This is sometimes known as a Policy Enforcement Point (PEP).

An API gateway is one type of decision integration point.

Decision service

Receives a decision request, evaluates the request against relevant policies, and returns a decision response that permits or denies access, or causes other systems to take additional actions. This is sometimes known as a Policy Decision Point (PDP), and in PingOne Authorize, it’s part of the admin console.

Information point

Provides the decision service with additional information used to make an informed decision. This is sometimes known as a Policy Information Point (PIP).

You define information points, such as data APIs, as attributes and services in the Trust Framework.

The following diagram shows a typical dynamic authorization request flow. Numbers in the diagram correspond to the steps that follow.

Flow diagram showing the steps in a typical decision request flow.

A user requests access to a protected resource through your application, such as viewing account details, accessing a database, or making a payment.
The decision integration point intercepts the user’s request and builds a decision request with relevant information, such as attributes for the requestor’s ID or account number. Then, the integration point sends the request to the decision service.
The decision service identifies targeted policies, which are authored and deployed using the admin console, that relate to protection of the resource, such as whether the account is active, or the user is a manager. Then the decision service calls out to registered information points to obtain extra information, such as the rest of the user information for that user ID.
The decision service evaluates relevant policies.
The decision service builds the decision response and sends it back to the decision integration point. The decision response includes a permit or deny decision and statements and advice that provide additional information for upstream applications to act on.
If the decision permits, the decision integration point fetches the protected resource. Based on presence statements, additional actions are triggered that allow contextually responsive user flows.
The decision integration point sends the resource to the requester with restrictions on the details and resources sent back that are based on the decision response.

API Access Management

API Access Management provides a simple way to manage access control while extending the authorization capabilities of your organization’s API gateway.

With API Access Management, IAM teams centrally manage common access control use cases inPingOne, while enforcement is distributed to API gateways using Ping Identity integration kits. Now IAM teams can focus on authorization and access control, while IT architects and developers can focus on core API features.

Through centralized management and continuous evaluation of policy, you can have confidence that only the right users are accessing APIs, resources, and data.

API Access Management provides:

Centralized, user-friendly configuration that smooths over the complexities of working with OAuth across multiple systems, with a powerful policy engine behind the scenes.
Centralized visibility of API activity, including runtime auditing with a focus on authorization events.
Coarse-grained access control that ensures only the right users and clients access API services.
More granular access control for individual API operations, including group-based and scope-based features.
Fine-grained access control for API services and operations through custom dynamic authorization policies.
Advice statement processing for filtering and transformation of API request and response data.

API Access Management integrates with your API gateway to enforce access control policy on behalf of the API. Ping Identity provides integration kits for the following API gateways:

How API Access Management works

The following components are involved in API Access Management.

API Gateway: Your API gateway helps your organization manage the full lifecycle of APIs through design, development, testing, deployment, versioning, security, and analytics. In order to simplify authentication and authorization for the API services behind the API gateway, a Ping Identity integration kit installed in your API gateway connects to the HTTP Access Policy service inPingOne. Your API gateway acts as the policy enforcement point when policy decisions are provided by the HTTP Access Policy service at runtime.

To install the integration kit for your API gateway, see PingOne Authorize API gateway integrations.

To configure the connection between your API gateway andPingOne, see API gateways.
API service: API services are typically microservices and serverless functions developed by your organization to perform business or application functions. Access is routed through your API gateway to your API services. API gateways typically refer to API services as target APIs, upstream APIs, or backend APIs.

Using API Access Management, access control is managed centrally in PingOne Authorize, while enforcement is delegated to your API gateways. You can define operations with rules that control access to specific APIs within the API service.

To configure an API service and access control rules for a protected API, see API services.
HTTP Access Policy Service: This PingOne Authorize runtime service provides the authentication and authorization decisions to your API gateway. Policy decisions are determined by evaluating the access control rules configured within the API services in PingOne Authorize.

The following diagram shows how traffic flows through an API gateway, PingOne Authorize, and a protected API. Numbers in the diagram correspond to the steps that follow.

Diagram showing how traffic flows through an API gateway, PingOne Authorize, and a protected API.

The API Client makes a request to the API gateway.
The integration kit installed in the API gateway extracts fields from the API Client’s request and sends them to the HTTP Access Policy service in PingOne Authorize for authorization.
PingOne Authorize evaluates the request, validates the authorization, then responds to the API gateway. The response can be an authentication or authorization error that is sent back to the client immediately, or a modified request that the API gateway sends to the backend API.
If authorized to proceed, the API gateway passes the original or modified API request to the backend API.
The backend API responds to the API gateway with the requested resource or result of the operation.
The integration kit in the API gateway extracts fields from the backend API’s response and sends them to the HTTP Access Policy service in PingOne Authorize for processing.
PingOne Authorize responds to the processing request. The API response can be modified by authorization policy in PingOne Authorize.
The API gateway responds to the API Client with the original API response received from the backend API or the modified response received from PingOne Authorize.

Get started with PingOne Authorize

To set up PingOne Authorize in your PingOne environment, see Getting started with PingOne Authorize.

Use the tutorials to familiarize yourself with PingOne Authorize capabilities: