Configuring SSO yourself, in three steps

SSO is configured from the application, by you, with no quote, no call and no ticket. This is a deliberate position: at most competitors it sits behind a sales cycle, and every time a customer has to ask permission, there is a place to take.

Everything happens in Settings › SSO. The three steps map to the three questions that would otherwise produce an email thread.

1. Declare us in your identity provider

The screen shows, each with a copy button:

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

2. Paste your metadata

One field, where you paste your IdP’s metadata XML. The certificate and the URLs are extracted from it.

There is no field-by-field transcription, and that is the point: manual transcription is the first source of error, therefore the first source of tickets.

When you leave the field, the document is inspected before anything is saved. The screen shows the detected provider, the entry point and the certificate’s validity, and disables the save button while a blocking anomaly remains, saying precisely what is missing.

An expired signing certificate is the most frequent defect in production, and the one whose raw SAML error explains nothing. It is announced here, with its date.

3. Prove the domain

The TXT record to create is shown in full:

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

A button triggers DNS resolution from our servers.

This step cannot be bypassed, including by us. Without it, anybody could claim a third party’s domain and capture its sign-ins. It is not an administrative formality; it is what makes the mechanism safe.

4. Making it mandatory, once it works

Until you do something, SSO adds a way in rather than replacing the others: your members can still use their password or Google. That is deliberate — you configure, you test, and you close the other doors only once you have proof the new one works.

The « Exiger le SSO » button at the bottom of Settings › SSO makes that switch. It stays disabled until you yourself have signed in through your identity provider at least once: without that precaution, an incomplete configuration would shut you out of the very screen that undoes it.

Once it is on:

• your members come in through your IdP only, and sessions opened any other way are cut immediately — otherwise the door would be reported closed while people kept walking through it;
• owners keep their password. That is your way back in the day your directory becomes unavailable: without it, an outage on your side would become a ticket on ours. The trade-off is that your most powerful accounts are the ones the rule does not bind;
• the other organizations your members belong to are unaffected.

Turning it off again uses the same button, with no condition attached. We never lock the way out.

From which plan

SAML SSO is available from the Team plan, and SCIM on Business. If your organization’s plan does not allow it, the form says so and names the plan required, rather than failing without explanation.

Signing in afterwards

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

A sign-in through your IdP opens your organization only

Worth knowing before you turn SSO on: it changes something for 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 — a contractor at one of your clients, say — it will appear greyed out to them for as long as they came in through your IdP. To reach it, they sign in again the way that organization allows.

This is not a restriction we impose on you: it is the counterpart of what SSO gives you. Your IdP decides who comes into your organization, so it decides in yours alone. Without that limit, your directory’s administrator could open a session as one of your employees and obtain the accesses that employee holds at a third party.

Two things do not change: nobody is ever locked in — leaving an organization works from any session — and members who belong only to your organization see no difference.

See plusieurs-organisations.

Known limits

Both of these are real gaps, written here rather than discovered:

• No end-to-end connection test yet. Inspecting the document covers the frequent case — incomplete file, expired certificate, wrong document pasted — but it does not prove that a real round trip with your IdP succeeds.
• Diagnostics for a rejected assertion are too thin. Once the connection is live, a refused assertion produces a generic message where it should name what was wrong: signature, audience, timestamp.