Federate SenseCrypt IdP with Ping Identity

Ping stays in the middle of the estate. Your service providers keep pointing at Ping, Ping keeps minting the sessions they read, and the connections, policies and reporting accumulated there are left alone. SenseCrypt IdP joins at the top of that chain as an upstream identity provider.

What SenseCrypt IdP takes on is the proof. On the phone methods the user faces the camera on the phone enrolled to them, liveness and matching complete there, and Ping receives a signed token or assertion to map onto the record it already keeps. Upstream federation over OpenID Connect and SAML 2.0 is standard Ping functionality. There is no pre-built connector. Federation is standard OIDC or SAML 2.0 configuration on both sides.

Those connections are configured one at a time, so a single application or a single population can be moved and watched before anything else is touched.

Trust needs two things from the SenseCrypt IdP side: somewhere to send the user, and a way to check that the answer is authentic. Both are published documents, so nothing secret travels between administrators and no certificate is pasted into an email.

The rest of the effort is claim mapping. Ping builds its own user record and session from the attributes you send. An identifier that shifts when somebody updates an email address becomes account drift, usually discovered months later during an audit.

Everything here happens in two administration consoles, which keeps the project's risk in configuration rather than infrastructure, and configuration can be reversed the same afternoon.

Run the first sign-in on a real handset using a test identity, then inspect the record Ping wrote for that user. Mapping errors appear at exactly that point, and one account is a far cheaper place to find them than four hundred.

1. Choose the protocol for the upstream link: OpenID Connect or SAML 2.0.
2. In the SenseCrypt IdP console, register Ping as an OIDC application (or as a SAML service provider).
3. Attach at least one SenseCrypt IdP group to the application; with none attached, nobody can sign in.
4. In the Ping console, add SenseCrypt IdP as an external identity provider.
5. Give Ping the discovery URL for OIDC, or the metadata file for SAML 2.0.
6. Map the claims to your Ping directory attributes.
7. Attach the new provider to one connection or one population, not to everything.
8. Enroll a test identity, sign in by face, then read back the record Ping created.

Policies, connections and reporting survive intact, while the front of the flow loses its password. The decision's blast radius is one connection.

It also puts attention on the part of the lifecycle attackers use. In the 2023 MGM Resorts incident, attackers phoned the IT help desk, impersonated an employee, and the company reported an impact of about $100 million. Hardening the front door while leaving account recovery to a persuasive phone call relocates the attack rather than removing it.

SenseCrypt IdP is deliberate about that path. There is no self-service face recovery. A lost phone is replaced through a verified contact (a one-time PIN by email, with SMS where a number is on file) and a new device key. The face is not re-registered, and the live face check is still required at sign-in. Your service desk still needs a documented way to be certain who is on the line.