01
How SAML changes sign-in
The mechanism is the ordinary SAML one. Your service provider sends the user to SenseCrypt IdP, the check completes in the SenseCrypt Authenticator 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 another 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 can still end up with a sign-in that has no password in it.
Any conformant service provider works
The requirement is modest: import identity provider metadata and check a signature on an assertion. That covers commercial products, open-source stacks and the SAML module somebody added to an application a decade ago.
Every response carries an RSA signature
The signing certificate is in the published SenseCrypt IdP metadata, so your service provider anchors trust in a verification key instead of in a hostname it happens to recognize.
The face image stays off the network
On the two phone 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 or a template.
Send authorization values as attributes
Roles and permissions are computed in SenseCrypt IdP and released as assertion attributes. Your application enforces what it enforces now, reading the values from the same place.
02
Establish federation trust
SAML trust runs in both directions and is built from two documents. The SenseCrypt IdP file names the sign-on endpoint and carries the signing certificate. Yours supplies the entity ID and the assertion consumer service URL, the address an assertion is posted to. Each side loads the other, and from then on runtime reduces to one question: does this signature verify?
Implementations rarely fail at the identity provider. A service provider that accepts an unsigned assertion, skips the audience restriction or ignores the validity window is insecure whoever sits at the other end. The protocol puts that burden in your code.
Certificate rotation deserves a written procedure. Re-importing the published metadata is the safe path; hand-editing a certificate string into a configuration entry is how outages happen at renewal time.
The SenseCrypt IdP document
It names the single sign-on endpoint and carries the signing certificate. When the certificate rotates, import the fresh file instead of editing the stored value in place.
Your service provider metadata
SenseCrypt IdP has to learn where to post an assertion and which audience it should name. Both are in your service provider metadata, so register the SAML service provider from the file rather than transcribing values by hand.
Validate each SAML response
Reject replayed assertions, and check the recipient, the audience restriction, the validity window and the signature. A service provider that skips verification cancels the signing done on this side.
Pin the subject to something durable
Use a stable, opaque identifier rather than anything a person can edit, such as a display name or an address. Somebody who changes either should not reappear as a second account.
03
Integration steps
Downloading two files and importing them takes minutes. Spend the time saved on attribute mapping, because that is where a federation that 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.
- Download the SenseCrypt IdP SAML 2.0 metadata document.
- Load it into your service provider configuration.
- In the SenseCrypt IdP console, register a SAML service provider from your service provider metadata.
- Attach at least one SenseCrypt IdP group to the application; with none attached, nobody can sign in.
- Map the assertion attributes to your user profile, the 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 a password 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 for a small amount of configuration.
Be clear about the protocol itself. SAML 2.0 is a signed assertion traveling through a browser redirect. Nothing in it corresponds to PKCE or pushed authorization requests, and its safety depends on your service provider checking the assertion properly. SAML Single Logout is not supported; end the session on your side.
SAML 2.0 is here for the applications you inherited. Anywhere you own the application, use OpenID Connect.
05
SenseCrypt IdP at a glance
06
Frequently asked questions
How is trust established between the two sides?
Through a metadata exchange. The SenseCrypt IdP document carries the sign-on endpoint and the signing certificate; yours carries the entity ID and the assertion consumer service URL. Each file is 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. A correctly signed assertion means nothing if the receiving side does not verify it, and that half of the work lives in your code.
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 phone.
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 in SenseCrypt IdP.
Is Single Logout supported?
No. SenseCrypt IdP does not implement SAML Single Logout, so sign the user out on your side by clearing your own session. For applications that need provider logout, OpenID Connect offers RP-initiated logout.