SSO в корпоративный портал — как объединить 1 200 сотрудников за неделю и не сломаться

Корпоративный портал, в который пользователи заходят отдельным логином и паролем — это автоматически мёртвый портал. По данным наших клиентов, DAU таких порталов опускается ниже 30% в течение трёх месяцев после запуска. Простая причина: ещё один пароль, который никто не помнит, ещё одна вкладка, которую закроют.

Эта статья — для IT-директора, который выбирает или внедряет интранет, и для HR-директора, которому интересно, что технически нужно сделать, чтобы запустить портал «по-взрослому». Без жаргона, но без упрощений: SSO — это решение из десятка маленьких решений, и каждое стоит понимать.

Разбираем по слоям: зачем SSO нужен в принципе, какие протоколы выбирать в 2026-м, как настроить JIT-провизионинг, где роль кастомного домена, и что такое 5-дневный playbook развёртывания.

Зачем SSO — три причины, не одна

SSO часто продают как «фишка для безопасников». На самом деле это решение трёх разных задач, и недооценивать любую из них — ошибка.

Первая — UX. Сотрудник заходит в почту, в чат, в task-tracker, в облачное хранилище — везде через корпоративную учётную запись. Если портал требует отдельного логина, он выбивается из этого ряда. Это и есть причина тех самых 30% DAU. Один логин для всех — это не «удобно», это минимально приемлемо в 2026-м.

Вторая — безопасность. Один пароль защищать проще, чем десять. Если у сотрудника есть отдельный логин в портале, он, скорее всего, поставит «qwerty2024» и не будет менять год. Если все системы за SSO — пароль один, защищается централизованно (двухфакторкой, регулярной ротацией, политикой сложности), и компрометация пароля портала автоматически становится инцидентом всего стека, не отдельного приложения.

Третья — прозрачность увольнений. Когда сотрудник уходит, его учётка в IdP блокируется, и в ту же минуту он теряет доступ ко всем системам, включая портал. Без SSO у вас есть список из 15 мест, где надо вручную убрать пользователя — и в большинстве компаний этот список никогда не выполняется до конца. Бывшие сотрудники остаются в портале месяцами, а иногда годами, что уже формальное нарушение требований по защите данных.

Эти три причины — не альтернативы, а слои. SSO нужен для всех трёх одновременно, и решение «у нас пока без SSO, добавим потом» обычно превращается в «у нас уже год портал работает, и SSO так и не собрались».

SAML vs OIDC vs LDAP — что выбрать в 2026

Три основных протокола, которые встретятся при настройке. Базовая разница важна.

LDAP — старый протокол, который выживает в инфраструктурах с давним Active Directory. Если у вас всё уже на AD — портал может в него интегрироваться, но это compromise. LDAP плохо работает с мобильными клиентами и почти не работает с распределёнными командами. В новых внедрениях избегайте.

SAML 2.0 — стандарт корпоративных интеграций последние 15 лет. Большинство IdP (Okta, Azure AD, Google Workspace, Keycloak, ADFS) поддерживают его как минимум. Сложен в интеграции, XML-based, но надёжен и проверен. В крупных компаниях с зрелой ИБ — часто требование.

OIDC (OpenID Connect) — современный протокол, построен поверх OAuth 2.0, использует JSON и JWT-токены. Простой в интеграции, изначально под мобильные клиенты, легко масштабируется на разные приложения. Все новые SaaS-продукты (включая нас) первой опцией предлагают OIDC.

Наша рекомендация на 2026-й:

• Первый выбор — OIDC. Если ваш IdP его поддерживает (а почти все современные поддерживают), берите его.
• Запасной вариант — SAML 2.0. Если у вас старый IdP без OIDC, или ИБ требует SAML по корпоративным стандартам.
• LDAP — только если иначе никак. Например, у вас on-prem AD без современной обвязки.

Хороший корпоративный портал должен поддерживать все три протокола, чтобы не диктовать клиенту, как ему быть с инфраструктурой. Но новый клиент — почти всегда OIDC.

JIT Provisioning — без ручного импорта пользователей

Самая болезненная часть классического онбординга в портал — ручная заводка пользователей. HR пишет в IT «вот список из 12 новых сотрудников, заведите их в портал», IT через 2 дня заводит, HR проверяет, что половина забыта, IT доводит, при этом текучка идёт дальше.

Решение — Just-In-Time provisioning. Пользователь создаётся в портале в момент первого SSO-входа, на основе данных из IdP. Никаких списков, никаких писем, никакого ручного импорта.

Что мапится при JIT:

• Имя — из IdP (given_name, family_name или name).
• Email — основной идентификатор.
• Подразделение — из атрибута IdP (например, department в Azure AD, или из членства в группе).
• Должность — из атрибута IdP (jobTitle).
• Роль в портале — на основе членства в группе IdP. Если человек в группе hr-team — он получает роль HR-менеджера. Если в tech-managers — Тимлид. Если ни в одной — значение по умолчанию.
• Фото — из Microsoft Graph, Google Directory или аналога.

Граничные случаи (edge cases), которые надо продумать заранее:

• Что делать, если у пользователя нет ни одной маппируемой группы. Дефолтная роль (обычно «Сотрудник»). Никакого «нельзя войти, обратитесь к админу» — это тот же самый барьер, что и ручная заводка.
• Что делать, если атрибут department отсутствует. Раздел «Без отдела» — лучше, чем ошибка входа.
• Что делать, если изменения в IdP пришли (например, перевели в другой отдел). На каждом входе пересинхронизировать атрибуты — это позволяет быстро корректировать роли без ручного вмешательства.

