On this page
What the SAML provider is
Plenty of business software speaks SAML 2.0 and will never be rewritten. SenseCrypt acts as the SAML identity provider for those applications. Your service provider trusts SenseCrypt, the user proves presence with a live face on a bound device, and a signed assertion comes back.
Nothing inside your service provider has to change. This is a metadata exchange, not a code project.
Standard metadata on both sides
You exchange SP and IdP metadata, map the attributes you need, and the connection is done. No proprietary SDK is involved.
The password leaves the SAML login too
Most SAML deployments still end at a password form. Here the assertion is issued only after a live face check on an enrolled device, so there is no form for a phishing page to imitate.
One IdP across many service providers
Every application you connect trusts the same identity provider. A user enrolls once, and each SAML application inherits that enrollment.
How SAML sign-in works
Your service provider redirects the user to SenseCrypt. The user completes the face ceremony on their enrolled device, where the capture and the match both run. SenseCrypt signs an assertion and posts it back. Your service provider validates the signature, then creates the session.
The attributes you release into that assertion are what places the user inside your application, so decide them before go-live rather than after.
The assertion is signed by SenseCrypt
Your service provider validates it against the IdP metadata you loaded, the same way it validates any other SAML identity provider.
Attributes carry the user's roles
Roles and permissions resolved at sign-in are released as attributes. Your application maps them onto its own model and enforces them there.
No image crosses the wire
The capture and the comparison stay on the handset. What reaches SenseCrypt is a single-use face token and a device-bound signature.
What comes with the assertion
SAML gives you the sign-in. The identity provider around it gives you what a SAML connector cannot: an access model, isolation between customers, and a record of administrative activity.
One point needs care, because SAML makes it easy to assume otherwise. SenseCrypt releases roles. It does not enforce your application's permissions.
Roles are released, not enforced for you
The assertion carries the user's roles and permissions. Your service provider decides what each one allows inside its own code.
The gates SenseCrypt does enforce
A default-closed group check at sign-in, so an unassigned user gets no assertion at all, and capability checks on every admin console route.
Tenants stay apart
Users, roles, and audit logs are scoped per tenant, so one customer's administrators never see another customer's directory.
How it fits the standard
A mixed estate is the normal case, and it is where one standards IdP pays for itself. The same service that issues SAML assertions to your older applications issues OIDC tokens to your newer ones and accepts SCIM calls from your directory.
These are the surfaces a SAML deployment can draw on.
- SAML 2.0 with signed assertions
- Standard IdP metadata for your service provider, and SP metadata import
- Attribute release, including roles and permissions
- SCIM 2.0 for provisioning and deactivation from your directory
- OIDC and OAuth 2.0 with PKCE and PAR for applications that prefer them
- CIBA for back-end services that need a person to approve
How to turn it on
Add your application as a SAML service provider, exchange metadata, and map attributes to roles. The 30-day trial takes no card, so you can prove the connection against a real service provider before you commit to anything.
Budget the seat rate and the line items that sit outside it.
One dollar per user per month, list price
A 20-seat minimum applies. Customer identity deployments bill monthly active users rather than every registered account.
Costs beyond the seat rate
Signing-key custody in KMS is twenty dollars per key per month, and each tenant or custom domain past the first three adds ten dollars per month.
Provision first, then sign in
SCIM creates and deactivates the accounts from your directory. SAML signs the user in. Run both and access follows your directory without a manual step.
Frequently asked questions
Is SenseCrypt a SAML 2.0 identity provider?
Yes. SenseCrypt acts as a SAML 2.0 identity provider (IdP). It sends signed SAML assertions to your app.
How do users sign in with SAML?
Users sign in by face. Face matching runs on-device. The sign-in is passwordless and phishing-resistant.
Does SenseCrypt support SCIM for provisioning?
Yes. SenseCrypt supports SCIM 2.0 for user provisioning. It also supports OIDC, OAuth 2.0, and CIBA.
Does the SAML provider give RBAC and audit logs?
Yes. SenseCrypt gives role-based access control (RBAC), multi-tenant isolation, and audit logs.
Related