> ## Documentation Index
> Fetch the complete documentation index at: https://idp-docs.facesign.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Silverfort Bridge pilot

> Partner-specific onboarding for the Silverfort Bridge integration, kept separate from the generic SAML documentation.

<Note>
  This page covers the joint Silverfort integration specifically. Everything else in these docs is
  generic and true for any SAML service provider.
</Note>

## 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.

<Steps>
  <Step title="Silverfort policy triggers a step-up">
    The person attempts a protected action. Silverfort already knows who they are.
  </Step>

  <Step title="Bridge sends an AuthnRequest to FaceSign">
    Bridge is the service provider. FaceSign is the identity provider.
  </Step>

  <Step title="The person completes a FaceSign verification">
    A short avatar-led session. This is all they see.
  </Step>

  <Step title="FaceSign returns signed SAML to the Bridge ACS">
    A pass carries the `facesign.*` attributes. Any other outcome is a signed, status-only refusal.
  </Step>

  <Step title="Silverfort validates and decides">
    Silverfort resumes, denies, or invokes its configured fallback. The access decision is
    Silverfort's.
  </Step>
</Steps>

## 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.

<Warning>
  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.
</Warning>

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

<ParamField path="entityID" type="string" required>
  Exact and case-sensitive, as Bridge sends it in `<Issuer>`.
</ParamField>

<ParamField path="ACS URL" type="string" required>
  HTTPS, POST binding.
</ParamField>

<ParamField path="NameID format and value" type="string" required>
  What Bridge injects as the Subject, and in which format.
</ParamField>

<ParamField path="Does Bridge sign its AuthnRequests?" type="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.
</ParamField>

<ParamField path="Bridge timeout" type="duration" required>
  Must exceed FaceSign's five-minute authentication deadline, or we lower ours to sit inside
  yours. Minimum 60 seconds.
</ParamField>

<ParamField path="Fallback behaviour" type="string" required>
  What Bridge does on deny, on timeout, and when the IdP is unavailable.
</ParamField>

## 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](/security-and-operations)), and the joint behaviour is established
together.

Contact [partnerships@facesign.ai](mailto:partnerships@facesign.ai?subject=Silverfort%20Bridge%20pilot).
