SSO та SCIM. Enterprise identity, zero friction.
Вхід SAML / OIDC проти будь-якого основного IdP. Синхронізація каталогів SCIM автоматично провізіонує та депровізіонує користувачів. Секрети вебхуків обертаються без втрати стану.
- 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
- Відображення домену електронної пошти → підключення
- SCIM user create / update / delete
- Перевірка підпису вебхука (HMAC-SHA256)
Що насправді потрібно для корпоративного SSO та SCIM-провіженінгу у продакшені
SAML-редирект — це лише база. Нижче описано деталі щодо затримки провіженінгу, маппінгу ролей, ротації секретів та сценаріїв відмов, які важливі для команд безпеки.
Вхід через SAML 2.0 та OIDC за допомогою WorkOS — маршрутизація за доменом пошти до потрібного IdP
Elido використовує WorkOS як SSO-брокера, який підтримує понад 20 з'єднань IdP, включаючи Okta, Azure AD / Entra ID, Google Workspace, OneLogin, PingFederate та будь-який SAML 2.0-сумісний IdP. Ваша IT-команда один раз налаштовує застосунок Elido у вашому IdP; Elido генерує метадані SAML XML або облікові дані клієнта OIDC для майстра налаштування IdP. Маршрутизація за доменом пошти спрямовує домени користувачів до відповідного з'єднання IdP — користувачі з @yourcompany.com автоматично перенаправляються на ваше з'єднання Okta без необхідності вибору зі списку. Кілька доменів пошти можуть бути прив’язані до одного з’єднання (для компаній після злиття або з кількома доменами). JIT-провіженінг створює акаунт Elido під час першого входу через SSO, якщо SCIM не використовується; якщо SCIM активовано, JIT вимикається, і акаунт має бути створений через SCIM перед першим входом.
Синхронізація каталогу SCIM 2.0: автоматичне створення, видалення та маппінг груп на ролі
SCIM 2.0 синхронізує каталог користувачів вашого провайдера ідентифікації з Elido. Коли користувача додають до групи застосунку Elido в Okta або Entra, Elido отримує подію SCIM CREATE і створює акаунт користувача — без IT-тікетів та ручних запрошень. Оновлення профілю користувача (ім'я, пошта) поширюються автоматично. Коли користувача видаляють із групи або деактивують в IdP, Elido отримує подію SCIM DELETE або PATCH (active: false) і негайно відкликає доступ — активні сесії анулюються, API-ключі користувача призупиняються. Маппінг груп на ролі дозволяє прив’язати ваші групи IdP (наприклад, 'Elido Admins', 'Elido Viewers') до ролей Elido (Admin, Member, Viewer). Призначення ролей оновлюється автоматично при зміні членства в групах IdP. Затримка провіженінгу від події в IdP до створення акаунта Elido зазвичай становить менше 60 секунд.
Секрети підпису вебхуків ротуються без втрати подій у процесі — процедура ротації без простоїв
Приймач SCIM-вебхуків та система вихідних вебхуків Elido використовують підписи HMAC-SHA256 для перевірки автентичності подій. Термін дії секретів закінчується, і вони потребують ротації — або за розкладом (рекомендовано кожні 90 днів), або після підозри на компрометацію. Ротація без простоїв працює так: згенеруйте новий секрет у панелі керування (старий залишається дійсним протягом 15 хвилин вікна перекриття), розгорніть новий секрет у своїх системах, переконайтеся, що вхідна подія SCIM верифікується новим секретом, а потім ініціюйте негайне закінчення терміну дії старого секрету. 15-хвилинне вікно перекриття гарантує, що події в процесі, підписані старим секретом, все одно будуть оброблені під час розгортання. Ротація секретів фіксується в журналі аудиту з позначкою часу, актором (адміном, який провів ротацію) та підтвердженням закінчення терміну дії перекриття.
Повний журнал подій ідентифікації: входи через SSO, події провіженінгу, зміни ролей та ротації секретів
Кожен вхід через SSO, SCIM-провіженінг/депровіженінг, зміна призначення ролей та ротація секретів реєструються в журналі аудиту робочого простору (Business). Кожен запис містить: позначку часу, актора (користувача або сервіс SCIM), тип дії, ціль (користувача або ресурс), використане з'єднання IdP та ID робочого простору. Журнал аудиту доступний лише для додавання та незмінний — жоден адмін не може видалити записи. Експортуйте в CSV або робіть запити через API для SIEM. Якщо ваш фреймворк відповідності вимагає підтвердження подій контролю доступу (SOC 2 Type II, ISO 27001, DORA, NIS2), журнал аудиту є цим артефактом. Термін зберігання — 12 місяців на Business; довше зберігання доступне за запитом для регульованих галузей.
Примусове завершення сесії через SCIM — доступ відкликається менш ніж за 60 секунд після деактивації в IdP
Коли SCIM сигналізує про деактивацію користувача (звільнення співробітника, завершення контракту), Elido негайно анулює всі активні сесії цього користувача та призупиняє його API-ключі. Це не залежить від TTL сесійних кук — Elido зберігає прапорець відкликання для кожного ID користувача та перевіряє його при кожному автентифікованому запиті. Час від деактивації в IdP до відкликання доступу в Elido — це затримка доставки події SCIM: зазвичай до 30 секунд для Okta, до 60 секунд для Azure Entra. Для критичного відкликання доступу (наприклад, для адміна, що йде), адміністратор робочого простору Elido також може вручну анулювати сесії конкретного користувача в панелі керування до надходження події SCIM. Сесії, анульовані вручну та через SCIM, відображаються в журналі аудиту.
Команди корпоративної безпеки, що використовують Elido SSO та SCIM
Імена є плейсхолдерами — реальні кейси клієнтів з'являться тут після публікації.
“SCIM-офбординг був вимогою нашої команди безпеки з першого дня. Коли співробітник деактивується в Entra, доступ до Elido зникає менш ніж за хвилину — без ручних заявок на депровіженінг, без ризику 'забутого доступу'. Ми перевірили журнали через три місяці та не знайшли жодної події доступу після звільнення.”
“У нас п'ять поштових доменів компанії після двох поглинань. Маршрутизація доменів пошти до IdP в Elido дозволяє всім п'яти вказувати на одне з'єднання Okta. Користувачі з будь-якого домену потрапляють на потрібний потік SSO, не обираючи зі списку.”
“Ротація секретів без простоїв — це була деталь, яка нас переконала. Ми ротуємо секрети вебхуків щокварталу згідно з політикою; 15-хвилинне вікно перекриття означає, що ми можемо проводити ротацію в робочий час без ризику інцидентів. Кожна ротація фіксується в журналі, проходить аудит і вказується в нашому пакеті доказів SOC 2.”
Elido SSO та SCIM проти Bitly та Rebrandly
SSO доступне на тарифі Enterprise у Bitly та тарифі Business у Rebrandly. SCIM-провіженінг у обох обмеженіший. Порівняння охоплює те, що кожен пропонує насправді.
| Feature | Elido | Bitly Enterprise | Rebrandly Business |
|---|---|---|---|
| SAML 2.0 SSO | Так — брокер WorkOS, 20+ з'єднань IdP | Так — тариф Enterprise | Так — тариф Business |
| OIDC SSO | Так — разом із SAML через WorkOS | Тільки SAML | Тільки SAML |
| SCIM 2.0 provisioning | Повне створення / оновлення / видалення + маппінг груп на ролі | Обмежено — тільки створення користувачів, без маппінгу груп | Недоступно |
| Auto-deprovisioning on offboarding | Так — SCIM DELETE, сесія анулюється менш ніж за 60с | Тільки вручну | Тільки вручну |
| Email-domain IdP routing | Так — кілька доменів на з'єднання | Один домен на з'єднання | Не задокументовано |
| Audit trail for identity events | Так — незмінний, 12 місяців, експорт через API | Обмежений журнал аудиту | Обмежений журнал аудиту |
| Webhook secret rotation (zero downtime) | Так — 15-хвилинне вікно перекриття | Не застосовується | Не застосовується |
Питання щодо SSO та SCIM
Які провайдери ідентифікації (IdP) підтримуються?
Elido використовує WorkOS як SSO- та SCIM-брокера, який підтримує Okta, Azure AD / Entra ID, Google Workspace, OneLogin, PingFederate, Shibboleth, ADFS, JumpCloud та будь-який SAML 2.0-сумісний IdP. З'єднання OIDC також підтримуються для таких провайдерів, як Google Workspace та Azure. Якщо вашого IdP немає в стандартному списку WorkOS, тип з'єднання 'Generic SAML' працює з будь-яким потоком SAML 2.0, ініційованим сервіс-провайдером (SP-initiated). Зв'яжіться з нами, якщо вам потрібне специфічне з'єднання IdP, якого немає в списку.
Що таке JIT-провіженінг проти SCIM-провіженінгу?
JIT (Just-in-Time) провіженінг створює акаунт користувача в Elido під час його першого входу через SSO — попередня підготовка не потрібна. Це простіше в налаштуванні, але не дає контролю над тим, хто може увійти (будь-хто з дійсним SSO-підтвердженням отримує акаунт). SCIM-провіженінг дає контроль вашому IdP: тільки користувачі в підготовленій групі можуть увійти, а акаунти створюються до першого входу. Для корпоративних середовищ, де доступ має бути попередньо схвалений, SCIM є обов'язковим. Коли SCIM активний, JIT-провіженінг вимикається.
Як працює маппінг груп SCIM на ролі?
У налаштуваннях SSO робочого простору ви прив’язуєте свої групи IdP до ролей Elido: наприклад, 'Okta group: Elido Admins' → 'Elido role: Admin', 'Okta group: Elido Members' → 'Elido role: Member'. Роль користувача в Elido відповідає його членству в групі IdP — якщо його перемістити з групи Admins до групи Members в Okta, його роль в Elido буде понижена при наступній синхронізації SCIM (зазвичай до 60 секунд). Користувач, який перебуває в кількох групах, отримує роль з найвищими привілеями серед відповідних маппінгів.
Чи може SSO бути обов'язковим для всіх користувачів, чи це опціонально?
SSO можна встановити як обов'язкове (enforced) — тоді всі користувачі повинні входити через SSO, а вхід за паролем вимикається, або опціональне (users can choose SSO or email+password). На Business обов'язковість налаштовується в параметрах SSO робочого простору. Після ввімкнення обов'язковості користувачі без активної SSO-ідентичності будуть заблоковані — переконайтеся, що SCIM або JIT створили акаунти перед активацією. Акаунти адміністраторів можуть бути виключені з обов'язкового SSO як механізм екстреного доступу; це можна налаштувати.
Що стається з API-ключами, коли користувача видаляють через SCIM?
Коли SCIM деактивує користувача, Elido призупиняє всі API-ключі, створені цим користувачем. Призупинені ключі повертають HTTP 401 при автентифікації. Ключі не видаляються — вони залишаються видимими для адміністраторів робочого простору для цілей аудиту зі статусом 'suspended — offboarded user'. Якщо сервісний акаунт використовував персональний API-ключ (не сервісний ключ робочого простору), призупинення ключа розірве цю інтеграцію — це зроблено навмисно. Для продуктових інтеграцій використовуйте сервісні ключі рівня робочого простору, а не особисті API-ключі користувачів.
Чи доступне SSO на Pro, чи тільки на Business?
SSO та SCIM — це функції лише для тарифу Business. Робочі простори Pro використовують вбудовану автентифікацію Elido (email + пароль через Ory Kratos, опціонально Google/GitHub OAuth). Якщо SSO є жорсткою вимогою вашого відділу закупівель, тариф Business є стартовою точкою. Зв'яжіться з відділом продажу для пробного періоду Business, якщо вам потрібно оцінити SSO перед покупкою.
Як налаштувати SSO для робочого простору з кількома брендами або підрозділами?
Кожен робочий простір Elido має власну конфігурацію SSO — якщо ви керуєте кількома робочими просторами (наприклад, для окремих брендів чи підрозділів), кожен отримує своє з'єднання IdP та SCIM-провіженінг окремо. Користувачі можуть бути членами кількох робочих просторів з різними ролями в кожному; їхня ідентичність IdP залишається незмінною, але маппінги груп на ролі оцінюються для кожного простору. Спільна група Okta може відповідати ролі Admin в одному просторі та Member в іншому.
Чи є журнал аудиту для невдалих спроб входу через SSO?
Так. Невдалі спроби входу через SSO (недійсне підтвердження SAML, сесія, що закінчилася, відсутність акаунта SCIM при вимкненому JIT) реєструються в журналі аудиту робочого простору з кодом причини. Це корисно для діагностики того, чому конкретний користувач не може увійти, та для виявлення спроб підбору SSO. Невдалі спроби з IP-адрес, що перевищують поріг, ініціюють сповіщення робочого простору (налаштовується в параметрах безпеки).
Keep reading
SSO для White-label порталу — ваші клієнти входять у вашу брендовану панель керування через свій IdP.
Вихідні вебхуки з підписом HMAC — той самий шаблон ротації секретів застосовується до підписів вихідних вебхуків.
Сервісні ключі робочого простору для продуктових API-інтеграцій — діють на рівні простору, а не окремих користувачів.
SOC 2, ISO 27001, резидентність в ЄС та виділений edge — повний корпоративний стек функцій.
Готові спробувати?
Почніть з безкоштовного плану, оновіть, коли вам знадобиться власний домен.