SAML Authentication
SAML 2.0 single sign-on lets your team sign in to sfp with your corporate identity provider — Microsoft Entra ID, Okta, Google Workspace, OneLogin, PingIdentity, and similar.
This area of the docs covers everything you need:
Configure your IdP. Same steps for self-hosted and cloud deployments — only the URLs differ.
Wire the IdP into a deployment you run yourself (sfp server init).
Wire the IdP into a flxbl-managed cloud deployment.
Common errors and how to fix them.
Which deployment mode am I in?
Run this against your sfp server to find out:
curl https://<your-domain>/sfp/api/configIf you provisioned the server with sfp server init, you are self-hosted.
Prerequisites
Both modes need the same things:
A running sfp deployment (V3 or later) reachable over HTTPS.
Admin access to your identity provider.
An owner-level JWT for the sfp API. Sign in as the tenant admin to get one:
What's automated
For deployments created with sfp server init (V3+), SAML is enabled out of the box. There is no manual config-file editing required to turn it on:
Signing material is generated during
sfp server init.The IdP is registered through an HTTP API — no restart needed.
The provider ID and SSO domain are auto-published to every client (CLI, web app, desktop app) via
/sfp/api/config.
The only manual steps are configuring the IdP, registering it through the API, and provisioning users. Those are what the setup guides walk through.
High-level flow
Whichever mode you're in, the path is the same:
Configure your IdP — create an application, set the SAML URLs, copy the federation metadata URL. See Identity Providers.
Register the IdP with sfp — one API call. The server picks it up immediately.
Provision users —
POST /sfp/api/users(orsfp server user add). Self-registration is disabled by default; users must be created before they can sign in.Sign in — from the CLI, web UI, or desktop app. The SSO domain is auto-detected from the server config; users just click Continue.
Last updated
Was this helpful?