Skip to main content

Single Sign-On (SSO)

Use SSO so people sign in to EKB with your organization’s identity provider instead of (or in addition to) email/password and Google sign-in.

EKB’s support team typically configures and tests platform SSO after you set up the application in your IdP and send metadata. For an IdP owned by a specific team or sub-team (not platform-wide), see Team SSO.

Choose a guide​

Related sign-in methods (not SAML SSO):

How platform SSO works​

  1. An admin creates a SAML application in your IdP (ACS URL, Entity ID, Name ID, attributes).
  2. You collect the IdP metadata URL (or metadata XML) and your enterprise email domain.
  3. You send those details to Support (provider name, domain, metadata, and whether SSO Sign-In Only should apply).
  4. EKB configures and tests the connection on your instance, then enables SSO for that domain.

Exact ACS URLs and claim mappings differ by provider — use the Okta, Azure AD, or Custom guide above.

SSO Sign-In Only​

When SSO Sign-In Only is enabled for a domain, users with that email domain must use SSO. Email/password sign-in and password reset are disabled for them. Request this flag when you submit the IdP details to Support, or confirm it with your EKB admin if it is managed in-product for your deployment.

Teams that do not accept platform SSO​

A team with its own subdomain can refuse platform SSO there, so that the subdomain accepts only the identity provider that team configured for itself. This is a per-team setting, held on each team separately and not inherited by sub-teams. Platform SSO is unaffected everywhere else, including on the shared sign-in page. See Team SSO.

What to send Support​

FieldExample
ProviderOkta, Azure AD, PingIdentity, …
Enterprise IDcompany.com (email domain)
Metadata URL or XMLIdP federation metadata
SSO Sign-In OnlyOptional — require SSO for that domain