SSO & SCIM. Enterprise identity, zero friction.
SAML / OIDC-Anmeldung gegen jeden großen IdP. SCIM-Verzeichnissynchronisierung stellt Benutzer automatisch bereit und entfernt sie. Webhook-Secrets rotieren ohne Zustandsverlust.
- SAML / OIDC against 20+ identity providers
- SCIM directory sync — provision and deprovision automatically
- Webhook secret rotation without downtime
- Full audit trail for compliance
SCIM directory sync
Provision and deprovision in under 60 seconds
Connect your IdP directory once. Every hire, transfer, and departure propagates to Elido automatically — no IT ticket, no manual invite, no forgotten offboarding gap.
- Auto-provisioningSCIM CREATE from Okta or Entra → Elido account in under 60s
- Group-to-role mappingIdP groups map to Elido roles; changes propagate on next sync
- Instant deprovisioningSCIM DELETE or active: false → sessions revoked immediately
- API key suspensionAll user API keys suspended on offboarding — no access-after-departure gap
- AAna KovačAdmin
- BBen CarterMember
- CCarla MoraMember
- DDmitri VolkovViewer
- EErika SaloMember
- AAna KovačAdmin
- BBen CarterMember
- CCarla MoraMember
- DDmitri VolkovViewer
- EErika Salodeprovisioned
Identity providers
Works with every major IdP
Elido uses WorkOS as the SSO and SCIM broker — 20+ connections out of the box, plus Generic SAML for any SP-initiated flow. Configure the Elido application in your IdP once; Elido generates the SAML metadata XML or OIDC credentials.
Any SAML 2.0-compliant IdP works via Generic SAML. See the setup guide →
- User provisioned via SCIMokta-scim-svc10.0.1.409:12:04
- SSO login — Oktaana@corp.com91.223.4.1709:14:31
- SSO login — Azure ADben@corp.com185.46.9.209:17:08
- Webhook secret rotatedadmin@corp.com77.123.11.510:05:22
- User deprovisioned via SCIMokta-scim-svc10.0.1.414:33:51
- Role changed: Member → Adminadmin@corp.com77.123.11.515:01:09
Audit trail
Immutable identity event log
Every SSO login, SCIM provision, role change, and secret rotation is logged append-only. No admin can delete entries. Export to CSV or stream to your SIEM via API.
- Timestamp, actor, action, target, and IdP connection per event
- 12-month retention on Business; longer available on request
- API export for SOC 2, ISO 27001, DORA, and NIS2 evidence
- Failed SSO attempts logged with reason code
- IP-based alerting for SSO probing threshold
- Secret rotations reference the overlap window in the log
What you can do
- Okta, Azure AD / Entra, Google Workspace
- E-Mail-Domain → Verbindungszuordnung
- SCIM-Benutzer erstellen / aktualisieren / löschen
- Webhook-Signaturprüfung (HMAC-SHA256)
Was Enterprise SSO und SCIM-Provisioning in der Produktion wirklich erfordern
SAML-Redirect ist die Grundvoraussetzung. Die folgenden Details behandeln Provisioning-Latenz, Rollenmapping, Secret-Rotation und die Fehlermodi, die für Security-Teams entscheidend sind.
SAML 2.0 und OIDC Login via WorkOS — Email-Domain-Routing zur richtigen IdP-Verbindung
Elido nutzt WorkOS als SSO-Broker, der über 20 IdP-Verbindungen unterstützt, darunter Okta, Azure AD / Entra ID, Google Workspace, OneLogin, PingFederate und jeden SAML 2.0-konformen IdP. Ihr IT-Team konfiguriert die Elido-Anwendung einmalig in Ihrem IdP; Elido generiert eine SAML-Metadaten-XML oder OIDC-Client-Credentials für den IdP-Setup-Assistenten. Email-Domain-Routing weist User-Email-Domains der korrekten IdP-Verbindung zu — User mit @ihrunternehmen.de werden automatisch zu Ihrer Okta-Verbindung geleitet, ohne diese auswählen zu müssen. Mehrere Email-Domains können auf eine einzige Verbindung gemappt werden (für Unternehmen mit fusionierten Einheiten oder mehreren Domains). JIT-Provisioning erstellt das Elido-Konto beim ersten SSO-Login, falls SCIM nicht verwendet wird; wenn SCIM aktiv ist, wird JIT deaktiviert und das Konto muss vor dem ersten Login via SCIM bereitgestellt werden.
SCIM 2.0 Verzeichnis-Synchronisierung: Automatisches Provisioning, Deprovisioning und Group-to-Role-Mapping
SCIM 2.0 synchronisiert das Benutzerverzeichnis Ihres Identity-Providers mit Elido. Wenn ein User in Okta oder Entra zur Elido-Anwendungsgruppe hinzugefügt wird, erhält Elido ein SCIM CREATE-Event und stellt das User-Konto bereit — kein IT-Ticket, keine manuelle Einladung. Updates der User-Profile (Name, Email) werden automatisch übernommen. Wenn ein User aus der Gruppe entfernt oder im IdP deaktiviert wird, erhält Elido ein SCIM DELETE- oder PATCH-Event (active: false) und entzieht sofort den Zugriff — aktive Sessions werden ungültig, API-Keys des Users werden gesperrt. Group-to-Role-Mapping ermöglicht es Ihnen, Ihre IdP-Gruppen (z. B. 'Elido-Admins', 'Elido-Viewer') auf Elido-Rollen (Admin, Member, Viewer) abzubilden. Rollenzuweisungen werden automatisch aktualisiert, wenn sich die Gruppenmitgliedschaft im IdP ändert. Die Provisioning-Latenz vom IdP-Event bis zur Erstellung des Elido-Kontos liegt in der Regel unter 60 Sekunden.
Webhook-Signing-Secrets rotieren ohne Verlust laufender Events — Zero-Downtime-Rotationsverfahren
Der SCIM-Webhook-Receiver und das Outbound-Webhook-System von Elido verwenden HMAC-SHA256-Signaturen zur Verifizierung der Event-Authentizität. Secrets laufen ab und müssen rotiert werden — entweder nach Zeitplan (empfohlen: 90 Tage) oder nach einer vermuteten Kompromittierung. Die Zero-Downtime-Rotation funktioniert wie folgt: Generieren Sie ein neues Secret im Dashboard (das alte bleibt 15 Minuten lang während des Übergangsfensters gültig), implementieren Sie das neue Secret in Ihren Systemen, verifizieren Sie den Empfang eines SCIM-Events mit dem neuen Secret und lösen Sie dann den sofortigen Ablauf des alten Secrets aus. Das 15-minütige Überlappungsfenster stellt sicher, dass laufende Events, die mit dem alten Secret signiert wurden, während des Bereitstellungsfensters weiterhin verarbeitet werden. Die Secret-Rotation wird im Audit-Trail mit Zeitstempel, Akteur (der Admin, der rotiert hat) und Bestätigung des Überlappungsablaufs protokolliert.
Vollständiges Identitäts-Event-Log: SSO-Logins, Provisioning-Events, Rollenänderungen und Secret-Rotationen
Jeder SSO-Login, jedes SCIM-Provisioning/Deprovisioning, jede Änderung der Rollenzuweisung und jede Secret-Rotation wird im Workspace-Audit-Trail (Business) protokolliert. Jeder Eintrag enthält: Zeitstempel, Akteur (User oder SCIM-Dienst), Aktionstyp, Ziel (betroffener User oder Ressource), verwendete IdP-Verbindung und die Workspace-ID. Der Audit-Trail ist Append-only und unveränderlich — kein Admin kann Einträge löschen. Export als CSV oder Abfrage via API für SIEM-Ingestion. Wenn Ihr Compliance-Framework Nachweise über Zugriffskontrollereignisse erfordert (SOC 2 Type II, ISO 27001, DORA, NIS2), ist der Audit-Trail das Artefakt. Die Aufbewahrungsfrist beträgt 12 Monate bei Business; längere Fristen sind auf Anfrage für regulierte Branchen verfügbar.
Erzwungener Session-Ablauf via SCIM — Zugriffswiderruf in unter 60 Sekunden bei IdP-Deaktivierung
Wenn SCIM signalisiert, dass ein User deaktiviert wurde (Mitarbeiter-Offboarding, Vertragsende), macht Elido sofort alle aktiven Sessions dieses Users ungültig und sperrt dessen API-Keys. Dies ist unabhängig von der Session-Cookie-TTL — Elido speichert ein Widerrufs-Flag pro User-ID und prüft dieses bei jeder authentifizierten Anfrage. Die Zeit von der IdP-Deaktivierung bis zum Zugriffswiderruf in Elido ist die SCIM-Event-Lieferlatenz: in der Regel unter 30 Sekunden bei Okta, unter 60 Sekunden bei Azure Entra. Für ein Hochsicherheits-Offboarding (z. B. ein ausscheidender Admin) kann ein Elido-Workspace-Admin eine spezifische User-Session auch manuell im Dashboard widerrufen, bevor das SCIM-Event eintrifft. Sowohl manuell widerrufene Sessions als auch SCIM-gesteuerte Widerrufe erscheinen im Audit-Trail.
Enterprise Security Teams, die Elido SSO & SCIM nutzen
Namen sind Platzhalter — echte Kunden-Case-Studies werden hier veröffentlicht, sobald sie erscheinen.
“SCIM-Offboarding war die Anforderung, die unser Security-Team vom ersten Tag an hatte. Wenn ein Mitarbeiter in Entra deaktiviert wird, ist der Zugriff auf Elido in weniger als einer Minute weg — kein manuelles Deprovisioning-Ticket, keine Sicherheitslücke durch vergessenes Widerrufen. Wir haben die Logs nach drei Monaten geprüft und null Ereignisse mit Zugriff nach dem Offboarding gefunden.”
“Wir haben fünf Unternehmens-Email-Domains aus zwei Akquisitionen. Das Email-Domain → IdP Routing in Elido handhabt alle fünf, die auf dieselbe Okta-Verbindung verweisen. User aller Domains gelangen in den richtigen SSO-Flow, ohne aus einer Liste wählen zu müssen.”
“Secret-Rotation ohne Downtime war das Detail, das uns überzeugt hat. Wir rotieren Webhook-Secrets gemäß unserer Richtlinie vierteljährlich; das 15-minütige Überlappungsfenster bedeutet, dass wir während der Geschäftszeiten ohne Incident-Risiko rotieren können. Jede Rotation wird protokolliert, auditiert und in unserem SOC 2-Nachweispaket referenziert.”
Elido SSO & SCIM vs Bitly vs Rebrandly
SSO ist auf dem Enterprise-Tier von Bitly und dem Business-Tier von Rebrandly verfügbar. SCIM-Provisioning ist bei beiden stärker eingeschränkt. Der Vergleich zeigt, was jeder tatsächlich bietet.
| Feature | Elido | Bitly Enterprise | Rebrandly Business |
|---|---|---|---|
| SAML 2.0 SSO | Ja — WorkOS Broker, 20+ IdP-Verbindungen | Ja — Enterprise-Tier | Ja — Business-Tier |
| OIDC SSO | Ja — neben SAML via WorkOS | Nur SAML | Nur SAML |
| SCIM 2.0 Provisioning | Vollständiges Create / Update / Delete + Group-to-Role-Mapping | Eingeschränkt — Nur User-Erstellung, kein Group-to-Role | Nicht verfügbar |
| Automatisches Deprovisioning beim Offboarding | Ja — SCIM DELETE, Session-Widerruf unter 60s | Nur manuell | Nur manuell |
| Email-Domain IdP Routing | Ja — Mehrere Domains pro Verbindung | Einzelne Domain pro Verbindung | Nicht dokumentiert |
| Audit-Trail für Identitäts-Events | Ja — Unveränderlich, 12 Monate, API-Export | Eingeschränktes Audit-Log | Eingeschränktes Audit-Log |
| Webhook Secret Rotation (Zero-Downtime) | Ja — 15-minütiges Überlappungsfenster | Nicht anwendbar | Nicht anwendbar |
Fragen zu SSO & SCIM
Welche Identity-Provider werden unterstützt?
Elido nutzt WorkOS als SSO- und SCIM-Broker, der Okta, Azure AD / Entra ID, Google Workspace, OneLogin, PingFederate, Shibboleth, ADFS, JumpCloud und jeden SAML 2.0-konformen IdP unterstützt. OIDC-Verbindungen werden ebenfalls unterstützt, z. B. für Provider wie Google Workspace und Azure. Falls Ihr IdP nicht auf der Standardliste von WorkOS steht, funktioniert der Verbindungstyp 'Generic SAML' von WorkOS mit jedem SAML 2.0 SP-initiierten Flow. Kontaktieren Sie uns, falls Sie eine spezifische, nicht aufgeführte IdP-Verbindung benötigen.
Was ist der Unterschied zwischen JIT-Provisioning und SCIM-Provisioning?
JIT-Provisioning (Just-in-Time) erstellt ein User-Konto in Elido beim ersten SSO-Login — es ist keine Vorab-Bereitstellung erforderlich. Es ist einfacher einzurichten, bietet aber keine Kontrolle darüber, wer sich einloggen kann (jeder mit einer gültigen SSO-Assertion erhält ein Konto). SCIM-Provisioning gibt Ihrem IdP die Kontrolle: Nur User in der bereitgestellten Gruppe können sich einloggen, und Konten werden vor dem ersten Login erstellt. Für Enterprise-Umgebungen, in denen der Zugriff vorab genehmigt werden muss, ist SCIM erforderlich. Wenn SCIM aktiv ist, wird JIT-Provisioning deaktiviert.
Wie funktionieren SCIM Group-to-Role-Mappings?
In den Workspace-SSO-Einstellungen ordnen Sie Ihre IdP-Gruppen Elido-Rollen zu: z. B. 'Okta-Gruppe: Elido Admins' → 'Elido-Rolle: Admin', 'Okta-Gruppe: Elido Members' → 'Elido-Rolle: Member'. Die Rolle eines Users in Elido folgt seiner IdP-Gruppenmitgliedschaft — wenn er in Okta von der Admins-Gruppe in die Members-Gruppe verschoben wird, wird seine Elido-Rolle beim nächsten SCIM-Sync (in der Regel unter 60 Sekunden) herabgestuft. Ein User in mehreren Gruppen erhält die Rolle mit den höchsten Privilegien aus den passenden Mappings.
Kann SSO für alle User erzwungen werden oder ist es optional?
SSO kann auf 'Erzwungen' eingestellt werden (alle User müssen sich via SSO anmelden — der Passwort-Login ist deaktiviert) oder auf 'Optional' (User können zwischen SSO oder Email+Passwort wählen). Bei Business wird die Erzwingung in den Workspace-SSO-Einstellungen konfiguriert. Sobald sie erzwungen wird, werden User ohne aktive SSO-Identität ausgesperrt — stellen Sie sicher, dass SCIM-Provisioning oder JIT die Konten angelegt haben, bevor Sie die Erzwingung aktivieren. Admin-Konten können als Break-Glass-Mechanismus von der SSO-Erzwingung ausgenommen werden; dies ist konfigurierbar.
Was passiert mit den API-Keys, wenn ein User via SCIM ausgephast wird?
Wenn SCIM einen User deaktiviert, sperrt Elido alle API-Keys, die von diesem User erstellt wurden. Gesperrte Keys geben bei der Authentifizierung den HTTP-Code 401 zurück. Die Keys werden nicht gelöscht — sie bleiben für Workspace-Admins zu Prüfzwecken sichtbar, mit dem Statuslabel 'Gesperrt — Offboardeter User'. Wenn ein Service-Konto einen persönlichen API-Key verwendet hat (keinen Workspace-Service-Key), wird die Key-Sperrung diese Integration unterbrechen — dies ist beabsichtigt. Verwenden Sie für Produktionsintegrationen Workspace-Level Service-Keys anstelle von User-API-Keys.
Ist SSO bei Pro verfügbar oder nur bei Business?
SSO und SCIM sind reine Business-Features. Pro-Workspaces nutzen die integrierte Authentifizierung von Elido (Email + Passwort via Ory Kratos, optional Google/GitHub OAuth). Falls SSO eine zwingende Voraussetzung für Ihre Beschaffungsgenehmigung ist, ist der Business-Plan der Startpunkt. Kontaktieren Sie den Vertrieb für einen Business-Testzugang, falls Sie SSO vorab evaluieren möchten.
Wie handhabe ich SSO für einen Workspace mit mehreren Marken oder Unterorganisationen?
Jeder Elido-Workspace hat seine eigene SSO-Konfiguration — wenn Sie mehrere Workspaces betreiben (z. B. pro Marke, pro Geschäftseinheit), erhält jeder separat seine eigene IdP-Verbindung und sein eigenes SCIM-Provisioning. User können Mitglieder mehrerer Workspaces mit unterschiedlichen Rollen sein; ihre IdP-Identität ist dieselbe, aber die Group-to-Role-Mappings werden pro Workspace ausgewertet. Eine geteilte Okta-Gruppe kann in einem Workspace als Admin und in einem anderen als Member gemappt werden.
Gibt es einen Audit-Trail für fehlgeschlagene SSO-Versuche?
Ja. Fehlgeschlagene SSO-Versuche (ungültige SAML-Assertion, abgelaufene Session, fehlendes SCIM-Konto bei deaktiviertem JIT) werden im Workspace-Audit-Trail mit dem Ursachencode protokolliert. Dies ist nützlich für die Diagnose, warum sich ein bestimmter User nicht einloggen kann, und für die Erkennung von Brute-Force-SSO-Probing. Fehlversuche von IP-Adressen, die einen Schwellenwert überschreiten, lösen einen Workspace-Alarm aus (konfigurierbar in den Workspace-Security-Einstellungen).
Keep reading
White-label Portal SSO — Ihre Kunden melden sich über ihren IdP in Ihrem gebrandeten Dashboard an.
HMAC-signierte Outbound-Webhooks — dasselbe Secret-Rotationsmuster gilt für Outbound-Webhook-Signaturen.
Workspace-Service-Keys für Produktions-API-Integrationen — auf Workspace-Ebene, nicht auf einzelne User beschränkt.
SOC 2, ISO 27001, EU-Residenz und dedizierte Edge — der vollständige Enterprise-Feature-Stack.
Bereit zum Ausprobieren?
Starten Sie mit dem kostenlosen Plan, upgraden Sie, wenn Sie eine benutzerdefinierte Domain benötigen.