Generic SAML setup steps that apply to any IdP, plus links to fifteen provider-specific guides.

SAML 2.0

Use this when your IdP is not Google, Microsoft, or GitHub, or when you specifically want a SAML (rather than OAuth) integration with one of those.

Every IdP below needs an explicit email attribute, not just the Name ID. Safeguard reads the signed-in user's email from a SAML attribute literally named email in the assertion's Attribute Statement — this is a different thing from the Name ID you also configure. Setting the Name ID format to Email is necessary but on its own may not be sufficient. Whatever your IdP calls this section ("Attribute Statements," "Attribute Mapping," "Attributes & Claims"), add or rename an entry so its attribute name is exactly email, mapped to the user's email address. Skipping this is the most common reason a SAML login looks fully configured on both sides but still fails.

Two different "Entity ID" values — don't mix them up. SAML involves two separate fields, both usually labelled "Entity ID", and they must hold different values:

The IdP Entity ID identifies the identity provider (e.g. Google): https://accounts.google.com/o/saml2?idpid=C0abc1def. This goes into Safeguard — it's the Entity ID field of the Add-Provider form.

The SP Entity ID identifies Safeguard as the service provider: https://api.safeguard.sh/auth/idp/realms/sg_ab12cde. This goes into the IdP — the IdP's Entity ID / Audience field, alongside the ACS URL.

Putting the IdP's own entity ID into the IdP's Entity ID field (echoing the IdP's value back to itself) makes the IdP reject the request. They must be the two distinct values above.

Both sign-in directions work. The usual path is SP-initiated: start at https://app.safeguard.sh, enter your email, and pick the SSO button. IdP-initiated login also works — launching from the IdP's app launcher/dashboard or a "Test SAML login" button signs you straight into Safeguard. Safeguard detects the unsolicited SAML response landing on the broker endpoint and transparently restarts it as an SP-initiated login; since you're already authenticated at the IdP, it completes with no second prompt. (This requires the provider to be configured and enabled in Safeguard first.)

Generic steps (any SAML IdP)

In your IdP, create a new SAML application/integration.
Set the IdP's ACS URL (sometimes called Reply URL or Single Sign-On URL) to the ACS URL Safeguard shows in the dialog after Save (the .../auth/idp/realms/.../broker/<alias>/endpoint value).
Set the IdP's Entity ID / Audience (SP Entity ID) to the SP Entity ID Safeguard shows (the .../auth/idp/realms/<tenantId> value). You'll enter the IdP's entity ID (not this one) into Safeguard in a later step.
Set Name ID format to Email / EmailAddress, and map the Name ID to the user's email attribute.
Also add an explicit attribute statement/mapping (separate from the Name ID) with the attribute name email, mapped to the user's email address. Safeguard reads email from this named attribute, not from the Name ID directly — most IdPs let you add this in an "Attribute Statements" or "Attribute Mapping" section of the same app config. Skipping this is the most common reason a SAML login otherwise appears fully configured but fails with a claim/email error.
From the IdP, collect three values: the SSO/Login URL, the Entity ID / Issuer, and the X.509 signing certificate (PEM format).

In Safeguard, click Add Provider → SAML 2.0 and fill in:

Field	Value
Alias	A short, URL-safe id, e.g. `okta`, `entra`, `acme-sso` (lowercase letters, numbers, hyphens only)
Display Name	What users see on the login screen, e.g. "Sign in with Okta"
SSO Service URL	The IdP's SSO/Login URL from step 6
Entity ID	The IdP's Entity ID / Issuer from step 6
X.509 Certificate	Paste the full PEM certificate, including `-----BEGIN CERTIFICATE-----` / `-----END CERTIFICATE-----`

Click Save. Copy the ACS URL, SP Entity ID, and Metadata URL shown, and paste the ACS URL and SP Entity ID back into your IdP's app configuration if you hadn't already (some IdPs let you finish setup before these values exist — that's fine, just go back and update them now).
Assign users/groups to the app in your IdP.
Back in Safeguard, click Test next to the new provider.

Illustrative values for an Okta integration. The tenant-specific sg_ab12cde values show the shape only — Safeguard displays your real ACS URL and SP Entity ID in the Add Provider dialog after you click Save.

In Safeguard — Add Provider → SAML 2.0:

Field	Example value
Alias	`okta`
Display Name	`Sign in with Okta`
SSO Service URL	`https://example.okta.com/app/xxxxx/sso/saml`
Entity ID	`http://www.okta.com/exkxxxxxxx`
X.509 Certificate	the PEM block below

-----BEGIN CERTIFICATE-----
MIIDdDCCAlygAwIBAgIGAX...(full cert from your IdP)...P3B/k0SolrFYPo
-----END CERTIFICATE-----

In your IdP — the values you paste back from Safeguard:

Field	Example value
ACS URL (Reply URL / Single Sign-On URL)	`https://api.safeguard.sh/auth/idp/realms/sg_ab12cde/broker/okta/endpoint`
SP Entity ID (Audience)	`https://api.safeguard.sh/auth/idp/realms/sg_ab12cde`

The broker/<alias> segment of the ACS URL matches the Alias you chose above (here, okta).

SAML 2.0

SAML 2.0

Generic steps (any SAML IdP)

Example values (any SAML IdP)

In this section

On this page