SSO для веб-застосунку: де ламається вхід і права
Єдиний вхід (SSO) перестає бути «просто кнопкою входу», коли в компанії кілька систем: каталог співробітників, внутрішній портал, CRM, склад, бухгалтерія.
Кожна живе своєю базою облікових записів, і варто людині піти або змінити роль — права залишаються висіти в трьох-чотирьох місцях. Автентифікація формально працює, але вхід в одну систему вже відкриває зайве в іншій.
Перший типовий збій — розсинхронізація облікових записів. Співробітника завели в каталозі, але не завели в застосунку, або навпаки: звільнений продовжує заходити за старим токеном, бо сесія живе довше, ніж запис у довіднику.
Другий — ручні скидання паролів: підтримка витрачає години на «не пускає в особистий кабінет», хоча проблема в простроченому сертифікаті або збитому часі на сервері.
Третій збій — дублювання входів. Користувач заводить другий акаунт під іншою поштою, і у звітах з'являються дві «одні й ті самі» сутності з різними правами.
Четвертий — зростання навантаження на підтримку: чим більше систем, тим більше звернень, і кожна нова інтеграція додає свою точку відмови.
Розбираємо, як це закривається: єдина точка автентифікації, синхронізація довідника і правила відкликання доступу.
Що дає єдиний вхід: ефект у цифрах
Єдиний вхід вимірюється не зручністю «загалом», а трьома метриками: час доступу до застосунку, частка звернень до підтримки, пов'язаних із доступом, і кількість інцидентів із паролями.
До впровадження співробітник витрачає на вхід до кожної системи від 20 до 40 секунд — введення логіна, очікування перевірки, повтор при помилці. За десяти робочих сервісів це десятки хвилин на тиждень на людину, і втрати зростають лінійно з кількістю застосунків.
Основний ефект — зникнення класу помилок, пов'язаних зі скиданням пароля. За нашою практикою, скидання та відновлення доступу дають від 20 до 40 відсотків усіх звернень до підтримки.
Після переведення на єдиний вхід користувач проходить перевірку один раз через корпоративний обліковий запис, а застосунок отримує підтверджену сесію. Звернення щодо паролів падають у рази — підтримка перемикається на завдання, які справді потребують людини.
Час входу скорочується до однієї перевірки на старті робочого дня: далі переходи між сервісами відбуваються без повторної автентифікації.
Для сценаріїв із підвищеними вимогами до безпеки ми налаштовуємо повторне підтвердження лише на критичні операції, а не на кожен перехід — захист зберігається, тертя зникає.
Окремо закривається питання звільнень і зміни ролей: доступ відкликається в одній точці, а не в десяти адмінках.
Ми працюємо з перевіреними протоколами федеративної автентифікації та стандартними корпоративними каталогами — Keycloak як один із варіантів брокера, якщо потрібен повний контроль над інфраструктурою.
Це дає передбачувану інтеграцію з наявним каталогом користувачів без переписування застосунків. Ефект фіксуємо до і після: заміряємо час входу, рахуємо частку звернень щодо доступів, відстежуємо кількість інцидентів із паролями.
Способи реалізації SSO: порівняння підходів
Єдиний вхід рідко будують з нуля — частіше обирають між готовим протоколом, зв'язкою з корпоративним каталогом або проксі-шлюзом перед застосунком.
Вибір диктує не мода, а ландшафт: які системи вже є, де зберігаються облікові записи та наскільки глибоко застосунок має знати про користувача.
| Підхід | Коли підходить | Обмеження |
|---|---|---|
| OpenID Connect поверх OAuth 2.0 | Нові веб-застосунки, зовнішні користувачі, мобільні клієнти | Потребує провайдера ідентичності та акуратної роботи з токенами оновлення |
| SAML 2.0 | Корпоративний контур, вже є каталог і федерація з партнерами | Багатослівний обмін, складніше налагодження, слабша підтримка мобільних сценаріїв |
| Зв'язка з LDAP або Active Directory | Внутрішні системи в одній мережі, потрібен єдиний довідник співробітників | Погано проходить через зовнішні межі, потребує захищеного каналу |
| Проксі-шлюз перед застосунком | Легасі-системи, які не можна переписати | Обмежена гнучкість, залежність від шлюзу як єдиної точки відмови |
На що дивитися при виборі
Ключове питання — де живе сесія і як застосунок дізнається про вихід користувача. При федеративних протоколах потрібен єдиний вихід: без нього закриття сесії в одній системі залишає відкритими інші.
Для внутрішнього контуру це вирішується прив'язкою до каталогу, для зовнішнього — коротким терміном життя токена та оновленням за вимогою.
Окремо перевіряємо зіставлення ролей і груп: атрибути з каталогу мають розкладатися в права застосунку без ручної синхронізації. Якщо ролі ведуть у двох місцях, рано чи пізно вони розійдуться, і доступ отримає не той, кому він призначений.
Що врахувати щодо обмежень
Проксі-шлюз економить час на старті, але додає точку відмови та ускладнює налагодження: застосунок перестає бачити реальний контекст користувача. SAML надійний у корпоративному середовищі, однак кожен новий застосунок потребує окремого налаштування метаданих.
OpenID Connect гнучкіший, але перекладає частину відповідальності за безпеку токенів на команду розробки.
Ми розбираємо ваш ландшафт систем і пропонуємо підхід, який не доведеться переробляти при зростанні числа застосунків. Опишіть задачу — повернемося з оцінкою та планом.
Етапи впровадження єдиного входу в продукт
Впровадження SSO — це не «підключити бібліотеку», а замінити спосіб підтвердження особистості в усіх точках входу, не втративши жодного користувача й не відкривши дірку в доступах.
Тому починаємо не з коду, а з інвентаризації: які застосунки та сервіси вже використовують автентифікацію, де зберігаються облікові записи, які протоколи підтримує кожен компонент і хто власник кожного доступу. Без цієї карти будь-яке налаштування перетворюється на лотерею.
Як влаштований процес
- Аудит поточної автентифікації. Збираємо реєстр застосунків, зовнішніх сервісів та інтеграцій, фіксуємо, де вхід локальний, де через сторонній провайдер, де доступи видані вручну. Окремо позначаємо сервіси, які протокол єдиного входу не підтримують, — для них заздалегідь плануємо обхідний шлях.
- Вибір сценарію та провайдера. Визначаємо, хто виступає джерелом істини про облікові записи: корпоративний каталог, зовнішній провайдер чи власна база. Від цього залежить схема зіставлення користувачів і правила, за якими права з каталогу потрапляють у застосунки.
- Налаштування провайдера та застосунків. Реєструємо кожен застосунок у провайдера, налаштовуємо довірені адреси повернення, терміни життя сесій і токенів, зіставлення атрибутів. Тут же закладаємо вихід з усіх систем однією дією — інакше єдиний вхід залишається половинчастим.
- Перевірка на тестовому контурі. Проганяємо сценарії: перший вхід нового користувача, повторний вхід, зміна ролі в каталозі, відкликання доступу, закінчення сесії, недоступність провайдера. Кожен сценарій перевіряємо на всіх типах облікових записів, включно зі службовими.
- Міграція користувачів. Переносимо облікові записи та зв'язки з ролями, на перехідний період залишаємо обидва способи входу, щоб ніхто не втратив доступ. Локальні паролі вимикаємо лише після того, як переконалися, що всі увійшли через єдиний вхід.
- Передача в експлуатацію. Фіксуємо регламент: як додавати новий застосунок, як відкликати доступ при звільненні, хто відповідає за провайдера. Налаштовуємо журналювання входів і оповіщення про аномалії.
- Супровід. Періодично переглядаємо список підключених сервісів і правила зіставлення — склад систем змінюється швидше, ніж здається.
Опишіть вашу поточну схему входів — повернемося з оцінкою та планом робіт.
Що залишається у замовника після впровадження
Впровадження SSO — це не «поставили і забули»: інтеграція живе й змінюється разом із вашим ландшафтом застосунків. Тому всі артефакти передаємо у вашу інфраструктуру та репозиторії, а не тримаємо в себе. Нижче — що саме залишається у вас на руках і як цим користуватися без нас.
- Конфігурації сервісу ідентифікації — параметри підключення застосунків, налаштування сесій і токенів, правила випуску та оновлення облікових даних. Усе в системі контролю версій, з історією змін і можливістю відкату.
- Схеми потоків автентифікації — як користувач проходить вхід, де відбувається перевірка прав, як застосунок отримує підтвердження особи. Схеми описують і штатний сценарій, і поведінку за недоступності провайдера.
- Політики доступу — прив'язка ролей і груп до застосунків, правила успадкування прав, порядок призначення та відкликання доступу під час прийому, переведення й звільнення співробітника.
- Регламенти експлуатації — як додати новий застосунок, як підключити зовнішнього підрядника, що робити при збої входу і куди дивитися в першу чергу. Покроково, з відповідальними та точками контролю.
- Документація — опис архітектури, перелік підключених систем, довідник із налаштувань, журнал змін. Розрахована на інженера, який відкриє її за пів року без нас.
- Інструкції для служби підтримки — типові звернення щодо входу та відновлення доступу, готові відповіді й межа, за якою підключається технічна команда.
- Доступи та права адміністраторів — розділення ролей на керування користувачами та на зміну конфігурації, щоб повсякденні операції не вимагали повних прав.
Такий комплект знімає головний ризик: коли SSO починає жити своїм життям, у вас є і карта місцевості, і важелі керування. Опишіть вашу задачу — повернемося з оцінкою та планом, включно зі складом артефактів, що передаються.
Кейс: як ми усунули розсинхронізацію облікових записів
Клієнт — сервісна компанія з розподіленою командою — звернувся з класичним болем: кілька внутрішніх систем, у кожної своя база користувачів. Співробітник під час прийому на роботу заводився в чотирьох місцях вручну, під час звільнення його обліковий запис вимикали не скрізь.
За квартал накопичилося близько 40 «мертвих» активних записів, а служба підтримки витрачала до третини робочого часу на скидання паролів і розбір прав доступу.
Що було до впровадження
Облікові записи жили в різних системах незалежно: єдиного джерела істини не існувало, а права призначалися «на око».
Розсинхронізація проявлялася в двох сценаріях — звільнений співробітник зберігав доступ до частини систем, а переведений в інший відділ продовжував бачити дані попереднього підрозділу. Кожен такий випадок розбирали вручну, за логами відновлюючи, де і коли розійшлися записи.
Що змінили
Ми вибудували єдиний вхід на базі Keycloak як провайдера ідентифікації та підключили до нього всі внутрішні системи за стандартним протоколом. Каталог співробітників став єдиним джерелом істини: обліковий запис створюється один раз, а ролі та права роздаються через групи.
Відключення співробітника тепер закриває доступ у всіх системах одночасно — це частина процесу, а не окреме завдання адміністратора.
Що стало після
Число ручних операцій із заведення та видалення облікових записів скоротилося приблизно на 90%, а «мертвих» активних записів не залишилося взагалі. Звернення до підтримки щодо паролів упали майже втричі — співробітники входять одним набором даних.
Час на підключення нової людини до робочих систем зменшився з кількох годин до хвилин, а аудит доступу тепер займає один запит замість ручного обходу систем.
Чим відрізняється SSO від федерації удостоверений?
SSO вирішує задачу входу всередині одного периметра: користувач один раз аутентифікується в центральному сервісі та отримує доступ до застосунків, які йому довіряють.
Довіра тут будується на спільному обліковому записі та спільному сховищі — каталозі, де зберігаються логіни, групи та ролі.
Усі застосунки перебувають під одним адміністративним контролем, тому узгодження політик паролів, термінів життя сесії та вимог до багатофакторної аутентифікації відбувається всередині однієї команди.
Федерація удостоверений працює між різними доменами та різними власниками. Користувач залишається у своїй організації, а сервіс-партнер не заводить у себе обліковий запис — він довіряє твердженню про особу, яке підписане провайдером удостоверений.
Ключова відмінність: при SSO ми керуємо всіма обліковими записами самі, при федерації — лише підтверджуємо факт аутентифікації, не отримуючи доступ до пароля та профілю користувача.
Звідси різні вимоги до реалізації. Для SSO достатньо єдиного каталогу та протоколу передачі сесії між застосунками одного домену.
Для федерації потрібні метадані обох сторін, обмін ключами підпису, заздалегідь узгоджені атрибути — які саме відомості про користувача передаються і в якому вигляді. Помилка в зіставленні атрибутів призводить до того, що людина входить, але не отримує потрібних прав.
На практиці ці моделі часто поєднують. Усередині компанії розгортають SSO, а для зовнішніх партнерів і підрядників налаштовують федерацію, щоб не видавати їм облікові записи у своєму каталозі.
Межа між підходами проходить по питанню: хто володіє обліковим записом і хто відповідає за його життєвий цикл — створення, блокування та видалення при звільненні або розірванні договору.
Технічні сумніви при впровадженні SSO
Питання на етапі вибору протоколу та схеми інтеграції виникають завжди — і це нормально: від відповідей залежить, як SSO ляже на поточний ландшафт застосунків і чи не зламає вхід наявним користувачам. Нижче — те, що найчастіше обговорюємо з технічними командами до старту робіт.
Чи сумісний SSO з нашими поточними застосунками, якщо частина з них самописні?
Так, якщо застосунок уміє працювати із зовнішнім провайдером ідентифікації. Для сучасних фреймворків це штатні бібліотеки, для самописних систем — інтеграція через стандартні протоколи (OIDC або SAML).
Якщо застосунок не підтримує жодного з них, його адаптують: додають модуль перевірки токена та проброс даних користувача в сесію. Складність залежить від того, чи зберігає система власну базу паролів і ролі — це розбираємо на етапі обстеження.
Що з безпекою: чи не стане єдина точка входу слабкою ланкою?
Навпаки — SSO прибирає головну вразливість, коли користувачі тримають різні паролі або перевикористовують один. Автентифікація концентрується в одному місці, де можна увімкнути багатофакторну перевірку, обмеження за IP та журналювання входів.
Ключове — коректно налаштувати термін життя токенів та їх відкликання при виході, щоб сесія не залишалася активною в усіх застосунках після розлогіну.
Як пройде міграція — чи доведеться змушувати всіх змінювати паролі?
Не обов'язково. Облікові записи переносяться, а паролі можна синхронізувати через федерацію з поточним сховищем або залишити вхід за старим паролем на перехідний період.
Зазвичай запускаємо SSO паралельно з попереднім входом, переводимо по одному застосунку і вимикаємо стару схему, коли переконаємося, що всі сценарії входу відпрацьовують. Відкат на будь-якому кроці — повернення до попередньої конфігурації без втрати облікових записів.
Хто отримає доступ до даних користувачів і як це регулюється?
Провайдер ідентифікації зберігає лише атрибути, необхідні для входу та ролей, — решта даних залишається в застосунках. Права роздаються за групами, а не вручну, тому при звільненні або зміні ролі доступ закривається в одному місці й одразу в усіх системах.
Обговоримо ваше завдання щодо єдиного входу
Перш ніж пропонувати рішення, нам потрібно зрозуміти вашу поточну картину: які застосунки та сервіси вже використовуються, де зберігаються облікові записи, як влаштовані ролі та права доступу.
Від цього залежить, чи буде єдиний вхід надбудовою над наявним каталогом користувачів, чи потребуватиме перебудови моделі доступу.
Тому перший крок — короткий розбір завдання разом із вашою командою: які системи мають брати участь у SSO, хто і як керує користувачами сьогодні, які сценарії входу є критичними.
За підсумками розбору ми повертаємося з оцінкою та планом впровадження — з етапами, строками та зонами відповідальності. Вам не потрібно готувати детальне технічне завдання: достатньо описати завдання та поточний ландшафт, решту ми структуруємо самі.
Що ви отримаєте на старті роботи:
- Розбір поточної схеми автентифікації та точок, де вона дає збій.
- Перелік застосунків і сервісів, які увійдуть до єдиного входу, з пріоритетом підключення.
- Модель ролей і прав: хто до чого отримує доступ і як це змінюється при звільненні або переведенні.
- Варіанти реалізації SSO під ваш ландшафт — із перевагами та обмеженнями кожного.
- План міграції користувачів без простою та з можливістю відкату.
- Перелік ризиків: несумісні системи, застарілі застосунки, зовнішні підрядники.
- Оцінку строків і складу робіт за етапами.
Опишіть завдання — які застосунки потрібно об'єднати, скільки користувачів, чи є зовнішні партнери та вимоги до безпеки. Ми повернемося з оцінкою та планом впровадження, за яким можна ухвалювати рішення.
