On this page
What this integration does
SenseCrypt is the SAML 2.0 identity provider and your application is the service provider. The application redirects a user to SenseCrypt, the face ceremony runs on the user's own device, and SenseCrypt posts back a signed assertion naming the enrolled user. Your service provider validates the signature and starts its session.
If your application already accepts assertions from another IdP, this is a metadata swap and an attribute mapping. Nothing is installed.
Your SP configuration stays standard
Any service provider that can import IdP metadata and validate a signed assertion can use SenseCrypt. No library, package or agent is added on your side.
SenseCrypt signs every assertion
The signing certificate is published in the SenseCrypt metadata, so your service provider pins trust to a key rather than to a hostname.
The face check happens off the wire
Capture and matching run on the user's enrolled device. A single-use face token is what moves, and the server keeps no face image and no face template.
Attributes carry the roles
SenseCrypt computes roles and permissions and releases them as assertion attributes. Your application enforces what they allow.
How the two sides come to trust each other
SAML trust is mutual and it is built from two files. SenseCrypt publishes IdP metadata with the single sign-on URL and the signing certificate. Your service provider publishes its own with the entity ID and the assertion consumer service URL. Each side imports the other, and at runtime the only thing that matters is whether a signature verifies.
That last part is where implementations go wrong. A service provider that accepts an unsigned assertion, or skips the audience check, is insecure no matter which IdP is on the other end.
SenseCrypt metadata: SSO URL and certificate
Download it once and import it into your service provider. When the signing certificate rotates, re-import the file rather than hand-editing a configuration entry.
Your metadata: entity ID and ACS URL
SenseCrypt needs to know where to post the assertion and which audience to name inside it. Send the file instead of transcribing values into a form.
Validate properly on your side
Check the signature, the audience restriction, the recipient and the assertion lifetime. SenseCrypt signs correctly, and a service provider that does not verify undoes that work.
Pick a subject identifier that will not move
Map to something stable rather than to an email address or a display name. A user who changes either one should not turn into a second account.
Setup steps
The exchange itself is two downloads and two imports. Spend the time on attribute mapping instead, because that is where a working federation still produces a user your application cannot place.
Keep your current login path enabled until one real user has signed in with a real phone.
- Download the SenseCrypt SAML 2.0 metadata file.
- Import it into your service provider.
- Send your service provider metadata to SenseCrypt.
- Map the SAML attributes onto your user profile, including the roles attribute.
- Enroll a test user and complete one face sign in end to end.
What you get
An old SAML application gains a modern sign in without a rewrite, which is usually why this page is open. The user stops holding a secret that can be phished, and your application keeps the integration it already has.
Be clear-eyed about what SAML itself contributes, though. The protocol is a signed assertion carried over a browser redirect, and its safety rests on your service provider validating that assertion correctly.
No password, no shared code
There is nothing at sign in for a fake page to collect. The face token is spent on use, so replaying a captured copy achieves nothing.
No face gallery to breach
The server keeps no face image and no face template, so there is nothing to hand over in a breach, a subpoena or a later migration.
The platform comes with it
Role-based access control, multi-tenant isolation, audit logs and SCIM 2.0 provisioning sit alongside the SAML federation rather than in a higher tier.
What it costs
One dollar per user per month with a 20-seat minimum. KMS signing-key custody is twenty dollars per key per month, and each tenant or custom domain past the first three is ten dollars per month. The 30-day trial takes no card.
Frequently asked questions
Does SenseCrypt need a proprietary SAML connector?
No. SenseCrypt uses standard SAML 2.0. Both sides exchange metadata files. This is standards-based federation.
How do both sides establish trust?
Each side imports the other metadata file. The metadata carries the signing certificate. SenseCrypt signs every SAML assertion.
Where does the face match run?
The face match runs on-device. SenseCrypt keeps no face image and no face template on the server. It uses patent-pending face tokenization.
Can SenseCrypt provision users too?
Yes. SenseCrypt supports SCIM 2.0 for user provisioning. It also supports OIDC, OAuth 2.0, and CIBA.
Related