01
How SAML changes sign-in
The mechanism is the ordinary SAML one. Your service provider sends the user to SenseCrypt, the check completes in the companion app on their enrolled phone, and a signed assertion is posted back naming that user. Your side verifies the signature and opens its session as it always did.
Where an application already consumes assertions from some other identity provider, the change amounts to swapping metadata and remapping attributes. No code is added and nothing is installed alongside it.
That is generally the reason to be reading this page. An application nobody intends to rewrite, because its authors have moved on or its vendor bills by the hour, can still end up with a sign in that has no password in it.
Any conformant service provider works
The requirement is modest: import IdP metadata, check a signature on an assertion. That covers commercial products, open-source stacks and the SAML module somebody bolted onto an application a decade ago.
Every assertion carries a signature
The signing certificate travels inside the published SenseCrypt metadata, so your service provider anchors trust in a verification key instead of in a hostname it happens to recognize.
The biometric stays off the network
On the two mobile app methods, the enrolled phone captures the image, tests liveness and performs the comparison. What travels to your service provider is an authentication statement, never an image and never a template.
Send authorization values as attributes
Roles and permissions are computed on the SenseCrypt side and released as assertion attributes. Your application enforces precisely what it enforces now, reading the values from the same place.
02
Establish federation trust
SAML trust runs in both directions and is assembled out of two documents. The SenseCrypt file names the sign-on endpoint and carries the certificate used to sign. Yours supplies the entity ID plus the assertion consumer service URL, the address an assertion gets posted to. Each side loads the other, and from then on runtime reduces to a single question: does this signature verify?
It is worth being blunt about where implementations fail, because it is rarely at the identity provider. A service provider that will accept an unsigned assertion, that does not enforce the audience restriction, or that ignores the validity window is insecure whoever sits on the other end of the connection. The protocol puts that burden in your code.
Certificate rotation deserves a written procedure rather than a calendar reminder. Re-importing the published metadata document is the safe path; hand-editing a certificate string into a configuration entry is how outages happen at renewal time.
The SenseCrypt document
It names the single sign-on endpoint and carries the signing certificate. Pull it once into the service provider configuration, and when the certificate rotates, import the fresh file instead of editing the stored value in place.
Your service provider metadata
SenseCrypt has to learn where an assertion should be posted, and which audience the assertion itself should name. Both live in your service provider metadata, so send the file rather than transcribing values into a form where one mistyped character costs an afternoon.
Validate each SAML response
Reject replayed assertions, and check the recipient, the audience restriction, the validity window and the signature. Signing is done correctly on this side; a service provider that skips verification cancels that work entirely.
Pin the subject to something durable
Use a stable, opaque identifier in place of anything a person can edit, a display name or an address included. Somebody who changes either should not reappear as a second account with none of their history attached.
03
Integration steps
Downloading two files and importing them takes minutes. Spend the time saved on attribute mapping, because that is where a federation which works technically still hands your application a user it cannot place.
Leave the existing login path in service until one real person has completed a sign in on a real handset. Then read the account record your application created for them, rather than settling for the fact that the redirect completed.
- Fetch the SenseCrypt SAML 2.0 metadata document.
- Load it into your service provider configuration.
- Return your own service provider metadata to SenseCrypt.
- Bind the assertion attributes to your user profile, roles attribute included.
- Confirm your validation covers signature, audience and validity window.
- Enroll one test user, then run a face sign in from start to finish.
04
SAML capabilities and limits
The application keeps the integration it already has, and the user stops holding something that can be phished, reused or dictated over the telephone. For an estate with a long tail of older applications, that is a large change bought with a small amount of configuration.
Be clear-eyed about the protocol itself. SAML 2.0 amounts to a signed assertion travelling through a browser redirect. Nothing in it corresponds to PKCE or to pushed authorization requests, and its safety depends on your service provider checking the assertion properly, which leaves more of the work in your code than a current OIDC library would.
SAML 2.0 exists here for the applications you inherited, and not because it is the stronger protocol for anything being built now. Anywhere you own the application, wire it over OpenID Connect.
No shared secret at sign-in
The flow carries no shared secret, so a page copying yours has nothing to collect and a caller impersonating support has nothing to ask for.
Biometric-free disposable face tokens
IdP retains quantum-safe, sealed, biometric-free, disposable face tokens and their verifier challenges. Standard OIDC/SAML account records, device public keys, sessions, logs and encrypted tenant signing keys also persist. No face images or templates are retained in the documented phone flow. Licensed on-premises Webcam processes captures inside the customer deployment. Being biometric-blind means a breach, a subpoena and a later migration all find the same thing: no gallery.
The rest of the platform is included
Multi-tenant isolation, role-based access control and SCIM 2.0 provisioning come with the SAML connection instead of sitting in a higher tier. Administrative actions are written to a hash-chained, tamper-evident log, while end-user sign-ins are recorded separately as a read-only activity stream.
Pricing details
Seats list at one dollar per user each month, with a minimum of 20. A signing key held non-exportably in a managed key service adds twenty dollars a month. Tenants and custom domains are free up to three, then ten dollars a month each. The 30-day trial needs no card.
05
Frequently asked questions
How is trust established between the two sides?
Through a metadata exchange. The SenseCrypt document carries the sign-on endpoint and the certificate used for signing; yours carries the entity ID together with the assertion consumer service URL. Both files are imported on the opposite side, after which every assertion is signed with the key your service provider checks against.
What must our service provider validate?
Four checks and one rejection rule: the signature, the recipient, the audience restriction and the validity window, plus refusal of any assertion already seen. Those checks are the security of SAML 2.0. A correctly signed assertion means nothing where the receiving side declines to verify it, and that half of the work lives in your code rather than in ours.
Should we use SAML 2.0 or OpenID Connect?
SAML 2.0 for applications that already speak it and are not going to change. OpenID Connect for anything you control, because discovery, PKCE and pushed authorization requests remove classes of mistake that SAML leaves to your implementation. Both paths run the same face ceremony on the user's device.
Can we use SAML for sign in and SCIM for provisioning together?
Yes, and that is the usual arrangement. SAML 2.0 handles the authentication event while SCIM 2.0 (RFC 7644) keeps users and groups in step, so an account closed in your source of truth does not linger inside the application.
What runs on the phone, and what is kept on the server?
On the two mobile app methods, liveness and the comparison both happen on the phone the user enrolled. IdP retains quantum-safe, sealed, biometric-free, disposable face tokens and their verifier challenges. Standard OIDC/SAML account records, device public keys, sessions, logs and encrypted tenant signing keys also persist. No face images or templates are retained in the documented phone flow. Licensed on-premises Webcam processes captures inside the customer deployment. A webcam method is offered to enterprise customers on a trusted customer network; contact sales@seventhsense.ai.
What if a user loses their enrolled phone?
A new device is bound behind a possession proof: a one-time PIN by email, an SMS where a number is recorded against the account, or the CIBA email-possession check. Neither self-service face recovery nor a password fallback exists, so the service desk procedure belongs in the plan alongside the federation itself. The replacement must also prove a new device key; the account remains bound to the enrolled person through biometric-free, disposable face tokens, and the live face check is still required at sign-in.