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​

Okta

Okta is your enterprise IdP

Azure AD

Microsoft Entra ID / Azure AD

Custom SAML

Any other SAML 2.0–compatible IdP (Ping, OneLogin, Auth0, etc.)

Team SSO

Each team or sub-team brings its own IdP

Related sign-in methods (not SAML SSO):

Email & password

Sign in with email and password

Google sign-in

Sign in with a Google account

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.

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