JIT — не приятная мелочь. На команде в 100+ человек ручной провизионинг — это +1 человек в IT-команду, который ежедневно занимается списками. JIT убирает эту работу полностью.

Принудительный SSO и кастомный домен

Две детали, которые часто откладываются «на потом», но именно они отличают зрелое внедрение от пилотного.

Принудительный SSO (enforce_sso). Это переключатель в админке портала: «email + пароль больше не разрешены, только через IdP». Зачем нужно: без принудительного режима у вас в системе всё равно создаются orphan-аккаунты — пользователи, которые когда-то залогинились по паролю, потом пользуются ими, обходя SSO. Через год у вас в базе 30 «теневых» пользователей, которых не видит IdP, и про которых HR не знает. С принудительным SSO такого не происходит — все ходят через SSO, и SSO — единственная точка контроля.

Включается обычно в один клик после стабилизации SSO-потока (чтобы не отрезать кого-то, у кого настройка не доехала). Хорошая практика — две недели гибридного режима (SSO + пароль), затем принудительный режим.

Кастомный домен. portal.yourcompany.ru вместо yourcompany.teamhero.ru. Кажется, мелочь — но влияет на восприятие.

Почему это важно:

• Доверие. Сотрудник, который видит вкладку с доменом своей компании, доверяет ей по умолчанию. Сторонний домен SaaS-вендора — психологически чуть-чуть «не моё».
• Согласованность. В корпоративной документации, в email-приглашениях, в onboarding-материалах ссылки выглядят как portal.yourcompany.ru/... — это смотрится как часть инфраструктуры компании.
• Управление в случае смены вендора. Если когда-то понадобится мигрировать — DNS переключается, пользователи продолжают ходить на тот же домен.

Технически: TXT-запись для подтверждения владения, CNAME на инфраструктуру вендора, автоматический выпуск SSL-сертификата (Let's Encrypt или эквивалент). У зрелых вендоров это занимает 30 минут от начала до работающего домена.

Кейс развёртывания за 5 рабочих дней

Стандартный playbook, который мы предлагаем клиентам с командой 500–1 500 человек: пятидневный график развёртывания Azure AD / Keycloak / Yandex 360, в типовом сценарии — без серьёзных инцидентов. Это не «маркетинговая обещалка»: SSO считается одной из самых предсказуемых интеграций в корпоративных системах — по опросу Gartner 70% компаний называют главным эффектом SSO улучшение пользовательского опыта, 61% — снижение тикетов в IT-поддержку.

День 1 (понедельник). Стартовая встреча с IT-командой клиента: выбор IdP (в нашем случае Azure AD), формат атрибутов, маппинг ролей. Час разговора — выходим с готовым техзаданием.

День 2. Создание OIDC-клиента в Azure AD, настройка callback URL, регистрация в портале. Тест с 3 пользователями (обычно — IT-директор, HR-директор и один доброволец). На этом этапе ловим самые очевидные проблемы (неправильный scope, отсутствие атрибута).

День 3. Настройка JIT-маппингов: какой атрибут IdP — какое поле в портале, какая группа IdP — какая роль. Граничные случаи (без группы → дефолт, без отдела → «Без отдела»). Проверка ещё на 5–10 пользователях.

День 4. Пилот на одном отделе (~30 человек). Команда отдела ходит в портал через SSO в течение дня, собираем все мелкие баги (атрибут не дошёл, фото не подгрузилось, роль не та). Чиним.

День 5 (пятница). Раскатка на всю компанию. Email-уведомление сотрудникам — «теперь портал работает через ваш корпоративный логин». Старая аутентификация по email+паролю остаётся включённой на 2 недели как запасной вариант. Через 2 недели — включается принудительный SSO, старые логины отключаются.

Типичный итог такого пятидневного развёртывания: через 2 недели — принудительный режим, через месяц — DAU портала заметно растёт. Эффект объясняется снижением барьера входа: один корпоративный логин против отдельного пароля, который сотрудник забывает. Это согласуется с индустриальными наблюдениями, что после SSO падают тикеты «забыл пароль» и растёт частота входов в системы, которые раньше использовались эпизодически.

Главное

SSO — это не «фишка для безопасников», это базовая инфраструктура корпоративного портала. Без него портал теряет 50–70% потенциального DAU и создаёт хвост orphan-аккаунтов после увольнений.

Три практических вывода для 2026-го:

• Предпочитайте OIDC. Современнее, проще, мобильнее. Если IdP позволяет — никаких SAML.
• JIT-провизионинг обязателен. Никаких ручных списков. Пользователь создаётся при первом входе, роль определяется группой IdP.
• Кастомный домен с первого дня. portal.yourcompany.ru — это не косметика, это базовое доверие сотрудника к системе.

И отдельный пункт: если внедряете в команде больше 100 человек — закладывайте 5 рабочих дней на SSO с момента стартовой встречи. Меньше — оптимистично, больше — обычно затяжка из-за внутренних согласований ИБ. Пять рабочих дней — это реалистичный, проверенный ориентир.

На следующей неделе — про 152-ФЗ и AI в HR-tech: что можно и нельзя в 2026-м, и как пройти compliance-проверку перед закупкой AI-системы.

Если нужен подробный технический one-pager про SSO под ваш конкретный IdP (Azure AD, Okta, Keycloak, Yandex 360, ADFS) — напишите нам, пришлём целевой документ с примерами конфигурации.

---

Если у вас сегодня корпоративный портал работает с email+паролем, или вы только выбираете решение и хотите понять, как у нас устроено SSO — напишите, проведём 30-минутное техническое демо.