Zero Trust building blocks - F5 BIG-IP Access Policy Manager (APM) and PingIdentity

We started a discussion on Machine Identity and Zero Trust building blocks in Zero Trust building blocks - Machine Identity Management (MIM) and Workload Protection . In that article we talked about one of the main items on NIST ZTNA framework which is the presence of Policy Decision Point (PDP) and Policy Enforcement Point (PEP).

The way F5 as Full Proxy is installed allow to have flexible deployments with multiple components, at a point BIG-IP APM acts on its own as both PDP and PEP. Also, F5 APM can act as PEP and rely on different Identity Providers as a decision point (PDP).

In this article we are going to take a deeper look at BIG-IP integration with PingIdentity . where PingIdentity acts as the PDP and BIG-IP APM acts as PEP.

How F5 simplifies PingIdentity integration

F5 deployment guide presents two main use cases when intergating with PingIdentity,

• Horizontal Scaling and offloading PingAccess Agent functionality to BIG-IP APM.
• PingIdentity as Identity Provider and BIG-IP APM as Service Provider.

Horizontal Scaling and offloading PingAccess Agent functionality to BIG-IP APM

BIG-IP APM allows the distribution of application access requests to multiple PingAccess nodes depending on constraints and availability.

1. The client requests access to a protected resource.
2. BIG-IP APM built-in PingAccess agent functionality requests a decision from PingAccess policy server.
   
   
3. PingAccess checks the URL policy and determines that the requested resource is protected. It then responds to BIG-IP APM indicating that the user should be redirected to PingFederate for authentication.
   
   
4. BIG-IP APM redirects the user to PingFederate. After successful authentication, the user is redirected to BIG-IP APM with a PingFederate token.
   
   
5. BIG-IP APM passes the PingFederate token to PingAccess, which validates the PingFederate response and provides BIG-IP APM with the decision to allow or deny access to the resource.

The decision comes with an expiration and will be cached in BIG-IP APM which enforces the decision until its expiration.

PingIdentity as Identity Provider and BIG-IP APM as Service Provider

BIG-IP APM acts as Service provider and PingIdentity the Identity provider. BIG-IP APM gives support to modern and legacy authentication systems which allows for robust Single Sign-On (SSO) integration with on-premises and cloud-based identity providers and supports Virtual Desktop Infrastructure (VDI).

 

1. Build SAML trust between BIG-IP APM and PingFederate.
2. User requests access to the protected web resource through BIG-IP APM.
3. BIG-IP APM redirects user browser to PingFederate for Authentication.
4. User's browser is redirected back to BIG-IP APM with assertion response.
5. BIG-IP APM validates the assertion and allow access.
6. If SSO is used (for example Kerberos), BIG-IP APM use kerberos delegation with information obtained from sesssion's variables for SSO.
7. Once successfull, the user is allowed to access the protected resource.

 

Related Content

• BIG-IP APM and PingIdentity deployment guide.
• Configuring NGINX API micro-gateway to support Open Banking's Advanced FAPI security profile
• Integrating NGINX Controller API Management with PingFederate to secure financial services API transactions
• Zero Trust building blocks - Machine Identity Management (MIM) and Workload Protection