Skip to content

Single Sign-On (SSO)

The Zaita platform supports SAML 2.0 Single Sign-On, allowing your organisation to authenticate users through an existing Identity Provider (IdP) rather than managing separate credentials within the platform. SSO is available on supported subscription tiers and applies across both multi-tenant and single-tenant deployments.

Supported Identity Providers

Any SAML 2.0-compliant identity provider is supported, including:

  • Microsoft Entra ID (formerly Azure Active Directory)
  • Okta
  • OneLogin
  • Google Workspace
  • Any other SAML 2.0-compliant IdP

SSO Enforcement Modes

SSO can be configured to operate in three modes:

Mode Behaviour
Disabled All users authenticate with email and password. SSO is not available.
Optional The login page offers both password authentication and a "Sign in with SSO" button. Users may choose either method.
Required All users must authenticate through SSO. The password form is not shown. Individual users can be exempted — see Per-User SSO Bypass.

Configuring SSO

SSO configuration is managed by a Super Administrator under Admin → Settings → SSO.

Note: SSO configuration requires a subscription tier that includes the SSO feature. If your current plan does not include SSO, a notice will appear on the settings page.

Step 1 — Gather Your IdP Details

Before configuring SSO in Zaita, obtain the following values from your identity provider:

Field Description
IdP Entity ID The unique identifier (Issuer URL) for your IdP, found in its SAML metadata
IdP SSO URL The URL to which Zaita will send authentication requests (HTTP-Redirect binding)
IdP X.509 Certificate The public certificate used by the IdP to sign SAML assertions
IdP SLO URL (optional) The Single Logout URL (reserved for future use)

Step 2 — Configure Your IdP

Register Zaita as a Service Provider in your IdP using the following values:

IdP Field Value
SP Entity ID / Audience URI https://<your-zaita-url>/saml/metadata
ACS URL / Reply URL https://<your-zaita-url>/sso/saml/acs
ACS Binding HTTP-POST
NameID Format Email Address (recommended)
Attribute Statements Map email, first_name, last_name

Replace <your-zaita-url> with your organisation's Zaita portal URL (e.g. https://au.zaita.com or your single-tenant URL).

Step 3 — Enter IdP Settings in Zaita

  1. Navigate to Admin → Settings → SSO.
  2. Under Identity Provider Settings, enter the IdP Entity ID, IdP SSO URL, and IdP X.509 Certificate obtained in Step 1.
  3. Optionally enter the IdP SLO URL if your IdP supports Single Logout.
  4. Select the NameID Format that matches your IdP configuration (Email Address is recommended).

Security note: IdP credentials entered here are stored encrypted at rest and are never displayed again after saving. To update a credential, simply enter a new value — leaving a field blank preserves the existing value.

Step 4 — Configure Attribute Mapping

The attribute mapping controls how SAML assertion attributes are mapped to Zaita user fields. The defaults match the most common IdP configurations:

Zaita Field Default SAML Attribute
Email address email
First name first_name
Last name last_name

If your IdP uses different attribute names, update the mapping to match. The email attribute is the primary field used to identify users during authentication.

Step 5 — Enable SSO

Once your IdP settings are saved:

  1. Toggle Enable SSO to activate single sign-on for your organisation.
  2. Optionally, toggle Require SSO to make SSO mandatory for all users.

Note: SSO cannot be enabled until IdP settings have been saved. Enabling "Require SSO" requires SSO itself to be enabled first. Disabling SSO automatically disables the Require SSO setting.

How SSO Login Works

When a user signs in with SSO:

  1. The user enters their email address on the Zaita login page and clicks Continue.
  2. The platform checks whether SSO is available or required for that user's organisation.
  3. The user is presented with a Sign in with SSO button (or, if SSO is required, redirected automatically).
  4. The user authenticates at their organisation's identity provider — including any MFA policies enforced by the IdP.
  5. The IdP posts a signed SAML assertion back to Zaita.
  6. Zaita validates the assertion and locates the matching user account by email address.
  7. The user is signed in and redirected to the dashboard.

Important: User accounts must exist in the Zaita platform before SSO authentication will succeed. SSO authenticates users — it does not automatically create new accounts. To add users, see Creating and Managing Users.

Per-User SSO Bypass

When SSO is set to Required, individual users can be exempted to allow them to authenticate with a password instead. This is useful for:

  • Service or break-glass accounts that must remain accessible if the IdP is unavailable.
  • Users whose accounts predate SSO configuration and require a transition period.

To configure a bypass for a specific user:

  1. Navigate to Admin → Users.
  2. Click the eye icon to open the user's account.
  3. In the Single Sign-On section, enable Allow password login (bypass SSO).

Bypassed users will see both the password form and the SSO button on the login page, regardless of the SSO enforcement setting.

Deleting the SSO Configuration

To remove SSO configuration entirely:

  1. Navigate to Admin → Settings → SSO.
  2. Select Delete Configuration and confirm.

Deleting the configuration disables SSO immediately and removes all stored IdP credentials. Users will revert to password-based authentication.

Security

  • Encrypted storage: All IdP credentials and certificates are encrypted at rest. Sensitive fields are never returned to the browser after saving.
  • Assertion validation: Zaita enforces strict SAML validation and requires all assertions to be signed by the IdP's X.509 certificate.
  • Tenant isolation: A user can only authenticate into their own organisation's account. Matching is performed by email address and organisation, preventing cross-tenant access.
  • Session security: Sessions are regenerated upon successful SSO login.
  • MFA: Multi-factor authentication for SSO users is managed entirely by your identity provider.

Best Practices

  • Enable SSO where possible — centralising authentication through your IdP reduces credential sprawl and lets you enforce your organisation's existing MFA and access policies.
  • Pre-create user accounts — ensure all users who need access have accounts in Zaita before enabling SSO. Users who cannot be matched by email address will not be able to sign in.
  • Use "Require SSO" for full control — enabling forced SSO ensures all authentication flows through your IdP, where you can apply conditional access, MFA, and device compliance policies.
  • Limit SSO bypass accounts — only grant per-user SSO bypass where operationally necessary, and review these accounts regularly.
  • Test before enforcing — configure and validate SSO in Optional mode before switching to Required, to avoid locking users out during a misconfiguration.
  • Keep IdP certificates current — update the IdP X.509 certificate in Zaita before it expires to avoid authentication failures.