Ping Identity vs ClavionX: What Twenty Years of Federation Buys You

Somewhere in a large enterprise there's a SAML service provider that went live around 2010. It sends AuthnRequests that aren't signed. It expects a NameID format nobody else uses. It can't handle an assertion whose signature covers the Response rather than the Assertion, and the vendor that built it no longer exists. It processes payroll, so it isn't going away.

In a PingFederate admin console, there's usually a setting that makes this work.

That setting is the most important thing to understand about Ping. Every configuration option in a mature federation server is a fossilized incident. Somebody, somewhere, had an outage or a failed integration, and the fix became a checkbox. Twenty years of those checkboxes is a genuinely valuable asset. It's also a genuinely heavy one. This post is about both, and about what a platform that chose to have fewer checkboxes gives up.

Disclosure: I work on ClavionX. Ping serves some of the largest and most regulated identity estates in the world, and for many of them it's the right choice. I've tried to be specific about which.

What Ping actually is

Ping Identity was founded in 2002. Its first product, PingFederate, became one of the defining enterprise federation servers of the SAML era. It's self-managed Java software that sits between an enterprise's directories and every application it has ever bought.

Since then, Ping has become a portfolio. Thoma Bravo took it private in 2022 and merged it with ForgeRock in August 2023. ForgeRock Identity Cloud became PingOne Advanced Identity Cloud. Earlier, in 2021, Ping had acquired Singular Key, whose no-code orchestration product became PingOne DaVinci. Alongside those sit the PingOne cloud services for MFA, risk, identity verification and authorization, plus the directory and access-management lineages from both companies.

That history matters architecturally, because it means "Ping" isn't a single engine. Depending on what you buy, a login may be governed by PingFederate authentication policies, by ForgeRock-lineage journeys built from nodes, or by a DaVinci flow drawn on a canvas. Ping is consolidating these. Anyone evaluating Ping should still ask early and plainly: for my use case, which engine runs the login, and which will in three years?

Configuration as accumulated knowledge

The argument for a federation server with a vast configuration surface is stronger than it first looks.

Identity federation is a protocol domain in which the other party is frequently wrong. Service providers mis-implement signature validation. IdPs emit clock-skewed assertions. Enterprise customers arrive with certificates in formats the spec never anticipated. Debugging SAML: A Field Guide catalogs the common ways this goes wrong. A platform that has seen more integrations has more of those failures pre-solved.

When you have four hundred legacy SAML applications, you aren't buying elegance. You're buying the probability that application #317 works on the first attempt. PingFederate's decades of deployments raise that probability in a way no amount of clean architecture can.

The cost of every knob

The same accumulation has a cost, and it's the mirror image of the one that extension points impose.

A configuration option is also a permanent public API. Once a customer has set it, the vendor has to keep honoring it indefinitely, in every future version, in combination with every other option. The state space grows combinatorially. The practical consequence for the customer is subtler and gets discussed less often:

Nobody on your team knows which settings are load-bearing.

The person who configured the payroll connection left in 2017. The setting that disables signature validation on one SP connection was a temporary workaround during a certificate rotation, and nobody wrote down that it was temporary. A security review finds it three years later. Changing it might break payroll, and there's no test that would tell you. So it stays.

This is the operational tax of a rich configuration surface. It isn't a flaw in Ping. It's what configuration becomes after a decade in an enterprise. The mitigation is the same as for code: configuration in version control, export and diff on every change, a named owner per connection, and a periodic review asking which settings are still justified. Teams that do this run Ping well. Teams that treat the admin console as the source of truth eventually can't answer what their federation server does.

ClavionX takes a much narrower position. It has far fewer options, and it makes security-relevant properties canonical so a tenant can't loosen them. Redirect URIs, grant types, PKCE requirements and token policy are fixed on the application definition. SAML setup is metadata-first: paste the partner's metadata, the platform analyzes it, and Test Connection runs before activation. The idea is that the wizard handles the common cases correctly and the unusual cases get a conversation rather than a checkbox.

That's precisely the wrong trade for application #317. If your estate is full of partners who need the checkbox, a platform built around saying no to the checkbox will cost you time you don't have.

Orchestration as a product

DaVinci is where Ping's philosophy and ClavionX's diverge most sharply, and it deserves a fair hearing.

DaVinci models the login as a visual workflow. The canvas holds nodes for your IdP, for identity verification vendors, for fraud and risk services and for your own APIs, connected by branches. A product team can add document verification to account opening without a code change. The ForgeRock lineage offers a similar model with journeys and nodes, including scripted decision nodes for custom logic.

