SSO i SCIM. Enterprise identity, zero friction.
Logowanie SAML / OIDC z dowolnym głównym IdP. Synchronizacja katalogów SCIM automatycznie provisionuje i deprovisionuje użytkowników. Sekrety webhooków rotują bez utraty stanu.
- 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
- Mapowanie domena e-mail → połączenie
- Tworzenie / aktualizowanie / usuwanie użytkowników SCIM
- Weryfikacja sygnatur webhooków (HMAC-SHA256)
Czego w rzeczywistości wymaga produkcyjne wdrożenie SSO i SCIM w przedsiębiorstwie
Przekierowanie SAML to podstawa. Szczegóły poniżej obejmują opóźnienia aprowizacji, mapowanie ról, rotację sekretów i scenariusze awaryjne kluczowe dla zespołów bezpieczeństwa.
Logowanie SAML 2.0 i OIDC przez WorkOS — routing domen e-mail do właściwego połączenia IdP
Elido wykorzystuje WorkOS jako brokera SSO, co zapewnia obsługę ponad 20 połączeń IdP, w tym Okta, Azure AD / Entra ID, Google Workspace, OneLogin, PingFederate oraz dowolnego IdP zgodnego z SAML 2.0. Twój zespół IT konfiguruje aplikację Elido w IdP tylko raz; Elido generuje plik XML z metadanymi SAML lub poświadczenia klienta OIDC dla kreatora konfiguracji IdP. Routing domen e-mail mapuje domeny użytkowników na odpowiednie połączenie IdP — użytkownicy z domeny @twojafirma.pl są automatycznie kierowani do połączenia z Okta bez konieczności jego wybierania. Wiele domen e-mail może być zmapowanych na jedno połączenie (dla firm po fuzjach lub z wieloma domenami). Aprowizacja JIT tworzy konto Elido przy pierwszym logowaniu przez SSO, jeśli SCIM nie jest używany; jeśli SCIM jest aktywny, JIT zostaje wyłączony, a konto musi zostać zaprowiantowane przez SCIM przed pierwszym logowaniem.
Synchronizacja katalogów SCIM 2.0: automatyczna aprowizacja, deprovisioning i mapowanie grup na role
SCIM 2.0 synchronizuje katalog użytkowników Twojego dostawcy tożsamości z Elido. Gdy użytkownik zostanie dodany do grupy aplikacji Elido w Okta lub Entra, Elido otrzymuje zdarzenie SCIM CREATE i tworzy konto użytkownika — bez zgłoszeń IT, bez ręcznych zaproszeń. Aktualizacje profili użytkowników (imię, nazwisko, e-mail) są propagowane automatycznie. Gdy użytkownik zostanie usunięty z grupy lub dezaktywowany w IdP, Elido otrzymuje zdarzenie SCIM DELETE lub PATCH (active: false) i natychmiast odbiera dostęp — aktywne sesje są unieważniane, a klucze API należące do użytkownika zawieszane. Mapowanie grup na role pozwala przypisać grupy IdP (np. 'Administratorzy Elido', 'Obserwatorzy Elido') do ról w Elido (Admin, Member, Viewer). Przypisania ról aktualizują się automatycznie przy zmianie członkostwa w grupach IdP. Opóźnienie aprowizacji od zdarzenia w IdP do utworzenia konta w Elido wynosi zazwyczaj poniżej 60 sekund.
Rotacja sekretów podpisywania webhooków bez utraty zdarzeń w toku — procedura rotacji bez przestojów
Odbiornik webhooków SCIM i system wychodzących webhooków Elido używają sygnatur HMAC-SHA256 do weryfikacji autentyczności zdarzeń. Sekrety wygasają i wymagają rotacji — według harmonogramu (zalecane: co 90 dni) lub po podejrzewanym naruszeniu. Rotacja bez przestojów działa następująco: wygeneruj nowy sekret w panelu (stary sekret pozostaje ważny przez 15 minut), wdróż nowy sekret w swoich systemach, zweryfikuj przychodzące zdarzenie SCIM nowym sekretem, a następnie wymuś natychmiastowe wygaśnięcie starego sekretu. 15-minutowe okno nakładania się zapewnia, że zdarzenia w toku podpisane starym sekretem są nadal przetwarzane podczas wdrażania. Rotacja sekretów jest rejestrowana w dzienniku audytu z czasem, aktorem (administratorem, który dokonał rotacji) i potwierdzeniem wygaśnięcia.
Pełny dziennik zdarzeń tożsamości: logowania SSO, zdarzenia aprowizacji, zmiany ról i rotacje sekretów
Każde logowanie SSO, aprowizacja/deprovisioning SCIM, zmiana przypisania roli i rotacja sekretu są rejestrowane w dzienniku audytu obszaru roboczego (Business). Każdy wpis zawiera: znacznik czasu, aktora (użytkownika lub usługę SCIM), typ akcji, cel (użytkownik lub zasób, którego dotyczy zmiana), użyte połączenie IdP oraz ID obszaru roboczego. Dziennik audytu jest tylko do odczytu i niezmienny — żaden administrator nie może usuwać wpisów. Eksportuj do CSV lub pobieraj przez API na potrzeby SIEM. Jeśli Twoje ramy zgodności wymagają dowodów na zdarzenia kontroli dostępu (SOC 2 Type II, ISO 27001, DORA, NIS2), dziennik audytu jest tym artefaktem. Retencja wynosi 12 miesięcy w planie Business; dłuższa retencja jest dostępna na życzenie dla branż regulowanych.
Wymuszone wygasanie sesji przez SCIM — dostęp odebrany w mniej niż 60 sekund po dezaktywacji w IdP
Gdy SCIM zasygnalizuje, że użytkownik został dezaktywowany (offboarding pracownika, koniec kontraktu wykonawcy), Elido natychmiast unieważnia wszystkie aktywne sesje tego użytkownika i zawiesza jego klucze API. Nie zależy to od TTL pliku cookie sesji — Elido przechowuje flagę unieważnienia dla każdego ID użytkownika i sprawdza ją przy każdym uwierzytelnionym żądaniu. Czas od dezaktywacji w IdP do odebrania dostępu w Elido to opóźnienie dostarczenia zdarzenia SCIM: zazwyczaj poniżej 30 sekund dla Okta, poniżej 60 sekund dla Azure Entra. W przypadku offboardingu o wysokim rygorze bezpieczeństwa (np. odchodzący administrator), administrator obszaru roboczego Elido może również ręcznie unieważnić sesje konkretnego użytkownika w panelu, zanim nadejdzie zdarzenie SCIM. Zarówno ręcznie unieważnione sesje, jak i te wywołane przez SCIM pojawiają się w dzienniku audytu.
Zespoły ds. bezpieczeństwa w przedsiębiorstwach korzystające z Elido SSO i SCIM
Nazwy są tymczasowe — prawdziwe studia przypadków zostaną tu opublikowane wkrótce.
“Offboarding SCIM był wymaganiem naszego zespołu bezpieczeństwa od pierwszego dnia. Gdy pracownik zostaje dezaktywowany w Entra, dostęp do Elido znika w mniej niż minutę — bez ręcznych zgłoszeń, bez luki typu 'zapomniano odebrać dostęp'. Po trzech miesiącach sprawdziliśmy logi i nie znaleźliśmy ani jednego przypadku dostępu po odejściu pracownika.”
“Mamy pięć firmowych domen e-mail z dwóch przejęć. Routing domen e-mail na IdP w Elido obsługuje wszystkie pięć, kierując je do tego samego połączenia Okta. Użytkownicy z dowolnej domeny trafiają na właściwy przepływ SSO bez konieczności wybierania go z listy.”
“Rotacja sekretów bez przestojów to szczegół, który nas przekonał. Zgodnie z polityką rotujemy sekrety webhooków co kwartał; 15-minutowe okno nakładania się oznacza, że możemy to robić w godzinach pracy bez ryzyka incydentu. Każda rotacja jest rejestrowana, audytowana i stanowi część naszego pakietu dowodów SOC 2.”
Elido SSO i SCIM vs Bitly vs Rebrandly
SSO jest dostępne w planie enterprise Bitly i planie Business Rebrandly. Aprowizacja SCIM jest w obu przypadkach bardziej ograniczona. Porównanie obejmuje faktycznie dostarczane funkcje.
| Feature | Elido | Bitly Enterprise | Rebrandly Business |
|---|---|---|---|
| SSO SAML 2.0 | Tak — broker WorkOS, ponad 20 połączeń IdP | Tak — plan enterprise | Tak — plan Business |
| SSO OIDC | Tak — obok SAML przez WorkOS | Tylko SAML | Tylko SAML |
| Aprowizacja SCIM 2.0 | Pełne tworzenie / aktualizacja / usuwanie + mapowanie grup na role | Ograniczone — tylko tworzenie użytkowników, brak mapowania ról | Niedostępne |
| Automatyczny deprovisioning przy offboardingu | Tak — SCIM DELETE, unieważnienie sesji poniżej 60s | Tylko ręcznie | Tylko ręcznie |
| Routing IdP na podstawie domeny e-mail | Tak — wiele domen na połączenie | Jedna domena na połączenie | Brak dokumentacji |
| Dziennik audytu dla zdarzeń tożsamości | Tak — niezmienny, 12 miesięcy, eksport API | Ograniczony dziennik audytu | Ograniczony dziennik audytu |
| Rotacja sekretów webhooków (bez przestojów) | Tak — 15-minutowe okno nakładania się | Nie dotyczy | Nie dotyczy |
Pytania o SSO i SCIM
Którzy dostawcy tożsamości są obsługiwani?
Elido wykorzystuje WorkOS jako brokera SSO i SCIM, co zapewnia obsługę Okta, Azure AD / Entra ID, Google Workspace, OneLogin, PingFederate, Shibboleth, ADFS, JumpCloud oraz dowolnego IdP zgodnego z SAML 2.0. Obsługiwane są również połączenia OIDC dla dostawców takich jak Google Workspace i Azure. Jeśli Twojego IdP nie ma na liście standardowej WorkOS, typ połączenia 'Generic SAML' działa z dowolnym przepływem SAML 2.0 zainicjowanym przez dostawcę usług (SP-initiated). Skontaktuj się z nami, jeśli potrzebujesz konkretnego połączenia IdP, którego nie wymieniono.
Czym różni się aprowizacja JIT od aprowizacji SCIM?
Aprowizacja JIT (Just-in-Time) tworzy konto użytkownika w Elido przy jego pierwszym logowaniu przez SSO — nie wymaga wstępnej konfiguracji. Jest prostsza w konfiguracji, ale nie daje kontroli nad tym, kto może się zalogować (każdy z poprawnym poświadczeniem SSO otrzymuje konto). Aprowizacja SCIM daje kontrolę Twojemu IdP: tylko użytkownicy w zaprowiantowanej grupie mogą się logować, a konta są tworzone przed pierwszym logowaniem. W środowiskach korporacyjnych, gdzie dostęp musi być wcześniej zatwierdzony, SCIM jest wymagany. Gdy SCIM jest aktywny, aprowizacja JIT zostaje wyłączona.
Jak działa mapowanie grup na role w SCIM?
W ustawieniach SSO obszaru roboczego mapujesz grupy IdP na role w Elido: np. 'Grupa Okta: Administratorzy Elido' → 'Rola Elido: Admin', 'Grupa Okta: Członkowie Elido' → 'Rola Elido: Member'. Rola użytkownika w Elido zależy od jego przynależności do grup IdP — jeśli zostanie przeniesiony z grupy Administratorów do grupy Członków w Okta, jego rola w Elido zostanie obniżona przy następnej synchronizacji SCIM (zazwyczaj poniżej 60 sekund). Użytkownik należący do wielu grup otrzymuje najwyższą rolę z pasujących mapowań.
Czy SSO może być wymagane dla wszystkich użytkowników, czy jest opcjonalne?
SSO można ustawić jako wymuszane (wszyscy użytkownicy muszą logować się przez SSO — logowanie hasłem jest wyłączone) lub opcjonalne (użytkownicy mogą wybrać SSO lub e-mail + hasło). W planie Business wymuszanie konfiguruje się w ustawieniach SSO obszaru roboczego. Po wymuszeniu użytkownicy bez aktywnej tożsamości SSO tracą dostęp — przed włączeniem należy upewnić się, że konta zostały zaprowiantowane przez SCIM lub JIT. Konta administratorów mogą być zwolnione z wymogu SSO jako mechanizm 'break-glass'; jest to konfigurowalne.
Co dzieje się z kluczami API, gdy użytkownik przechodzi offboarding przez SCIM?
Gdy SCIM dezaktywuje użytkownika, Elido zawiesza wszystkie klucze API utworzone przez tego użytkownika. Zawieszone klucze zwracają błąd HTTP 401 przy uwierzytelnianiu. Klucze nie są usuwane — pozostają widoczne dla administratorów obszaru roboczego w celach audytowych z etykietą statusu 'zawieszony — użytkownik po offboardingu'. Jeśli konto usługowe korzystało z osobistego klucza API (zamiast klucza usługowego obszaru roboczego), zawieszenie klucza przerwie tę integrację — jest to zamierzone działanie. Dla integracji produkcyjnych należy używać kluczy usługowych na poziomie obszaru roboczego, a nie kluczy API użytkowników.
Czy SSO jest dostępne w planie Pro, czy tylko Business?
SSO i SCIM to funkcje dostępne wyłącznie w planie Business. Obszary robocze Pro korzystają z wbudowanego uwierzytelniania Elido (e-mail + hasło przez Ory Kratos, opcjonalnie Google/GitHub OAuth). Jeśli SSO jest twardym wymogiem w procesie zakupowym, plan Business jest punktem wyjścia. Skontaktuj się z działem sprzedaży w sprawie okresu próbnego Business, jeśli chcesz przetestować SSO przed zakupem.
Jak zarządzać SSO dla obszaru roboczego z wieloma markami lub podorganizacjami?
Każdy obszar roboczy Elido ma własną konfigurację SSO — jeśli prowadzisz wiele obszarów (np. dla każdej marki lub jednostki biznesowej), każdy z nich otrzymuje oddzielne połączenie IdP i aprowizację SCIM. Użytkownicy mogą należeć do wielu obszarów z różnymi rolami w każdym z nich; ich tożsamość w IdP jest taka sama, ale mapowania grup na role są oceniane dla każdego obszaru z osobna. Wspólna grupa w Okta może być zmapowana na Admina w jednym obszarze i Membera w innym.
Czy istnieje dziennik audytu dla nieudanych prób logowania SSO?
Tak. Nieudane próby logowania SSO (nieprawidłowa asercja SAML, wygasła sesja, brak konta SCIM przy wyłączonym JIT) są rejestrowane w dzienniku audytu obszaru roboczego wraz z kodem przyczyny. Jest to przydatne do diagnozowania, dlaczego dany użytkownik nie może się zalogować, oraz do wykrywania prób siłowego sondowania SSO. Nieudane próby z adresów IP przekraczających próg wyzwalają alert obszaru roboczego (konfigurowalny w ustawieniach bezpieczeństwa).
Keep reading
SSO dla portalu white-label — Twoi klienci logują się do Twojego markowego panelu przez własne IdP.
Wychodzące webhooki podpisane HMAC — ten sam wzorzec rotacji sekretów dotyczy sygnatur wychodzących webhooków.
Klucze usługowe obszaru roboczego dla produkcyjnych integracji API — ograniczone do obszaru roboczego, a nie poszczególnych użytkowników.
SOC 2, ISO 27001, rezydencja danych w UE i dedykowany edge — pełny stos funkcji enterprise.
Gotowy, aby wypróbować?
Zacznij od planu darmowego, uaktualnij, gdy będziesz potrzebować niestandardowej domeny.