- Загальна інформація з технології
- Базова інформація щодо інтеграції
- Приклад 1: HDE + OneLogin
- Приклад 2: HDE + Okta
- Режим налагодження в HDE
- Атрибути, що настроюються: departments_ids, custom_group_id, custom_departments_ids. Мапінг груп та департаментів.
1. ЗАГАЛЬНА ІНФОРМАЦІЯ
SSO (Single Sign-On) - технологія єдиного входу користувачів, завдяки якій володіючи одним лише обліковим записом користувач може відвідувати безліч різних сервісів.
SAML - це популярний XML-протокол для реалізації SSO. Як правило, використовується у великих організаціях (enterprise) як перевірений і надійний варіант. В організаціях де централізовано ведеться актуальна база користувачів, запроваджуються свої політики безпеки тощо. Відповідно і доступ до контенту в сервісі стає безпечнішим і контрольованим.
В аутентифікації через SAML SSO бере участь три сторони:
- SAML identity Provider (IdP)
- SAML Service Provider (SP)
- браузер користувача (User Agent)
Сама схема взаємодії представлена на малюнку нижче:
Докладніше з технологією можна ознайомитись на просторах інтернету.
2. БАЗОВА ІНФОРМАЦІЯ
- Логін відбувається поштою, NameID описаний в metadata
- Є 3 кастомні параметри (необов'язкові, якщо не вказати - вони не оновлюватимуться):
- group_id - число, що дозволяє змінювати групу на авторизації
- organization - рядок, організація змінюється на авторизації
- name - рядок, повне ім'я, може змінюватися на авторизації
Авторизувати можна двома способами:
- логін із системи - додаткова кнопка входу до системи на формі входу:
- авторизація із самого сервісу:
3. Приклад підключення інтеграції через сервіс OneLogin (onelogin.com)
На даний момент виконати інтеграцію з EddyDesk можливо через настроювання та підключення тестового конектора SSO SAML, наданого сервісом OneLogin. У планах є додавання власної програми-конектора EddyDesk і інтеграція таким чином спроститься до декількох кліків.
1. Створюємо обліковий запис у сервісі OneLogin (пошта може бути тільки в корпоративному домені, жодних gmail або mail.ua)
2. Переходимо до Адміністрування:
3. І додаємо додаток:
4. Шукаємо в пошуку по saml test і вибираємо SAML Test Connector (Advanced):
5. Далі необхідно буде задати назву конектора, за необхідності його опис та зберегти:
6. Після збереження доступні інші налаштування конектора.
Зачепимо основні налаштування, що стосуються інтеграції з EddyDesk.
Налаштування на стороні сервісу OneLogin, які беруться з ED (SP):
- RelayState (необов'язкове) - посилання для перенаправлення у випадку якщо авторизація була з сервісу. Можна залишати порожньою, а можна, наприклад, вказати пряме посилання на Омніканальність або КБ (якщо є необхідність).
- Audience (EntityID) - поле куди вставляємо metadata з ED, він же "Audience Restriction" вставляємо поле "Audience (EntityID)" з SSO з'єднання в ED.
- Recipient - приймач викликів на логін, він же - "Single Sign On URL" або "ACS" або "Assertion consumer service URL", в це поле вставляємо "Assertion consumer service URL (ACS)" з ED.
- ACS (Consumer) URL Validator* – валідатор посилання (захист). За умовчанням ставимо .* (крапка + зірочка)
- ACS (Consumer) URL* – виклик на логін від сервісу. У цьому полі додаємо "Assertion consumer service URL (ACS)" з ED.
- Single Logout URL – посилання для виклику на logout (вихід), це "Single logout URL" з ED. На це посилання йде виклик при виході з сервісу на тлі (скрізь працює по-різному). Також на це посилання переходить користувач після успішного виходу через кнопку логауту ED
Ці дані беруться з EddyDesk, створивши SSO з'єднання:
Налаштування на стороні ED (ldP), які беруться з OneLogin (Applications - Connector - SSO):
Використана термінологія Onelogin, поля вказані цифрами для зручності
- Issuer URL - мета інформація, за цим посиланням знаходяться всі потрібні точки для з'єднання. В ED поле називається також.
- SAML 2.0 Endpoint (HTTP) - посилання, за яким ED направляє користувача для авторизації в сервісі. В ED поле називається також.
- SLO Endpoint (HTTP) - посилання, за яким ED відправляє вихід із системи. В ED поле називається також.
- Сертифікат - є й інші методи захисту, але на поточний момент в ED використовується тільки X.509 Certificate
Додаємо ці дані в SSO з'єднання ED:
7. Кастомні поля ED + OneLogin:
4. Приклад підключення інтеграції через сервіс Okta (okta.com)
1. Реєструємося, заходимо в обліковий запис і створюємо додаток:
Налаштування Okta:
1) Single sign on URL - посилання на вхід у сервіс, це "Assertion consumer service (ACS)" в ED. Якщо галочку тут не ставимо - з'явиться ще одне поле Recipient URL - його теж можна заповнити тим самим посиланням.
2) Audience URI (SP Entity ID) - методату, вставляємо поле "Audience (EntityID)" з ED.
3) Single Logout URL - okta не цікаві виходи з боку ED. АЛЕ вони можуть викинути користувача з системи коли виходиш з їхньої програми, відповідно налаштування за бажанням (можна не використовувати) - поле Single logout service (SLS) з ED. Оскільки Okta не підтримує повноцінно SLO, можна вставити посилання із закінченням /slo замість /sls . Різниця буде в тому, що користувач одразу вилетить із системи, а якщо на стороні ED посилання SLO не вказано - просто відбудеться перехід на старт ED.
4) SP Issuer - поле Single logout service (SLS) з ED. Він обов'язковий якщо використовується SLO.
5) Сертифікат, його потрібно завантажити, якщо використовуємо SLO і закинути в 6 пункт.
6) Поле завантаження сертифіката пункту 5.
Налаштування в ED.
Необхідні для внесення настройок на стороні ED можна знайти в налаштуваннях створеної програми:
1) RelayState - це поле можна не вказувати. Якщо вказати - туди буде перенаправлений користувач після авторизації в ED.
2) Посилання на методату та сертифікат. При переході на View Setup Instructions відкриються необхідні нам дані (див. наступний скріншот)
далі переходимо до інструкції.
3) Ставимо email.
View Setup Instructions:
2.1) Identity Provider Single Sign-On URL = SAML 2.0 Endpoint (HTTP) в ED
2.2) Identity Provider Single Logout URL = SLO Endpoint (HTTP) в ED
2.3) Identity Provider Issuer = Issuer URL в ED
2.4) Сертифiкат - вставляємо сертифікат в ED
Після збереження налаштувань та додавання користувачів для даної програми вийде в систему через сервіс Okta:
5. РЕЖИМ НАЛАДЖЕННЯ В ED
При активації режиму налагодження в лог при авторизації будуть записані атрибути, що передаються.
Може бути помічником при налаштуванні нових підключень, відображаючи яка саме інформація надходить у ED.
Приклад:
Активується за кнопкою Режим налагодження у підключенні SSO у HDE
6. НАЛАШТОВАНI АТРИБУТИ
departments_ids - можливість задати список доступів до департаментів. Сприймає масиви. Передаються ID департаментів у ED.
Мапінг груп та департаментів:
Одну групу або департамент можна визначити за різними ролями, або навпаки, різні ролі з SSO можуть призначати ту саму групу в ED.
Активується за кнопкою - Увімкнути атрибути, що настроюються.
розділювач багатозначного атрибута - параметр використовується, якщо передача рядкова, наприклад розділювач кома і передається рядок "role,role2,role3". Якщо передається не рядок - буде читатись тільки перший параметр і буде спроба його поділити.
custom_group_id - дозволяє призначити групу користувачу залежно від ролей SSO. Працює за першим збігом ролі із SSO. Тут важливий порядок виставлених пар група - роль HD
Тобто при передачі custom_group_id = "admin;manager;operator" користувач отримає групу Співробітник, т.к. вона більш пріоритету у списку.
custom_departments_ids – дозволяє виставити доступи до департаментів на підставі ролей SSO. Додає всі департаменти всіх переданих ролей. Порядок значення немає.
Тобто. при передачі custom_departments_ids = "operator;manager" користувач отримає доступи до 7 департаментів, тобто. для обох збігів за "департаментами - роль".
Приклад налаштувань на стороні OKTA.
У налаштуваннях програми в розділі SAML Settings додаємо оголошення змінних і вказуємо на які змінні вони повинні посилатися - https://support.okta.com/help/s/article/How-to-define-and-configure-a-custom-SAML-attribute-statement?language=en_US
Попередньо ці самі поля необхідно буде створити:
І відповідно прописати потрібні значення для облікових записів: