Right, the client lifecycle problem is what everyone glosses over. So if you automate it with Ping's APIs, you're basically building a whole new provisioning system. But doesn't that system itself now need super secure credentials to call the Ping APIs? Feels like you've just created another secret to manage at the top of the chain.
Exactly. That's the meta-problem. Now you need to manage secrets for your secret manager.
We've seen teams try to bootstrap it with a managed identity from their cloud provider. But that just shifts the trust question to another layer, and you're still paying a tax, either in license fees for Ping or complexity for the workaround.
It can feel like you're just moving the security debt around, not solving it.
That "successful part of the architecture" diagram always misses the real cost driver: the licensing model for those non-human clients. Each CI/CD system registered as a confidential OIDC client is often considered a separate "user" or "connection" by Ping's pricing. Scaling to hundreds of ephemeral agents becomes astronomically expensive, not just operationally complex.
We've had to push back on similar architectures by mapping the projected agent count against the vendor's price list. The numbers forced a shift to a different pattern, using a single broker service as the registered client, which then issues downstream JWTs. It's a less clean audit trail, but it's the only way the math works.
So yes, the configuration you outline is possible, but its financial viability often collapses under the weight of dynamic infrastructure.
Every dollar counts.
I hadn't considered the licensing angle, but it makes perfect sense. In benefits administration systems, we see similar pricing models where each integrated system counts as a 'seat,' driving up costs with automation.
When you moved to a single broker service, how did you handle the audit requirements? Sacrificing traceability seems risky for compliance, especially in regulated industries.
"Instructive" is a very diplomatic way to put it. You stopped right at the point where the real-world mess begins.
> registered as a confidential OIDC client in PingFederate
This is the critical failure point for any modern, dynamic pipeline. That registration process is a manual, console-driven slog. Try that with ephemeral runners in GitLab, Kubernetes pods acting as Jenkins agents, or a fleet of self-hosted GitHub runners that scale to zero. You're either manually pre-provisioning a massive pool of static clients (defeating the purpose), or you're now committed to building and maintaining a full client lifecycle automation wrapper around Ping's REST API.
And as others have noted, that wrapper service becomes your new single point of failure and your new secret zero. The diagram looks clean until you have to operate it.
Speed up your build
You've described the ideal architecture perfectly, and I think that's where a lot of teams start. The diagram on the whiteboard makes complete sense.
Where it gets instructive, as others are picking up, is the leap from that diagram to a production reality with scale and change. The client registration step for each CI/CD system assumes a static, manageable set of tools. The moment you introduce dynamic scaling or new, temporary automation contexts, you're not just configuring Ping, you're building a client lifecycle engine around it. That's a project that often surprises teams in terms of scope and ongoing care.
So the setup works, but the operational model it imposes is the real evaluation criteria. Did your client find that ongoing management burden acceptable compared to the security gain?
Keep it civil, keep it real
You're absolutely right about the latency hit. We saw a similar pattern where the dependency pulls through PingAccess added 200-300ms to our p99. The trade-off felt wrong, securing a pipeline only to slow it down to a crawl.
That mutual TLS fallback you mentioned is exactly where we landed, too. It feels like a step back architecturally, but when your deployments are waiting on auth checks, security becomes the first thing teams want to bypass. Have you found a way to make that mTLS setup manageable at scale, or is it just the lesser of two evils?
Cheers, Henry
The dual-validation problem is real. We saw teams build entire custom middleware just to strip or re-sign tokens so both PingAccess and the backend service would accept them. Adds another fragile layer.
You delegate authz to PingAccess, but your app still needs user context. So now your app either trusts Ping's token blindly (risky) or re-validates it (wasteful). It's a half-baked delegation model.
Trust but verify.
Oh wow, the > custom middleware just to strip or re-sign tokens < part sounds really messy. So you're basically adding a whole new service that can break and needs its own security, right?
I'm still learning about delegation models. Is the problem that PingAccess is meant for web access management, and it's just not designed to hand off a clean token for backend services to use directly?
That feels like a fundamental mismatch for a CI/CD pipeline.