Налаштування SSO (единого входу) для Bitrix24
Співробітник приходить вранці на роботу, логінується в Windows, відкриває пошту — ще один пароль, заходить у Jira — третій пароль, потім Bitrix24 — четвертий. Паролі забуваються, скидаються, записуються на стікерах. IT-відділ витрачає час на скидання паролей замість корисної роботи. SSO (Single Sign-On) вирішує проблему: один вхід — доступ до всіх систем. Співробітник авторизується через корпоративний Identity Provider, а Bitrix24 приймає цю авторизацію без власного логіна/пароля.
Протокол SAML 2.0
Bitrix24 підтримує SSO через SAML 2.0 — стандартний протокол федеративної аутентифікації. Схема роботи:
- Користувач відкриває Bitrix24.
- Б24 перенаправляє на Identity Provider (IdP) — Azure AD, Keycloak, ADFS.
- Користувач аутентифікується на IdP (або вже аутентифікований через Kerberos).
- IdP повертає SAML-assertion — підписаний XML-документ з даними користувача.
- Б24 перевіряє підпис, витягує атрибути, створює або оновлює сесію.
Для хмарної Б24 SAML SSO доступен на тарифах Професійний та Енергопривід. Для коробки — через модуль SSO.
Налаштування на стороні Identity Provider
Незалежно від конкретного IdP, потрібно зареєструвати Bitrix24 як Service Provider (SP):
| Параметр SP | Значення |
|---|---|
| Entity ID | https://your-domain.bitrix24.by |
| ACS URL | https://your-domain.bitrix24.by/bitrix/tools/saml/acs.php |
| SLS URL | https://your-domain.bitrix24.by/bitrix/tools/saml/sls.php |
| NameID Format | urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress |
Azure AD — реєстрація Enterprise Application, налаштування SAML-конфігурації, завантаження Federation Metadata XML. Правила заявок: user.mail → NameID, user.displayname → Name, user.department → Department.
Keycloak — створення клієнта з протоколом SAML, вказівка Valid Redirect URIs, налаштування mappers для атрибутів. Keycloak зручний для компаній, які хочуть тримати IdP на своєму сервері.
ADFS — додавання Relying Party Trust, налаштування Claim Issuance Policy. Для ADFS типова ситуація, коли сертифікат підпису закінчується — потрібно стежити за термін і оновлювати в параметрах Б24.
Обмін сертифікатами
SAML працює на довірі між SP та IdP, підтвердженому сертифікатами:
- Сертифікат IdP — завантажується в параметри SSO Bitrix24. Б24 використовує його для перевірки підпису SAML-assertions. При ротації сертифіката на IdP потрібно оновити його в Б24, інакше авторизація сломається.
- Сертифікат SP (необов'язково) — якщо IdP вимагає підписані AuthnRequest. Генерується в параметрах Б24 і завантажується в IdP.
Рекомендація: при ротації сертифіката на IdP підтримувати обидва сертифікати (старий і новий) протягом переходного періоду.
Маппінг атрибутів користувача
SAML-assertion містить атрибути користувача. Б24 витягує їх і заповнює профіль:
- NameID (email) → логін користувача в Б24
- FirstName / LastName → ім'я та прізвище
- Department → відділ (при наявності маппінга на структуру Б24)
- Groups → групи та ролі (для автоматичного призначення прав)
Якщо користувача з таким email немає в Б24 — він створюється автоматично при першому вході (провізіонування через SSO). Це налаштовується: можна дозволити автоствворення або вимагати попередню реєстрацію.
Що налаштовуємо
- Реєстрація Bitrix24 як Service Provider у корпоративному IdP
- Налаштування SAML 2.0 на стороні Azure AD, Keycloak або ADFS
- Обмін сертифікатами і налаштування довіри між SP та IdP
- Маппінг атрибутів: email, ім'я, відділ, групи
- Автоматичний провізіонування користувачів при першому SSO-вході
- Тестування та відладка SAML-потоку, діагностика помилок авторизації