SAML SSO для среднего бизнеса — подключаем Yandex ID, Keycloak, Azure AD

SAML — одна из тех аббревиатур, которые звучат «только для enterprise». Это не так. Компания в 50 человек на Yandex 360 для бизнеса может включить SAML SSO в HR-портал за 20 минут. Компания в 200 на Keycloak — за 10. Причина, почему большинство SMB этого не делают — не в сложности, а в незнании, что это вообще доступно.

Этот текст — недостающее руководство: что такое SAML простыми словами, четыре шага настройки и подводные камни, о которых документация умалчивает.

Что SAML реально делает

Когда вы заходите в SaaS-приложение сегодня, вы скорее всего вводите пароль (или кликаете «Войти через Google» / «Войти через Yandex»). SAML — третий вариант: «Войти через identity provider компании».

Сценарий:

1. Вы открываете dtpulse.вашакомпания.ру.
2. Портал видит что вы не залогинены. Перенаправляет браузер на ваш identity provider (Keycloak, Yandex ID for Business, Azure AD, и т.п.).
3. IdP аутентифицирует вас (пароль, MFA и т.п.) — теми методами, которые ваша компания стандартизировала.
4. IdP перенаправляет браузер обратно на портал с криптографически подписанным «assertion'ом» «да, это alice@yourcompany.ru, она в группе Engineering».
5. Портал доверяет assertion'у (проверил подпись против сертификата, который у него на руках), создаёт сессию — вы внутри.

Вы не вводили пароль в портал. Портал никогда не хранил для вас пароль. Когда вы уходите из компании, IT отключает ваш Keycloak-аккаунт; портал больше не доступен при следующей попытке входа. Никакого шага «попросить вендора SaaS удалить пользователя».

Почему это важно для среднего бизнеса

Три причины почему SMB должны настроить SAML, даже на 30 человек:

1. Гигиена офбординга. Когда кто-то уходит — вы отключаете его Keycloak/Yandex/AD-аккаунт. Он мгновенно теряет доступ ко всем SAML-интегрированным приложениям. Без SAML — каждый SaaS-инструмент нужно вручную депровиженировать, и какой-то всегда забывают. HR-система — ХУДШИЙ инструмент чтобы забыть отключить — там живут персональные данные.

2. MFA достаётся бесплатно. Настраиваете MFA в IdP один раз; каждое SAML-приложение наследует это. Без SAML — у каждого приложения свои настройки MFA, и слабейшее MFA — это MFA-история компании.

3. Переиспользование паролей перестаёт быть вашей проблемой. SAML двигает энтропию паролей в одно место, где можно нормально enforce'ить парольные политики. HR-система, project-tracker, дизайн-инструмент — ни один из них больше не видит пароля.

Цена? Однократная 20-минутная настройка per app. После этого IdP-команда управляет всем.

Настройка в 4 шага

Какой бы IdP вы ни использовали — настройка одинаковой формы. Возьму Keycloak как пример; Azure AD и Yandex ID отличаются только UI-метками.

Шаг 1: в IdP добавьте новое SAML-приложение

В Keycloak: Clients → Create → выбрать SAML. Если в IdP есть каталог — поищите DTPulse там.

IdP запросит:

• Single sign-on URL (иногда «ACS URL» или «Reply URL»): URL на портале, куда постятся SAML-assertion'ы. Документация портала это говорит. Для DTPulse: https://yourtenant.dtpulse.ru/api/auth/callback/saml.
• Audience URI (иногда «SP Entity ID»): идентификатор вашего портала в IdP. Обычно URL портала: https://yourtenant.dtpulse.ru.

Сохраните приложение. IdP вернёт вам:

• SSO URL (IdP-эндпоинт, на который ваш портал редиректит юзеров).
• Public certificate (используется порталом для верификации подписей IdP).
• IdP Entity ID (собственный идентификатор IdP).

Шаг 2: в HR-портале вставьте эти три значения

На SSO admin-странице портала есть поля «IdP SSO URL», «IdP certificate» (вставьте X.509 PEM-блок), «IdP Entity ID». Сохранить.

