Single sign-on
Learn how the SAML SSO platform authenticates members through SP and IdP-initiated streams, verifies domain ownership, and enforces login policies.
The platform supports single SAML 2.0 registration for organization members. SSO delegates authentication to an identity provider, while the platform continues to control organization membership and authorization.
Authentication flows
Section titled “Authentication flows”- In an SP-initiated A user starts on the platform and is redirected to the configured identity provider.
- In an IdP-initiated flow, a user starts from the provider's application catalog. RelayState identifies the relevant configuration of the SAML platform.
The service provider metadata, entity ID and claim consumer URL are derived from the platform’s home audience under /api/connect/v1/saml/2.0/. Use the displayed implementation values instead of copying the URLs of another organization.
Domain ownership and enforcement
Domain ownership and enforcementCheck the property of an email domain before applying the SSO policy. A SAML configuration may be disabled, optional or required. First run optional authentication, confirm that expected users can log in and keep a tested recovery path before requesting SSO.
SSO authenticates a person; it does not provide or remove members themselves. SCIM to automate the life cycle or enable automatic authentication on the SAML configuration when new users should join the first authentication.
Membership roles from SAML
Section entitled “Membership roles from SAML”You can keep the platform roles under Peopleor map them from the identity provider.
Set Role Attribute The values supported are OWNER, ADMIN, ADMIN, EMPLOYEE, and VIEWER. Leave the field empty when owners and administrators should assign roles in the platform only.
Security boundary
Section entitled “Security boundary”- Request signed statements and check them against your current identity provider certificate.
- Keep the implementation clock synchronized as SAML statements have narrow validity windows.
- Cross-site SAML POSTs require cookies that modern browsers will only send with the ___ZBT_I18N_RUNTIME_BLOCK_175__ attribute.
- Limit who can change domains, certificates, and execution.
- The testing service provider and identity provider have initiated authentication after the certificate, URL, or domain has been changed.
Provider-specific setup pages for Google Workspace, Microsoft Entra ID, and Okta are available separately.