Кожен окремий логін — це ще один пароль, який доведеться скидати, і ще один обліковий запис, який треба закрити, коли людина йде. Єдиний вхід (SSO) SAML з’єднує вашу систему управління навчанням із провайдером ідентифікації, тож люди входять до навчання зі своїм робочим обліковим записом, а доступ відповідає вашому каталогу. Ось як працює SAML, як відбувається налаштування з Microsoft Entra ID, Okta або Google Workspace і що перевірити перед запуском.
Як працює єдиний вхід SAML
SAML (Security Assertion Markup Language) 2.0 — відкритий стандарт передавання даних про вхід між двома системами, які довіряють одна одній. LMS ніколи не бачить пароля людини: вона перенаправляє людину до вашого провайдера ідентифікації, який перевіряє, хто це (зокрема із застосуванням будь-якої потрібної вам багатофакторної автентифікації), і повертає її з підписаним підтвердженням.
| Термін | Що він означає |
|---|---|
| Провайдер ідентифікації (IdP) | Система, яка автентифікує ваших людей, як-от Entra ID, Okta або Google Workspace. |
| Постачальник послуг (SP) | Застосунок, до якого входять люди: ваша LMS. |
| Assertion (твердження) | Підписане XML-твердження від IdP: хто ця людина, коли вона ввійшла та які в неї атрибути, як-от пошта й ім’я. |
| Entity ID | Унікальна назва кожної сторони, часто схожа на URL, але це лише ідентифікатор. Має збігатися точно. |
| ACS URL | Assertion Consumer Service URL: адреса LMS, яка приймає відповідь IdP. |
| Сертифікат підпису | IdP підписує своїм приватним ключем; LMS перевіряє підпис за публічним сертифікатом IdP і відхиляє підроблені чи змінені твердження. |
| Метадані | XML-файл, що об’єднує entity ID, кінцеві точки та сертифікати, готовий до імпорту. |
Твердження живуть недовго й зазначають свою аудиторію (entity ID постачальника послуг). SP відхиляє все, що прострочене або призначене для іншого застосунку.
Чому SSO вартий уваги для LMS
- Жодних зайвих паролів. Люди користуються звичним обліковим записом, а ваші MFA та політики доступу поширюються і на навчання.
- Нові співробітники швидко отримують доступ. Призначте застосунок LMS групі — і нові працівники в ній зможуть увійти вже в перший день.
- Ті, хто йде, втрачають доступ на самому джерелі. Вимкніть людину у своєму каталозі, і вона не зможе розпочати новий сеанс у LMS. SAML керує входом, а не самим обліковим записом, тож під час звільнення архівуйте також обліковий запис у LMS.
Створення облікових записів «на льоту»
За створення облікових записів «на льоту» (just-in-time, JIT) LMS створює обліковий запис, коли людина входить уперше, на основі атрибутів твердження, тож імпортувати список користувачів не потрібно. Передбачте для цього запобіжники:
- Обмежте його власними доменами електронної пошти, щоб неправильно налаштований застосунок чи гостьовий обліковий запис не створював сторонніх користувачів.
- Надавайте новим обліковим записам найнижчу роль, а права адміністратора видавайте свідомо.
- Зіставляйте людей за стабільним ідентифікатором, якщо ваш IdP може його надсилати, адже адреси електронної пошти змінюються.
Вхід, ініційований SP, і вхід, ініційований IdP
- Ініційований SP: людина відкриває LMS, яка надсилає IdP запит на автентифікацію, а IdP надсилає свою відповідь на ACS URL. Це працює із закладок і посилань в електронних листах і вважається безпечнішим сценарієм, бо відповідь стосується запиту, який надіслала LMS.
- Ініційований IdP: людина натискає плитку застосунку в Microsoft My Apps, на своїй панелі Okta або в меню застосунків Google, і IdP надсилає на ACS URL відповідь, якої ніхто не запитував.
Можна запропонувати обидва варіанти; протестуйте кожен.
Налаштування SAML SSO крок за кроком
Послідовність скрізь приблизно однакова:
- Визначте обсяг: хто користується SSO, які групи отримують застосунок, які домени електронної пошти дозволено й який атрибут ідентифікує кожну людину.
- Створіть підключення в LMS і занотуйте його entity ID та ACS URL.
- Створіть застосунок SAML у вашого IdP з цими значеннями, виберіть формат NameID і додайте атрибути електронної пошти, імені та прізвища.
- Призначте користувачів або групи; непризначених людей зазвичай не пускають.
- Передайте LMS дані IdP: URL метаданих, файл метаданих або entity ID IdP, URL входу й сертифікат підпису.
- Зіставте атрибути з іменами, які ваш IdP справді надсилає.
- Протестуйте, потім увімкніть і повідомте людям, що змінюється.
Примітки щодо провайдерів
Точні екрани описано в документації вашого провайдера. Варто знати таке:
- Microsoft Entra ID: використовуйте корпоративний застосунок не з галереї, а не реєстрацію застосунку (app registration), яка не пропонує SAML. Назви claim — це довгі URI, тому копіюйте їх точно. Object ID добре підходить як стабільний ідентифікатор. Для людей без поштової скриньки claim електронної пошти може бути порожнім; замість нього можна використати user principal name, якщо це справжня адреса.
- Okta: створіть інтеграцію застосунку SAML 2.0. Назви атрибутів у твердженнях ви задаєте самі, тож вони мають точно збігатися із зіставленням у LMS, зокрема за регістром. Внутрішній ID користувача в Okta слугує стабільним ідентифікатором.
- Google Workspace: додайте власний застосунок SAML і завантажте його файл метаданих. Застосунок спершу вимкнено, тож увімкніть його для потрібних організаційних підрозділів чи груп. У типовому налаштуванні людей ідентифікують за основною адресою електронної пошти, тому враховуйте перейменовані та повторно використані адреси.
Чек-лист тестування
Перед запуском перевірте це в приватному вікні браузера:
- Наявний користувач входить, починаючи з LMS, і ще раз — з плитки застосунку.
- Новий користувач у вашому домені отримує обліковий запис із правильною роллю.
- Людині, яку не призначено до застосунку, відмовлено.
- Людині поза дозволеними доменами відмовлено.
- Електронна пошта, ім’я та прізвище надходять правильно.
- Адміністратор і надалі може увійти запасним шляхом.
Поширені помилки
Розбіжність годинників
Якщо годинники IdP і LMS розходяться більше, ніж припускає LMS, справні твердження відхиляються як такі, що ще не діють або вже прострочені. Це здебільшого стосується серверів ідентифікації на власному обладнанні, тож тримайте їхні годинники синхронізованими.
Заміна сертифіката
Сертифікати підпису IdP закінчуються, і якщо LMS не довіряє заміні, усі входи одразу припиняються. Занесіть дату завершення до календаря. Якщо ваша LMS може довіряти двом сертифікатам, спершу додайте туди новий, а потім активуйте його в IdP; інакше змініть обидві сторони одночасно в тихий час. Протестуйте одразу.
Зіставлення атрибутів
Назви атрибутів зазвичай зіставляються точно: LMS, яка очікує email, не прийме Email. Перевірте й ідентифікатор. Тимчасовий (transient) NameID змінюється в кожному сеансі, а адреса електронної пошти може змінитися; постійний (persistent) NameID або незмінний атрибут ID є стабільними. Якщо людей зіставляють за поштою, архівуйте обліковий запис тих, хто йде, доки їхню адресу не передали комусь іншому.
Невідповідність домену пошти
У каталогах часто є люди, чиє ім’я для входу не збігається з адресою електронної пошти, підрядники з інших доменів і працівники придбаних компаній, які досі мають старі домени. Якщо LMS обмежує облікові записи певними доменами, їм відмовляють. Перелічіть усі домени до запуску.
Як це робить Acadenix
SAML SSO доступний у тарифі Gold, з покроковими інструкціями для Entra ID, Okta і Google Workspace.
- Спершу тест, потім активація. Ви зберігаєте дані свого IdP як чернетку, запускаєте Test configuration (перевірка конфігурації), входячи у свого провайдера, і лише потім активуєте. Про відсутній claim електронної пошти повідомляється з назвами claim, які ваш провайдер таки надіслав.
- Поетапні зміни. Новий сертифікат чи тенант додається як оновлення конфігурації, а поточна конфігурація працює, доки ви його не активуєте.
- JIT у межах ваших доменів. Людина без облікового запису отримує обліковий запис слухача під час першого входу, лише якщо її електронна пошта належить до доменів реєстрації вашої організації, і це можна вимкнути. Коли людина, яка вже має обліковий запис в Acadenix, уперше входить через ваш IdP, Acadenix надсилає їй на пошту одноразовий код, щоб підтвердити зв’язок. Це трапляється один раз для кожної людини.
- Обидва способи входу. Люди можуть починати зі сторінки входу, яка може одразу перенаправляти до вашого IdP або показувати кнопку, або з плитки в My Apps, Okta чи Google.
- Одне підключення — одна організація. Підключення SAML не передається організаціям, що розташовані нижче за його власника, і це важливо для груп із багатьма майданчиками.
- Запасний шлях. Якщо ваш IdP не працює, адміністратори все одно можуть увійти за одноразовим кодом із листа, і це не можна вимкнути.
Крім SAML, люди можуть входити за кодом із листа або через обліковий запис Google, Microsoft чи LinkedIn. Докладніше — на нашій сторінці безпеки.
Головне
- Обміняйтеся entity ID, ACS URL і метаданими, потім зіставте стабільний ідентифікатор і підтверджену адресу електронної пошти.
- Обмежуйте облікові записи, створені «на льоту», власними доменами й найнижчою роллю.
- Перед запуском протестуйте обидва сценарії входу, відмови й запасний шлях.
- Занесіть дату завершення сертифіката до календаря й архівуйте облікові записи тих, хто йде, у LMS.
Хочете підключити Acadenix до свого провайдера ідентифікації? Порівняйте тарифи на нашій сторінці з тарифами або поговоріть з нами про ваше налаштування.