Если портал поддерживает, включите также:

• Just-in-time (JIT) provisioning: когда новый пользователь аутентифицируется через SAML, и его ещё нет в портале — создать автоматически. Экономит ручную работу по созданию учёток.
• Group → role mapping: например, «юзеры в Keycloak-группе HR получают роль ADMIN в портале». Если пропустите — все юзеры заходят как обычные сотрудники, и роли назначаете вручную.

Шаг 3: назначьте пользователей в IdP

В Keycloak: у нового client'а есть «Role mappings» / «Users». Добавьте users или groups (обычно — целые группы). Пользователи, которых вы тут assignите — смогут заходить через SSO.

Assignment — это enforcement: люди НЕ assigned к app в IdP не смогут войти, даже если у них есть учётка в портале. Это то, что делает офбординг чистым.

Шаг 4: тест, потом включить

Тест:

1. Зайдите как сами (вы должны быть assigned).
2. Выйдите.
3. Откройте URL портала → должны быть редирект на IdP-логин → после аутентификации попасть в портал.

Когда это работает — в портале включите «SSO required» (разные порталы называют по-разному). Это отключает password-логин для SAML-managed пользователей; теперь они ОБЯЗАНЫ ходить через SSO.

Оставьте хотя бы одну admin-учётку с password-логином как break-glass — на случай если сам IdP упадёт или будет неправильно сконфигурирован позже.

Четыре подводных камня первой настройки

1. Расхождение часов. SAML-assertion'ы подписаны и timestamped. Если часы вашего портал-сервера и IdP-сервера расходятся больше чем на пару минут — assertion'ы отбиваются как expired или future-dated. Современные хосты auto-sync NTP и обычно это не проблема, но если selfhost'ите портал на VM, которую никто не патчит — проверьте что NTP работает.

2. Сертификат однажды истечёт. IdP-cert, который вы вставили на шаге 2, имеет дату истечения — обычно 1–3 года. В день истечения SSO ломается с криптическими ошибками «signature invalid». Митигация: когда сохраняете cert, ставьте календарное напоминание за 60 дней до истечения. Хорошие порталы показывают дату истечения и email'ят админам когда она близко.

3. Несовпадение Name ID format. SAML-assertion'ы идентифицируют юзера через «name ID», который может быть email, username или другие формы. IdP и портал должны договориться. Если ваш портал ожидает nameIDFormat=emailAddress, а IdP шлёт nameIDFormat=persistent — портал не распознает юзера. Обычно у обеих сторон есть dropdown «name ID format», который надо согласовать.

4. Group claims настраиваются отдельно. Просто включение SAML-auth не означает автоматическую передачу групп. Обычно нужно добавить «group attribute statement» в IdP app-config, который включает claim groups. Без него ваш мэппинг «Keycloak HR group → portal ADMIN role» получает от чего мэппиться нечего.

Когда SAML НЕ нужен

Разумная планка: если вас меньше 15 человек и вы не используете IdP ни для чего больше — SAML overkill. Используйте встроенную password-auth портала (с включённой MFA), вернётесь когда onboard'ите 20-го человека.

Выше 25 человек аргумент гигиены офбординга начинает доминировать. Выше 50 без SSO — почти наверняка где-то есть бывший сотрудник, чья учётка в каком-то инструменте не отключена.

Что мы шипим

DTPulse SAML-интеграция: вставить IdP SSO URL + cert + entity ID, опциональный JIT-provisioning, опциональный group-to-role mapping, поддержка Keycloak / Yandex ID for Business / Azure AD / ADFS / Google Workspace / generic SAML 2.0. Предупреждение об истечении сертификата за 30 дней по email. Per-tenant config (multi-tenant SaaS) — каждый клиент управляет своей IdP-настройкой независимо. Break-glass admin-учётка всегда сохраняет password-fallback.

20-минутная настройка — то, к чему стремимся. Если у вас занимает дольше — это почти всегда один из четырёх подводных камней выше.

Связанное чтение

• On-premise vs облако HR-системы — что выбрать для российской компании в 2026
• Что такое корпоративный портал и когда он реально нужен компании