SAML 2.0 SSO

AxisSynapse is a SAML 2.0 Service Provider. Configure your IdP (Okta, Entra ID / Azure AD, ADFS, Ping, OneLogin) once per tenant; users on the configured email domains then sign in without ever seeing a password prompt.

Configure a provider

From the dashboard:

  1. Go to /settings → Identity & SSO → SAML 2.0 SSO providers → Add provider
  2. Paste the IdP's entityID, SSO URL, and X.509 signing certificate
  3. Add the email domains that should route to this IdP
  4. Save (status DRAFT)
  5. Click SP info on the row to copy our metadata URL into your IdP wizard
  6. Click Test config — runs validation + reachability checks
  7. Click Enable to switch the provider to ACTIVE

SP metadata

Every provider exposes its metadata at a stable URL:

curl
https://app.axissynapse.com/api/saml/{providerId}/metadata

Metadata advertises:

  • entityID: {baseUrl}/api/saml/{providerId}/metadata
  • ACS URL: {baseUrl}/api/saml/{providerId}/acs
  • Binding: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
  • NameID format: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress (default)
  • AuthnRequestsSigned: false
  • WantAssertionsSigned: true (configurable)

Attribute mapping

The platform ships defaults for every IdP we've seen. They cover all of:

  • email / Email / emailAddress
  • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
  • urn:oid:0.9.2342.19200300.100.1.3 (RFC 4524 mail)
  • givenName / urn:oid:2.5.4.42
  • surname / sn / urn:oid:2.5.4.4
  • groups / memberOf / http://schemas.xmlsoap.org/claims/Group

Tenants can override per-provider in the attributeMap field. NameID fallback: if no explicit Email attribute is provided but the NameID looks like an email, it's used.

Just-in-time provisioning

When allowJitProvisioning is on, a verified SAML assertion for an unknown email creates a fresh TenantUser with the provider's defaultRole. Existing users with status DISABLED or SUSPENDED are REACTIVATED — the IdP just said the person should have access.

We bridge IdP-side identifiers to local TenantUser.id via the ExternalIdMapping table, so future SCIM updates target the right row even when email changes.

Sign-in flow

  1. User enters email at /auth/login
  2. Login form parallel-queries OIDC + SAML discovery — SAML wins when both are configured
  3. Browser is redirected to /api/saml/{id}/login with the original target in relayState
  4. We POST a SAMLRequest to the IdP via an auto-submitting form
  5. IdP authenticates, posts back to our /api/saml/{id}/acs
  6. We verify the signature, attributes, conditions, audience, InResponseTo
  7. JIT-provision or look up the user, issue a session ticket, redirect to RelayState