API Security leveraging Ping Access

API Security leveraging Ping Access

With Ping Access, you can use one access management product to protect both your web and API resources—and easily apply policies to both. Let’s see below how API security leveraging Ping Access.
Ping Access protects Web and APIs as show in the figure below by applying security policies to client requests to determine if access is allowed. Requests are routed through Ping Access Gateway to the target Site. Policies specified for the target Application are evaluated and Ping Access grants or denies access. When access is granted, the client request can be modified to provide additional identity information as needed by the target Application.

Ping Access Basic Concepts
Sites represent applications and APIs running on Web servers or ESBs to be protected by Ping Access. They are defined by host and port settings to which Ping Access will forward authorized client requests.
Ping Access Gateway It intercepts requests and communicate with the Ping Access Policy engine to deny or grant access to protected APIs.
Applications represent applications and APIs which clients need to access securely and specify the information needed to protect them. Applications are composed of resources which have distinct access control requirements. Access rules can be applied to applications and their resources for greater flexibility.
Policies are rules applied to applications and resources and determine if access is allowed. Rules are evaluated in the context of the client’s identity and request characteristics.

There are many options for deploying Ping Access in your network environment:
• deployment that supports mobile and API access management
• deployment that supports Web access management
• deployment that supports auditing and proxying
• stand-alone deployment
• deploy multiple Ping Access servers in a cluster configuration for high availability, server redundancy, and fail over recovery.

Below are various zones for a DMZ deployment that supports mobile, web and API access management.
External Zone: External network where incoming API requests originate.
DMZ Zone: Externally exposing segment where Ping Access is accessible to API clients. Ping Access is a standalone instance in this environment, serving as both a run time and an administrative port.
Protected Zone: Back-end controlled zone in which Sites hosting the protected APIs are located. All requests to these APIs must be designed to pass through Ping Access.

various zones for a DMZ deployment that ultimately helps in API security leveraging Ping Access

Key functionalities that needs to be considered for Web and API Security

Authentication (Basic Http Auth)

• Ensure that users are logged in with an appropriate authentication level that enables access to an application, and perform step-up authentication if the current level is too weak.

• Ping Access supports a variety of Site authenticator that range from basic username/password authentication to certificate and token-based authentication. Create a Site Authenticator for the type of authentication the Site requires.

• Standards centric: Ping Access is designed to embrace standards and reduce the risk of vendor lock-in. Ping Access uses a JSON Web Token (JWT) to maintain session information and OpenID Connect to facilitate user authentication.

• Site Authenticator: Through creation of a Site Authenticator for the type of authentication the Site requires that can include:
– Basic Authentication Site Authenticator
– Mutual TLS Site Authenticator
– Token Mediator Site Authenticator


• Policy-based URL Access Management: Apply access policies at the URL level with an extensible rules engine to dictate who can access which applications under what criteria.

• Easily apply access control rules to both web and API resources.

• Avoiding Vendor Lock-in: Ping Access and harness the open standards (JSON Web Token) for session management in order to protect from vendor lock-in and speed application integration.

• Scalability: Scalable and Ready for the Cloud. The Ping Access gateway handles tens of thousands of transactions per second with advanced clustering and replication. Ping Access supports industry standard operating systems deployed on hardware, virtual machines or in the cloud. Advanced caching reduces back-channel network traffic and accelerates access control within your applications.

• The Policy Manager is a rich drag-and-drop interface where you can manage API security policies by creating Rules.
Rules: They can restrict access in a number of ways such as testing user attributes, time of day, request IP addresses, or OAuth access token
scopes. Rules can also perform request processing such as modifying headers or rewriting URLs.

• Rules types: (Access Control Rules, Groovy Script Rule, HTTP Request Rule, Network Range Rule, OAuth Attribute Value Rule, OAuth Groovy Script Rule, OAuth Scope Rule, Time Range Rule, Web Session Attribute Rule, Processing Rules, Rewrite Cookie Domain Rule, Rewrite Cookie Path Rule, Rewrite Response Header Rule, Rewrite URL Rule)

SSL Requests handling (offloading if required)

• Out of the box feature of Ping Access. Ping Access can accept secure requests from external resources and route them to API or non-SSL application endpoints (residing behind the network firewall).

Headers / Attributes validation
• Can be accomplished through Policy Manager, Rules & Groovy Scripting

IP filtering
• Can be accomplished easily by Network Ranging in Policy Manager


• With growing numbers of internal and external users, it is important to know which users are accessing applications, from where and when they are accessing them, and ensuring that they are correctly accessing only those applications to which they have permission. A standardized auditing/proxying deployment provides a centrally controlled model that ensures existing infrastructure and security policies are followed, thereby safeguarding an organization’s assets.

• Receives inbound calls requesting access to protected back-end Sites. Audits the request and then makes authorized requests to the back-end Sites.

• Receives and processes responses and relays them on to the client.

• Audit results are sent to an audit repository or digested by reporting tools. Many types of audit repository/tools are supported such as SIEM/GRC, Splunk, database, and flat files.

Fail over recovery

• For high availability and redundancy, the environment requires clustering and load-balancing. Load balancers are required as part of the networking infrastructure to achieve high availability by ensuring that requests are sent to available servers they are front-ending.

More information can be found here https://www.pingidentity.com/en/platform/access-security.html