Enterprise SSO (SAML 2.0)
If your identity provider speaks SAML 2.0 rather than OpenID Connect, Zynth Auth federates sign-in the same way — your members authenticate at your IdP and land in Zynth Auth with a normal session.
Availability: enterprise federation is feature-flagged per deployment. If the Enterprise SSO settings page reports it is not enabled, ask your platform operator to enable it. Prefer OIDC if your IdP supports both — it needs no certificate management.
Configuring a connection
Open Settings → Organization → Enterprise SSO (requires tenant:manage) and pick the
SAML 2.0 tab.
1. Register the SP at your IdP. The top card lists the service-provider details your IdP needs — copy them into your IdP's application config:
- Entity ID / Audience and ACS (Reply) URL — required.
- Single Logout URL — for IdP-initiated logout.
- SP metadata URL — many IdPs can import all of the above from this one URL.
2. Import your IdP's metadata (optional). Paste your IdP's metadata XML, or give its https metadata URL, and Zynth Auth fills the entity ID, SSO URL, SLO URL, and signing certificate for you. Nothing is saved until you save the connection.
3. Fill in / confirm the connection:
| Field | Meaning |
|---|---|
| IdP Entity ID / SSO URL | Your IdP's identifier and its SingleSignOnService (redirect) endpoint. |
| IdP signing certificate(s) | The PEM certificate(s) your IdP signs assertions with. List two during a rotation so either signature is accepted. |
| Email / Groups attribute | Which assertion attributes carry the user's email and directory groups (email can also come from an emailAddress NameID). |
| Group → role mapping | Maps IdP groups to membership roles, one group = role per line; first match wins, re-applied every sign-in. |
| Just-in-time provisioning | On: unknown subjects your IdP asserts get a workforce account. Off: only existing members can sign in. |
| Allow IdP-initiated login | Accept unsolicited responses (login started at the IdP). Off is safer — leave it off unless your IdP requires it. |
| Sign AuthnRequests / Require encrypted assertions | Optional hardening — both use this deployment's SP certificate. |
| Connection enabled | Master switch; configured-but-disabled serves no logins. |
Security posture (what Zynth Auth enforces)
Every assertion must be signed by one of your configured certificates — unsigned or
tampered assertions are rejected, as are ones with the wrong audience, an expired validity
window, or (for SP-initiated logins) a mismatched InResponseTo. Each assertion is accepted
once — replays fail. Deprecated signature algorithms (SHA-1) are refused. These are not
configurable; they always apply.
Single logout
If you configure an SLO URL, an IdP-initiated logout signs the user out of every device at once (not just the current session) and returns a signed response to your IdP. Zynth Auth requires the logout request to be signed.
Certificate rotation
When your IdP rotates its signing certificate, add the new PEM to the certificate list (keeping the old one) before the IdP switches, then remove the old one afterward. Logins never break during the overlap.
Requiring SSO for your organization
The Enforcement tab works the same for SAML tenants: require SSO and members can sign in only through your IdP, while owners keep an audited break-glass sign-in. See the OIDC guide's "Requiring SSO" section — the policy is protocol-independent.