Identity Providers

This section covers the IdP-side configuration: creating the SAML application, setting the URLs sfp expects, mapping user attributes, and copying out the metadata URL you'll hand to sfp.

The steps are the same regardless of whether you're running self-hosted or cloud — only the URLs you paste into the IdP differ.

Pick your IdP

Other SAML 2.0 providers (Google Workspace, OneLogin, PingIdentity, etc.) follow the same shape — set the Entity ID and ACS URL, map the email and name attributes, copy the metadata URL. The Entra and Okta walkthroughs are good templates.

URL convention

Every SAML setup needs two URLs from sfp: the Entity ID (what the IdP calls "Identifier" or "Audience") and the ACS URL (what the IdP calls "Reply URL" or "Single sign-on URL").

Use the URL that matches your deployment mode:

For self-hosted, replace <your-domain> with the public domain of your sfp server. For cloud, both URLs always point at auth.flxbl.io — the global auth instance — regardless of your tenant domain.

The /auth/v1/sso/saml/... path is fixed and required; don't shorten or rewrite it.

What you'll copy out

At the end of IdP configuration you need exactly one thing to hand to sfp: the federation metadata URL. It looks like:

https://login.microsoftonline.com/<tenant>/federationmetadata/2007-06/federationmetadata.xml?appid=<app>

or for Okta:

https://<your-org>.okta.com/app/<app-id>/sso/saml/metadata

sfp downloads and parses this URL when you register the provider — you don't paste any certificates or XML manually.

Attribute mapping

sfp expects the IdP to send these attributes in the SAML assertion:

Each IdP page shows the exact claim names to use.

Next step

Once your IdP is configured and you have the metadata URL, head to:

• Self-Hosted Setup, or
• Cloud Setup

to register the IdP with sfp and provision users.