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 always signed, 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, because end-user authentication keeps no identity provider side SSO session to propagate a logout from. 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, which matters less than it sounds: every interactive sign-in is already a fresh face ceremony, so there is no cached session for ForceAuthn to override.
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
One dollar per user each month at list, with a minimum of 20 seats. 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
Keeping a signing key in a managed key service runs to twenty dollars per key each month, and tenants and custom domains beyond the first three are ten dollars a month apiece.
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 in addition to the assertion |
| 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 in addition to the assertion
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 signed SAML assertion, indistinguishable in kind from one issued by any other identity provider. On the two mobile methods the capture, the liveness check and the comparison all happen inside the app on the enrolled phone; the enterprise webcam method captures at the workstation and is available to enterprise customers on a trusted network, contact sales@seventhsense.ai. Either way the assertion is the only thing the SP handles. This licensed on-premises method processes captures inside the customer deployment and does not add an enrolled-phone possession factor.
Is Single Logout supported?
No. Single Logout propagates the end of a shared identity provider session, and for end users no such session exists here, so the metadata advertises no logout service and inbound LogoutRequests are not handled. Ending the session your service provider created, in your own application, is the whole of signing somebody out.
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. Each sign-in it brokers then runs through the face ceremony before it completes.