For some problems this is exactly right. Consumer onboarding in a regulated industry really is a workflow. It involves collecting an identity document, running a liveness check, screening against sanctions lists, scoring fraud risk and choosing a path based on the result. Those steps touch external vendors by nature, and the workflow changes when compliance says so. Putting that workflow in a canvas that the business can see and change is a genuine improvement over the same logic scattered across services.

The cost is that the login path is now a distributed system, drawn in a canvas:

flowchart LR
    L["Login"] --> IdP["Credential check"]
    IdP --> R{"Risk score<br/>(external)"}
    R -- low --> T["Tokens"]
    R -- medium --> MFA["MFA"] --> T
    R -- high --> V["Document verification<br/>(external)"]
    V --> S["Sanctions screen<br/>(external)"] --> T

Every external node brings its own availability, latency tail and failure mode, and each one needs a decision about what happens when it doesn't answer. The canvas makes the flow visible. It doesn't make it reliable. That's the argument in Why Identity Systems Fail Gradually, Then All at Once, and orchestration makes it easier to walk into, precisely because adding a node is so easy.

ClavionX's position is that onboarding workflows like this belong beside the identity runtime, not in it. The workflow decides; identity records the outcome as an attribute, and the login reads local state. Identity Isn't Your Integration Layer makes the full case. It's a defensible position, but it has a real cost: someone has to build and run the workflow system that Ping would have given you.

Deployment: one of the few who still ship software

A quieter strength of Ping is that it still sells serious self-managed software. PingFederate and the ForgeRock platform run in your own data centers, including in environments that can't reach a SaaS control plane. For defense, critical infrastructure, some public-sector work and some banks, that's a hard requirement, and few vendors of Ping's scale still meet it well.

ClavionX is also self-hostable, using Helm charts with bring-your-own Postgres, Redis and Kafka, and deployment profiles sized from small to large. Being deployable isn't the same as having years of air-gapped operational history, though. Some parts of that story, such as backup and disaster-recovery drills, are still being completed. A buyer who needs on-premises identity for a regulated estate should weigh a vendor's track record of running there, not just whether a chart exists.

Where ClavionX is simply younger

The honest list for a Ping evaluation:

• SAML. ClavionX acts as a SAML identity provider, handling SP- and IdP-initiated sign-in with managed certificate rotation. It also acts as a service provider, with metadata-driven setup, single logout and encrypted assertions. Its own documentation is candid about gaps. For example, as an identity provider it doesn't yet verify signatures on inbound AuthnRequests, even when a service provider is configured to sign them. Ping has handled both sides, and their edge cases, for two decades across a far larger range of partners.
• Adaptive access. ClavionX's network access policies and adaptive MFA are planned rather than built. PingOne Protect and the ForgeRock risk nodes exist today.
• Governance and verification. Identity governance, identity verification and fine-grained authorization are products in Ping's portfolio. ClavionX doesn't offer them.
• Delegation. RFC 8693 token exchange and ClavionX's agent identity model are planned or in design.

What ClavionX does have is a narrow, uniform runtime. That includes strict separation between control plane and runtime, per-tenant issuers and signing keys, a login path without customer code, and OIDC behavior that passes the OpenID Foundation's Basic OP conformance tests. Those are real properties. They also make up a much smaller product than a portfolio.

When Ping is the better choice

Pick Ping when:

• You have a large estate of legacy federation partners and application #317 has to work this quarter.
• Your login really is a workflow involving identity proofing, fraud, sanctions and compliance-driven branching, and you want the business to own it visually.
• You need governance, verification and access management from one vendor, and your procurement values consolidation.
• You need self-managed software with a long record in regulated or disconnected environments.
• The organization's risk model favors a large, established vendor, which is a legitimate factor, not a cop-out.

ClavionX fits better when the estate is newer and mostly OIDC. It also fits when you're building a multi-tenant product rather than federating an enterprise, when a login that depends on nothing external matters more than one that can call anything, and when you'd rather have a smaller configuration surface your team fully understands than a larger one it has inherited.

The actual difference

Ping sells the accumulated answers to twenty years of federation questions, and increasingly the canvas on which to compose them. ClavionX sells a smaller set of answers that it can guarantee, and asks you to put the workflow somewhere other than the login.

If you have the old SAML application from the opening, you already know which one you need. The harder cases are the teams that don't have it yet and are choosing between being ready for it and being free of it.

Vendor details are from Ping Identity's public materials and product documentation as of September 2026; Ping's portfolio is actively being consolidated, so verify current product names and capabilities. ClavionX capability status is taken from its public docs and feature matrix. I work on ClavionX.