You built the dashboard, wired the metrics, and finally got your observability stack humming. Then the security team appears, asking who can see what. That’s when Lightstep Ping Identity earns its keep. It’s not magic, it’s just a smarter way to prove every request came from someone authorized to make it.
Lightstep focuses on performance visibility, tracing every service interaction down to the millisecond. Ping Identity handles the opposite side of the story — identity, authorization, and token security that feeds those logs only to the right people. Connecting them means your telemetry has context. A trace is never just data anymore, it’s data with a verified identity.
When Lightstep and Ping Identity integrate, each span inherits user identity metadata directly from the authentication layer. Trace events become identity-aware. This lets teams run queries filtered by who triggered what, not just when it happened. Access audits get radically simpler because the identity map lives inside your observability tool, not in a separate spreadsheet.
How the integration works
You link Lightstep’s access management to Ping through OIDC or SAML. Ping Identity supplies tokens that Lightstep trusts for role-based access. Those tokens define everything from who can view traces to who can configure collectors. The logic is plain: Token issued, verified, mapped to RBAC, enforced. Done.
A few best practices keep the setup clean. Match your service accounts in Ping to your Lightstep project roles. Rotate client secrets every ninety days like you would any endpoint credential. Audit permissions quarterly, especially if your org uses ephemeral workloads on AWS or GCP. If someone leaves, you remove their identity at the source, not in multiple dashboards.