Enabling SAML and Signing Users In
With the connection configured, enabling it puts SAML on the sign-in page. What follows is about the user experience and the first weeks.
Where to find it
Architect Panel → Integration & Connections:
- SAML Identity Providers — the connection
- SCIM User Provisioning — account lifecycle, which SAML does not do
Architect Panel → Security:
- Authentication Methods — which sign-in routes are enabled
What the user experiences
They choose the sign-in option, are sent to their own identity provider, authenticate there — with whatever it requires, including its own second factor — and are returned signed in.
The platform never sees their password, and their organisation's authentication policy applies without you implementing any of it.
Authentication is not provisioning
The distinction that catches people out. SAML signs people in; it does not create, update or deactivate accounts.
A leaver disabled at the identity provider can no longer sign in — which is most of what you wanted — but their account here, its groups and its record grants all remain. If you want the full lifecycle, that is SCIM provisioning, and it is a separate thing to set up.
Group mapping is a security boundary
Where directory groups drive platform access, somebody adding a colleague to a group at the identity provider grants access here — possibly without knowing that is what they are doing.
Keep the mapping small, explicit and written down, and review it when either side changes. This is the part of a SAML connection most likely to grant more than anybody intended.
Keep a local route in
If every administrator signs in through SAML and the identity provider is unavailable, nobody can get in to fix anything — turning somebody else's incident into yours.
Retain at least one local administrative account, protected by a passkey, and confirm it works by actually signing in with it rather than assuming.
Watch the first fortnight
Attribute mismatches, users with two identities, and people whose directory record is missing something all surface early. Check the error log and sign-in activity daily for the first couple of weeks rather than waiting to be told.
The two-identity problem
Somebody who previously signed in with a password and now arrives by SAML is two identities unless linked. The symptom is a user insisting they have an account while the system says otherwise, and it is the commonest report after go-live.
Decide how you will handle it before switching, not while people are queueing.
Sign-out is two things
Signing out of the platform does not necessarily sign somebody out of their identity provider, so clicking sign-in again may complete instantly and look as though sign-out failed. Set post-logout behaviour deliberately and be clear in your wording.
Worked example
An organisation enables SAML for staff, mapping two directory groups to two platform groups and nothing else. Two local administrator accounts with passkeys are retained and tested. In the first week, four users report having no account — all previously had password accounts, all resolved by linking, and the pattern was expected because it had been planned for.
Recommendations
- Add SCIM if you want leavers handled, not just sign-in.
- Keep group mapping small and reviewed.
- Retain and test a local administrator.
- Plan for the two-identity problem before switching.