Configuring SSO yourself, in three steps

SSO is configured from the application, by you, with no quote, no call and no ticket. SAML SSO is available from the Team plan, and SCIM on Business. If your plan does not allow it, the form says so and names the plan required.

Everything happens in Settings → SSO.

1. Declare us in your identity provider

The screen shows four values, each with its copy button. Enter them into your IdP:

• the Entity ID;
• the ACS URL, where the assertion comes back;
• the sign-out URL;
• the URL of our SP metadata, if your IdP would rather read them than have them typed.

2. Paste your metadata

Paste your IdP’s metadata XML into the screen’s single field. The certificate and the URLs are extracted from it: there is no field-by-field transcription, which is the first source of error.

When you leave the field, the document is inspected before anything is saved. The screen shows the provider it detected, the entry point and the certificate’s validity, and keeps the save button inactive while a blocking problem remains, naming what is missing.

An expired signing certificate is the most common defect in production, and the one whose raw SAML error never explains anything. The screen announces it here, with its date.

3. Prove your domain

Create the TXT record the screen shows in full:

_facteur-<providerId>.<your-domain>   TXT   _facteur-<providerId>=<token>

Then click the verify button, which runs the DNS resolution from our servers.

This step cannot be skipped, not even by us. Without it, anybody could claim a third party’s domain and capture its sign-ins.

Sign in, and check that it works

From the sign-in screen, the redirect happens by address domain: an address whose domain is verified and attached to a provider goes to your IdP.

At this point SSO adds itself to the other ways in. Your members can still use their password or Google. Test first, close the other doors afterwards.

Make SSO mandatory

The Require SSO button, at the bottom of Settings → SSO, makes the switch. It stays inactive until you have signed in yourself at least once through your identity provider, otherwise an incomplete configuration would shut you out of the very screen that undoes it.

Once it is on:

• your members only come in through your IdP, and sessions opened any other way are cut immediately;
• owners keep their password. That is your way out on the day your directory becomes unavailable. The trade-off is that your most powerful accounts are outside the rule;
• the other organizations your members belong to are not affected.

The same button reverses it, with no condition.

What changes for your members who also work elsewhere

A session opened by your identity provider reaches your organization, and only yours.

If one of your members also belongs to another Facteur organization, for instance a contractor working at one of your clients, that organization shows greyed out to them while they came in through your IdP. To go there, they sign back in through whatever that organization allows.

Your IdP decides who comes in at your place, so it only decides at your place. Without that limit, your directory’s administrator would gain, by opening a session in one of your employees’ name, the access that employee holds at a third party.

Two things do not change: nobody is ever locked in, leaving an organization stays possible from any session, and your members who belong only to your organization see no difference. See Several organizations.

Known limits

• No end-to-end sign-in test yet. The document inspection covers the common cases (incomplete file, expired certificate, wrong document pasted), but it does not prove that a real round trip with your IdP completes.
• The diagnosis of a rejected assertion is too thin. If an assertion is refused once the connection is live, the message stays generic where it should name the cause: signature, audience, or timestamp.