Platform implementation

Ping Identity

We design Ping Identity deployments for complex federation, with PingFederate or PingOne brokering sign-in between several directories, partners and older web applications that cannot all move at once.

Open network rack with switches and neatly combed cables

Ping is usually chosen where identity has to bridge several worlds: more than one Active Directory after a merger, partner organisations, and older web applications that rely on HTTP headers. PingFederate can run in your own data centre while PingOne services run in the cloud, so hybrid hosting is a design choice, not a workaround. For banks and public bodies in the Middle East, that flexibility helps where staff access must stay separate from citizen or customer sign-in arrangements such as UAE PASS or Nafath.

We build the federation hub in PingFederate, with SAML and OpenID Connect connections per application and adapters for each authentication source. PingAccess protects web applications that cannot speak modern protocols, PingID or PingOne MFA adds the second factor, and PingOne DaVinci orchestrates multi-step flows such as step-up or account recovery without custom code. Configuration moves between environments through the PingFederate administrative API rather than manual console edits.

Ping Identity and related product names may be trademarks of their respective owners.

How we implement Ping Identity

Implementation, customisation, deployment and ongoing support, with governance your steering committee can follow.

  • Blueprint and governance

    The connection inventory, the attributes exchanged with each partner and application, and the plan for token signing and certificate rotation are agreed first, and the security office signs them off with the application owners.

  • Older web apps behind PingAccess

    Header-based and older web applications placed behind PingAccess, so they gain single sign-on and session control without code changes.

  • Partner federation

    SAML and OpenID Connect connections with partner organisations, each with its own agreed attributes, certificate expiry tracking and an incident contact.

  • Risk-based step-up

    Device, location and behaviour signals from PingOne Protect feeding step-up rules, so an extra factor is requested only when the risk score calls for it.

  • Hypercare and managed support

    PingFederate and PingAccess are versioned products you upgrade on your own schedule, while PingOne services update in the cloud, so we plan upgrades, renew signing certificates before they expire, and watch federation errors and authentication latency.

Is Ping Identity the fit?

Ping fits organisations with many federation partners, mixed hosting rules and legacy applications, often banks, telecoms operators and government, where a single cloud directory cannot cover every case.

  • An inventory of applications by protocol: SAML, OpenID Connect or header-based
  • A hosting position for PingFederate: your data centre or a private cloud
  • A partner list with technical contacts and certificate owners
  • Agreement on which flows move to PingOne DaVinci and which stay in PingFederate

Plan Ping Identity with Hosn Al Tomoh

Share your current systems, compliance themes and integration map. We will return a phased plan, a risk register and a governance model for your stakeholders to review.

Talk to our team