SSO & SCIM. Enterprise-identiteit, zonder frictie.

Elido gebruikt WorkOS als SSO- en SCIM-broker, die Okta, Azure AD / Entra ID, Google Workspace, OneLogin, PingFederate, Shibboleth, ADFS, JumpCloud en elke SAML 2.0-conforme IdP ondersteunt. OIDC-connections worden ook ondersteund voor providers zoals Google Workspace en Azure. Staat jouw IdP niet op de standaardlijst van WorkOS, dan werkt het 'Generic SAML'-connectionstype van WorkOS met elke SAML 2.0 SP-initiated flow. Neem contact met ons op als je een specifieke IdP-connection nodig hebt die niet vermeld staat.

JIT (Just-in-Time) provisioning maakt bij de eerste SSO-inlog een gebruikersaccount in Elido aan - geen voorafgaande provisioning nodig. Het is eenvoudiger op te zetten, maar geeft geen controle over wie kan inloggen (iedereen met een geldige SSO-assertion krijgt een account). SCIM-provisioning geeft je IdP de controle: alleen gebruikers in de geprovisioneerde groep kunnen inloggen, en accounts worden aangemaakt vóór de eerste inlog. Voor enterprise-omgevingen waar toegang vooraf moet worden goedgekeurd, is SCIM vereist. Als SCIM actief is, wordt JIT-provisioning uitgeschakeld.

In de SSO-instellingen van de workspace koppel je je IdP-groepen aan Elido-rollen: bijvoorbeeld 'Okta-groep: Elido Admins' → 'Elido-rol: Admin', 'Okta-groep: Elido Members' → 'Elido-rol: Member'. De rol van een gebruiker in Elido volgt zijn IdP-groepslidmaatschap - als iemand van de groep Admins naar de groep Members in Okta wordt verplaatst, wordt zijn Elido-rol bij de volgende SCIM-sync afgewaardeerd (doorgaans binnen 60 seconden). Een gebruiker in meerdere groepen krijgt de rol met de hoogste rechten uit de bijpassende mappings.

SSO kan worden ingesteld op verplicht (alle gebruikers moeten via SSO inloggen - inloggen met wachtwoord is uitgeschakeld) of optioneel (gebruikers kunnen kiezen tussen SSO of e-mail+wachtwoord). Op Business wordt handhaving geconfigureerd in de SSO-instellingen van de workspace. Zodra handhaving actief is, worden gebruikers zonder actieve SSO-identiteit buitengesloten - zorg dat SCIM-provisioning of JIT accounts heeft aangemaakt vóórdat je handhaving inschakelt. Admin-accounts kunnen als break-glass-mechanisme worden uitgesloten van SSO-handhaving; dit is configureerbaar.

Wanneer SCIM een gebruiker deactiveert, schorst Elido alle API-keys die door die gebruiker zijn aangemaakt. Geschorste keys geven HTTP 401 bij authenticatie. Keys worden niet verwijderd - ze blijven zichtbaar voor workspace-admins voor auditdoeleinden, met een statuslabel 'geschorst - offboarded gebruiker'. Gebruikte een service-account een persoonlijke API-key (geen workspace service key), dan breekt de schorsing die integratie - dit is bewust zo. Gebruik voor productie-integraties workspace-brede service keys in plaats van persoonlijke API-keys.

SSO en SCIM zijn Business-only functies. Pro-workspaces gebruiken de ingebouwde authenticatie van Elido (e-mail + wachtwoord via onze authenticatielaag, optioneel Google/GitHub OAuth). Als SSO een harde vereiste is voor je inkoopgoedkeuring, is het Business-plan het startpunt.

Elke Elido-workspace heeft zijn eigen SSO-configuratie - draai je meerdere workspaces (bijvoorbeeld per merk, per business unit), dan krijgt elke workspace zijn eigen IdP-connection en SCIM-provisioning afzonderlijk. Gebruikers kunnen lid zijn van meerdere workspaces met verschillende rollen in elk; hun IdP-identiteit is dezelfde, maar group-to-role-mappings worden per workspace geëvalueerd. Een gedeelde Okta-groep kan in de ene workspace naar Admin mappen en in een andere naar Member.

Ja. Mislukte SSO-pogingen (ongeldige SAML-assertion, verlopen sessie, ontbrekend SCIM-account terwijl JIT is uitgeschakeld) worden gelogd in de workspace-audittrail met de redencode. Dit is nuttig om te diagnosticeren waarom een specifieke gebruiker niet kan inloggen en om brute-force SSO-probing te detecteren. Mislukte pogingen vanaf IP-adressen die een drempel overschrijden, triggeren een workspace-alert (configureerbaar in de securityinstellingen van de workspace).