Identity federation: SSO, SCIM & LDAP
Standards-shaped SAML, SCIM, and LDAP — any conformant IdP connects with its generic connector, not a KHUB-specific one.
SAML 2.0 single sign-on#
See Authentication & sessions for the exact request flow. Configuration (Organization settings → Security) requires the IdP's SSO URL, its signing certificate, and an entity ID; KHUB exposes SP metadata for the reverse configuration on the IdP side. Two-factor enforcement and SSO are independent controls — an organization can require both.
SCIM 2.0 provisioning#
KHUB implements the standard SCIM 2.0 REST contract at /api/scim/v2/:orgSlug/:
| Endpoint | Purpose |
|---|---|
GET /ServiceProviderConfig, GET /ResourceTypes | Capability discovery, as required by the SCIM spec so an IdP can introspect what's supported before syncing. |
GET/POST/PUT/PATCH/DELETE /Users | Full user lifecycle — an IdP-initiated DELETE (or a PATCH setting active: false) deactivates the corresponding KHUB account, it does not hard-delete it. |
GET/POST/PUT/PATCH/DELETE /Groups | Group sync, mapped onto KHUB Team membership. |
Authenticated with a dedicated SCIM token (khub_scim_..., created under Organization settings → Provisioning) distinct from personal access tokens — a SCIM token authorizes only the SCIM endpoints for its own organization, not the general API. Because this is a standard-shaped implementation, any SCIM-capable IdP (Okta, Microsoft Entra ID, etc.) can be pointed at it using its generic SCIM connector rather than a KHUB-specific one.
LDAP / Active Directory sync#
Configured under Admin → LDAP with a bind DN, search base, and a group-to-role mapping. A scheduled sync service periodically binds to the configured directory, resolves matching users and group memberships, and reconciles them onto KHUB accounts and team membership — additive and corrective on every run (a user removed from a mapped group in the directory loses the corresponding team membership on the next sync), rather than only provisioning new accounts.
Domain verification#
An organization can prove ownership of an email domain by publishing a DNS TXT record KHUB generates for it:
Name: _khub-verify.<yourdomain.com>
Value: khub-domain-verify=<token>Verification performs a live DNS TXT lookup for that name and checks for the expected value — there's no manual "mark as verified" override, and a failed lookup returns a specific, actionable error (including that DNS propagation can take a few minutes) rather than a generic failure. A verified domain can be used to auto-associate sign-ups from that domain with the organization.