Skip to main content
This page covers the joint Silverfort integration specifically. Everything else in these docs is generic and true for any SAML service provider.

​
Where FaceSign sits

Silverfort already knows the workforce identity and has authenticated it. Its policy engine decides a particular action needs a step-up, and invokes Bridge. Bridge acts as the SAML service provider and sends the person to FaceSign.
1

Silverfort policy triggers a step-up

The person attempts a protected action. Silverfort already knows who they are.
2

Bridge sends an AuthnRequest to FaceSign

Bridge is the service provider. FaceSign is the identity provider.
3

The person completes a FaceSign verification

A short avatar-led session. This is all they see.
4

FaceSign returns signed SAML to the Bridge ACS

A pass carries the facesign.* attributes. Any other outcome is a signed, status-only refusal.
5

Silverfort validates and decides

Silverfort resumes, denies, or invokes its configured fallback. The access decision is Silverfort’s.

​
The boundary that matters most

FaceSign attests that a live, willing person is present. It does not attest that the person is the workforce identity Silverfort authenticated.
If Bridge injects its pre-authenticated user’s UPN as the <Subject> NameID, FaceSign echoes that value back — for an explicitly registered service provider only. The echo binds the assertion to the identity Silverfort supplied. It is not independent confirmation of it.Bridge must bind our response to its already-authenticated server-side user, and must not grant access from the returned NameID alone.
Subject echo is enabled only for Silverfort’s exact isolated, non-authorizing sandbox registration, once both sides have confirmed that boundary in writing.

​
What we need from Silverfort

​
string
required
Exact and case-sensitive, as Bridge sends it in <Issuer>.
​
string
required
HTTPS, POST binding.
​
string
required
What Bridge injects as the Subject, and in which format.
​
boolean
required
The most consequential answer. FaceSign does not support signed AuthnRequests in this release. If Bridge signs and cannot be configured otherwise, that changes the integration scope rather than a setting.
​
duration
required
Must exceed FaceSign’s five-minute authentication deadline, or we lower ours to sit inside yours. Minimum 60 seconds.
​
string
required
What Bridge does on deny, on timeout, and when the IdP is unavailable.

​
Joint acceptance test

The integration is established when a joint test demonstrates:
  • A real Bridge-initiated success, repeated across two people and two devices.
  • Both request bindings Bridge actually uses.
  • Subject echo returning the exact value injected, with format preserved.
  • Both signatures, Destination, Recipient, Audience and time conditions validated by Bridge.
  • An explicit denial, and Silverfort’s chosen fallback firing correctly.
  • Deadline behaviour on both sides.
  • A tampered response rejected.
Until that test has been run, FaceSign makes no claim about Bridge interoperability — the FaceSign side of the contract is validated and independently reproducible (Security and operations), and the joint behaviour is established together. Contact partnerships@facesign.ai.