Safeguard.sh Documentation Center
SSO AuthenticationSAML 2.0

SAML 2.0

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.

Generic steps (any SAML IdP)

  1. In your IdP, create a new SAML application/integration.

  2. 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).

  3. 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.

  4. Set Name ID format to Email / EmailAddress, and map the Name ID to the user's email attribute.

  5. 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.

  6. From the IdP, collect three values: the SSO/Login URL, the Entity ID / Issuer, and the X.509 signing certificate (PEM format).

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

    FieldValue
    AliasA short, URL-safe id, e.g. okta, entra, acme-sso (lowercase letters, numbers, hyphens only)
    Display NameWhat users see on the login screen, e.g. "Sign in with Okta"
    SSO Service URLThe IdP's SSO/Login URL from step 6
    Entity IDThe IdP's Entity ID / Issuer from step 6
    X.509 CertificatePaste the full PEM certificate, including -----BEGIN CERTIFICATE----- / -----END CERTIFICATE-----
  8. 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).

  9. Assign users/groups to the app in your IdP.

  10. Back in Safeguard, click Test next to the new provider.

In this section

On this page