01
What the service provider sees
Each tenant has a separate SAML identity provider, hostname, RSA-2048 signing key and self-signed certificate. IdP retains encrypted tenant signing keys and publishes SAML metadata and certificates for verification. SAML’s entityID is separate from the tenant’s OIDC issuer; OIDC uses ES256.
Connecting a service provider is a metadata exchange and an attribute decision. Point the SP at the metadata URL, or configure the entityID, the sign-on URL and the certificate by hand; register the assertion consumer service URLs it may use; map the attributes you want it to receive. There is no software to install on either side.
SP-initiated sign-on works over the HTTP-Redirect and HTTP-POST bindings. IdP-initiated sign-on is available per service provider and stays off until you enable it. The Response is always delivered to the consumer service over the HTTP-POST binding, as an auto-submitting form.
The ACS allow list is the SAML redirect URI
A requested assertion consumer service URL has to be on that service provider's registered list, and a mismatch is refused. When the AuthnRequest names no consumer service, the first registered one is used.
Request signature checking is opt-in, per SP
It is enforced once you register that provider's signing certificate, over the detached signature on the Redirect binding or the enveloped signature on POST. Verification pins to the configured certificate; a certificate embedded in the request is ignored.
Key rotation is make-before-break
A new certificate appears in the metadata before it starts signing, so a service provider that re-fetches metadata trusts assertions from either side of the switch. A staged certificate can also be downloaded to pre-configure an SP that cannot re-fetch on its own.
NameID has two shapes
Ask for the emailAddress format to receive the person's email. Any other format yields a stable, opaque per-tenant identifier rather than a database id. A policy demanding a format the SP is not configured for is rejected as an invalid NameID policy.
02
How the assertion is built
The assertion is signed by default, with RSA-SHA256, SHA-256 digests and exclusive canonicalization, and the outer Response is signed as well when the service provider asks for it. One invariant sits underneath that: a Response can never be wholly unsigned, so assertion signing is forced on whenever the Response is unsigned or the assertion is encrypted.
Assertion encryption is optional and switched on by registering the service provider's RSA encryption certificate. SenseCrypt signs first and then encrypts, with AES-256-CBC data encryption and RSA-OAEP key transport using SHA-256 and MGF1-SHA256; integrity comes from the enclosed signature. Note that this is CBC rather than GCM, and that an ECDSA certificate will not work.
Each assertion carries a bearer subject confirmation whose recipient is the consumer service, an audience restriction naming the SP entityID, and a validity window running from thirty seconds before issue to five minutes after it. The default authentication context asserts the biometric class and is overridable per service provider.
Attributes are released by scope, then renamed
A claim reaches the assertion only when a scope attached to that service provider releases it and the user has a value. The attribute map then renames released claims onto your SAML attribute names.
A mapping for an unreleased claim is inert
It is dropped silently rather than raising an error, which is the most common reason an expected attribute never arrives. Check the attached scopes first, and the map second.
NameFormat is configurable, and some platforms are fussy
Choose unspecified, basic or uri per deployment. Microsoft Entra ID expects the uri form, while unspecified omits the format attribute entirely. Multi-valued claims render as repeated attribute values.
Sign-in is gated the same way as OIDC
A service provider admits only members of the groups attached to it, and one with no attached groups admits nobody. The gate is re-run when the assertion is built, not only when the ceremony starts.
03
What this SAML deployment does not do
Two absences are worth knowing before you plan around them. There is no Single Logout: no logout service in the metadata and no logout request handling. Sign people out by clearing the session in your own application.
The HTTP-Artifact binding is not supported either. AuthnRequests arrive over Redirect or POST and Responses are delivered by POST. Request signature verification and assertion encryption both require RSA certificates from the service provider.
Only the Issuer, the request ID, the consumer service URL and the NameID policy format are read from an AuthnRequest. Extensions, ForceAuthn, IsPassive and RequestedAuthnContext are ignored; with session persistence turned off, every interactive sign-in is already a fresh face ceremony.
04
Running SAML alongside everything else
Very few organizations run one protocol, and that is the situation a standards provider exists for. One tenant signs assertions for the applications that need SAML, mints tokens for the ones that speak OIDC, and takes provisioning calls from your directory over SCIM, with a single enrollment underneath all three.
Order matters: provisioning first, sign-in second. SCIM lays down the account and the memberships that satisfy the gate, and the SAML flow then authenticates the person. With both running, access tracks your directory and nobody has to raise a ticket for it.
The 30-day trial needs no card, so a real service provider can be connected and tested before procurement has an opinion.
Seat pricing, and the floor under it
The list rate is $1/user/month, 20-seat minimum. In a consumer deployment the count is monthly actives, so the size of the account table does not set the bill.
Custody and tenancy are separate lines
A signing key held in a managed key service is $20/key/month. Three tenants and three custom domains are included; each additional tenant or custom domain is $10/month.
Move one service provider at a time
Nothing about a SAML estate has to change in one weekend. Repoint a single low-risk SP, run it beside the rest for as long as you want the evidence, and repoint the next when that one has proved itself.
05
Compare the details
| Setting | Effect |
|---|---|
| ACS allow list | The consumer service URLs an assertion may be sent to. A requested URL that is not on it is refused |
| SP signing certificate | When set, AuthnRequest signatures are verified against it. RSA only |
| Encryption certificate | When set, assertions are encrypted after signing. RSA only |
| Sign the assertion | On by default, and forced on whenever the Response is unsigned or the assertion is encrypted |
| Sign the Response | Signs the outer Response element; assertion signing follows the setting above |
| IdP-initiated sign-on | Permits a sign-in that starts at SenseCrypt rather than at the SP. Off unless enabled |
| NameID format | The default for this SP. emailAddress returns the email, anything else a stable opaque identifier |
| Attribute map | Renames released claims onto your SAML attribute names. It renames, it never releases |
| Attribute NameFormat | unspecified, basic or uri. Microsoft Entra ID expects uri |
| Authentication context | The context asserted in the assertion, biometric by default, overridable to any URI |
| Attached groups | The sign-in gate for this SP. Zero attached groups admits nobody |
| Attached scopes | Which claims may be released into the assertion at all |
ACS allow list
- Effect
- The consumer service URLs an assertion may be sent to. A requested URL that is not on it is refused
SP signing certificate
- Effect
- When set, AuthnRequest signatures are verified against it. RSA only
Encryption certificate
- Effect
- When set, assertions are encrypted after signing. RSA only
Sign the assertion
- Effect
- On by default, and forced on whenever the Response is unsigned or the assertion is encrypted
Sign the Response
- Effect
- Signs the outer Response element; assertion signing follows the setting above
IdP-initiated sign-on
- Effect
- Permits a sign-in that starts at SenseCrypt rather than at the SP. Off unless enabled
NameID format
- Effect
- The default for this SP. emailAddress returns the email, anything else a stable opaque identifier
Attribute map
- Effect
- Renames released claims onto your SAML attribute names. It renames, it never releases
Attribute NameFormat
- Effect
- unspecified, basic or uri. Microsoft Entra ID expects uri
Authentication context
- Effect
- The context asserted in the assertion, biometric by default, overridable to any URI
Attached groups
- Effect
- The sign-in gate for this SP. Zero attached groups admits nobody
Attached scopes
- Effect
- Which claims may be released into the assertion at all
06
Frequently asked questions
Does the service provider ever see biometric data?
No. What arrives at the service provider is a SAML assertion protected by a signature over the assertion, the Response or both, indistinguishable in kind from one issued by any other identity provider. On the two phone methods the capture, the liveness check and the comparison all happen inside the app on the enrolled phone; the deviceless webcam method captures at the workstation, inside the customer deployment, without adding an enrolled-phone possession factor; it is available to enterprise customers on secure terminals, because unsecured terminals expose webcam capture to injection attacks (contact sales@seventhsense.ai). Either way the assertion is the only thing the SP handles.
Is Single Logout supported?
No. The metadata advertises no logout service and inbound LogoutRequests are not handled. Sign somebody out by ending the session your service provider created, in your own application.
An attribute is not reaching our service provider. What is wrong?
Look at the scopes before the map. Release comes first and renaming comes second, so an attribute the attached scopes never let through cannot be recovered by naming it in the map, and a map entry pointing at a claim that was not released is discarded without an error to tell you so. Check that the SP has a scope carrying the claim, then check that the user actually has a value for it, then look at the map.
Can assertions be encrypted?
Yes, by registering the service provider's RSA encryption certificate. SenseCrypt signs the assertion and then encrypts it, with AES-256-CBC data encryption and RSA-OAEP key transport using SHA-256 and MGF1-SHA256. An ECDSA certificate is not supported.
How do we rotate the signing key without downtime?
The metadata publishes the new certificate before it starts signing, so a service provider that re-fetches metadata during the overlap trusts assertions from either key. For an SP that cannot re-fetch on its own, download the staged certificate and configure it ahead of activation.
Do we have to replace our current identity platform?
No. Keep it as the identity platform, with its directory, its policies and every application already federated to it, and add SenseCrypt behind it as an external identity provider over SAML 2.0 or OIDC. With session persistence turned off, each sign-in it brokers runs through the face ceremony before it completes.