Реализация SSO (Single Sign-On) для веб-приложения

SSO для веб-приложения: где ломается вход и права

Единый вход (SSO) перестаёт быть «просто кнопкой входа», когда в компании несколько систем: каталог сотрудников, внутренний портал, CRM, склад, бухгалтерия. Каждая живёт своей базой учётных записей, и стоит человеку уйти или сменить роль — права остаются висеть в трёх-четырёх местах. Аутентификация формально работает, но вход в одну систему уже открывает лишнее в другой.

Первый типовой сбой — рассинхрон учётных записей. Сотрудника завели в каталоге, но не завели в приложении, или наоборот: уволенный продолжает заходить по старому токену, потому что сессия живёт дольше, чем запись в справочнике. Второй — ручные сбросы паролей: поддержка тратит часы на «не пускает в личный кабинет», хотя проблема в истёкшем сертификате или сбитом времени на сервере.

Третий сбой — дублирование входов. Пользователь заводит второй аккаунт под другой почтой, и в отчётах появляются две «одни и те же» сущности с разными правами. Четвёртый — рост нагрузки на поддержку: чем больше систем, тем больше обращений, и каждая новая интеграция добавляет свою точку отказа.

Разбираем, как это закрывается: единая точка аутентификации, синхронизация справочника и правила отзыва доступа.

Что даёт единый вход: эффект в цифрах

Единый вход измеряется не удобством «в целом», а тремя метриками: время доступа к приложению, доля обращений в поддержку, связанных с доступом, и число инцидентов с паролями. До внедрения сотрудник тратит на вход в каждую систему от 20 до 40 секунд — ввод логина, ожидание проверки, повтор при ошибке. При десяти рабочих сервисах это десятки минут в неделю на человека, и потери растут линейно с числом приложений.

Основной эффект — исчезновение класса ошибок, связанных со сбросом пароля. По нашей практике, сброс и восстановление доступа дают от 20 до 40 процентов всех обращений в поддержку. После перевода на единый вход пользователь проходит проверку один раз через корпоративную учётную запись, а приложение получает подтверждённую сессию. Обращения по паролям падают в разы — поддержка переключается на задачи, которые действительно требуют человека.

Время входа сокращается до одной проверки на старте рабочего дня: дальше переходы между сервисами происходят без повторной аутентификации. Для сценариев с повышенными требованиями к безопасности мы настраиваем повторное подтверждение только на критичные операции, а не на каждый переход — защита сохраняется, трение уходит. Отдельно закрывается вопрос увольнений и смены ролей: доступ отзывается в одной точке, а не в десяти админках.

Мы работаем с проверенными протоколами федеративной аутентификации и стандартными корпоративными каталогами — Keycloak как один из вариантов брокера, если нужен полный контроль над инфраструктурой. Это даёт предсказуемую интеграцию с существующим каталогом пользователей без переписывания приложений. Эффект фиксируем до и после: замеряем время входа, считаем долю обращений по доступам, отслеживаем число инцидентов с паролями.

Способы реализации SSO: сравнение подходов

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

На что смотреть при выборе

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

Отдельно проверяем сопоставление ролей и групп: атрибуты из каталога должны раскладываться в права приложения без ручной синхронизации. Если роли ведут в двух местах, рано или поздно они разойдутся, и доступ получит не тот, кому он предназначен.

Что учесть по ограничениям

Прокси-шлюз экономит время на старте, но добавляет точку отказа и усложняет отладку: приложение перестаёт видеть реальный контекст пользователя. SAML надёжен в корпоративной среде, однако каждое новое приложение требует отдельной настройки метаданных. OpenID Connect гибче, но перекладывает часть ответственности за безопасность токенов на команду разработки.

Мы разбираем ваш ландшафт систем и предлагаем подход, который не придётся переделывать при росте числа приложений. Опишите задачу — вернёмся с оценкой и планом.

Этапы внедрения единого входа в продукт

Внедрение SSO — это не «подключить библиотеку», а заменить способ подтверждения личности во всех точках входа, не потеряв ни одного пользователя и не открыв дыру в доступах. Поэтому начинаем не с кода, а с инвентаризации: какие приложения и сервисы уже используют аутентификацию, где хранятся учётные записи, какие протоколы поддерживает каждый компонент и кто владелец каждого доступа. Без этой карты любая настройка превращается в лотерею.

Как устроен процесс

1. Аудит текущей аутентификации. Собираем реестр приложений, внешних сервисов и интеграций, фиксируем, где вход локальный, где через сторонний провайдер, где доступы выданы вручную. Отдельно помечаем сервисы, которые протокол единого входа не поддерживают, — для них заранее планируем обходной путь.
2. Выбор сценария и провайдера. Определяем, кто выступает источником истины об учётных записях: корпоративный каталог, внешний провайдер или собственная база. От этого зависит схема сопоставления пользователей и правила, по которым права из каталога попадают в приложения.
3. Настройка провайдера и приложений. Регистрируем каждое приложение у провайдера, настраиваем доверенные адреса возврата, сроки жизни сессий и токенов, сопоставление атрибутов. Здесь же закладываем выход из всех систем одним действием — иначе единый вход остаётся половинчатым.
4. Проверка на тестовом контуре. Прогоняем сценарии: первый вход нового пользователя, повторный вход, смена роли в каталоге, отзыв доступа, истечение сессии, недоступность провайдера. Каждый сценарий проверяем на всех типах учётных записей, включая служебные.
5. Миграция пользователей. Переносим учётные записи и связи с ролями, на переходный период оставляем оба способа входа, чтобы никто не потерял доступ. Локальные пароли отключаем только после того, как убедились, что все вошли через единый вход.
6. Передача в эксплуатацию. Фиксируем регламент: как добавлять новое приложение, как отзывать доступ при увольнении, кто отвечает за провайдера. Настраиваем журналирование входов и оповещения об аномалиях.
7. Сопровождение. Периодически пересматриваем список подключённых сервисов и правила сопоставления — состав систем меняется быстрее, чем кажется.

Опишите вашу текущую схему входов — вернёмся с оценкой и планом работ.

Что остаётся у заказчика после внедрения

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

• Конфигурации сервиса идентификации — параметры подключения приложений, настройки сессий и токенов, правила выпуска и обновления учётных данных. Всё в системе контроля версий, с историей изменений и возможностью отката.
• Схемы потоков аутентификации — как пользователь проходит вход, где происходит проверка прав, как приложение получает подтверждение личности. Схемы описывают и штатный сценарий, и поведение при недоступности провайдера.
• Политики доступа — привязка ролей и групп к приложениям, правила наследования прав, порядок назначения и отзыва доступа при приёме, переводе и увольнении сотрудника.
• Регламенты эксплуатации — как добавить новое приложение, как подключить внешнего подрядчика, что делать при сбое входа и куда смотреть в первую очередь. Пошагово, с ответственными и точками контроля.
• Документация — описание архитектуры, перечень подключённых систем, справочник по настройкам, журнал изменений. Рассчитана на инженера, который откроет её через полгода без нас.
• Инструкции для службы поддержки — типовые обращения по входу и восстановлению доступа, готовые ответы и граница, за которой подключается техническая команда.
• Доступы и права администраторов — разделение ролей на управление пользователями и на изменение конфигурации, чтобы повседневные операции не требовали полных прав.

Такой комплект снимает главный риск: когда SSO начинает жить своей жизнью, у вас есть и карта местности, и рычаги управления. Опишите вашу задачу — вернёмся с оценкой и планом, включая состав передаваемых артефактов.

Кейс: как мы устранили рассинхрон учётных записей

Клиент — сервисная компания с распределённой командой — пришёл с классической болью: несколько внутренних систем, у каждой своя база пользователей. Сотрудник при приёме заводился в четырёх местах вручную, при увольнении его учётку отключали не везде. За квартал накопилось около 40 «мёртвых» активных записей, а служба поддержки тратила до трети рабочего времени на сбросы паролей и разбор прав доступа.

Что было до внедрения

Учётные записи жили в разных системах независимо: единого источника истины не существовало, а права назначались «на глаз». Рассинхрон проявлялся в двух сценариях — уволенный сотрудник сохранял доступ к части систем, а переведённый в другой отдел продолжал видеть данные прежнего подразделения. Каждый такой случай разбирали вручную, по логам восстанавливая, где и когда разошлись записи.

Что изменили

Мы выстроили единый вход на базе Keycloak как провайдера идентификации и подключили к нему все внутренние системы по стандартному протоколу. Каталог сотрудников стал единственным источником истины: учётная запись создаётся один раз, а роли и права раздаются через группы. Отключение сотрудника теперь закрывает доступ во всех системах одновременно — это часть процесса, а не отдельная задача администратора.

Что стало после

Число ручных операций по заведению и удалению учёток сократилось примерно на 90%, а «мёртвых» активных записей не осталось вовсе. Обращения в поддержку по паролям упали почти втрое — сотрудники входят одним набором данных. Время на подключение нового человека к рабочим системам уменьшилось с нескольких часов до минут, а аудит доступа теперь занимает один запрос вместо ручного обхода систем.

Чем отличается SSO от федерации удостоверений?

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

Федерация удостоверений работает между разными доменами и разными владельцами. Пользователь остаётся в своей организации, а сервис-партнёр не заводит у себя учётную запись — он доверяет утверждению о личности, которое подписано провайдером удостоверений. Ключевое различие: при SSO мы управляем всеми учётными записями сами, при федерации — только подтверждаем факт аутентификации, не получая доступ к паролю и профилю пользователя.

Отсюда разные требования к реализации. Для SSO достаточно единого каталога и протокола передачи сессии между приложениями одного домена. Для федерации нужны метаданные обеих сторон, обмен ключами подписи, заранее согласованные атрибуты — какие именно сведения о пользователе передаются и в каком виде. Ошибка в сопоставлении атрибутов приводит к тому, что человек входит, но не получает нужных прав.

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

Технические сомнения при внедрении SSO

Вопросы на этапе выбора протокола и схемы интеграции возникают всегда — и это нормально: от ответов зависит, как SSO ляжет на текущий ландшафт приложений и не сломает ли вход существующим пользователям. Ниже — то, что чаще всего обсуждаем с техническими командами до старта работ.

Что с безопасностью: не станет ли единая точка входа слабым звеном?

Наоборот — SSO убирает главную уязвимость, когда пользователи держат разные пароли или переиспользуют один. Аутентификация концентрируется в одном месте, где можно включить многофакторную проверку, ограничение по IP и журналирование входов. Ключевое — корректно настроить срок жизни токенов и их отзыв при выходе, чтобы сессия не оставалась активной во всех приложениях после разлогина.

Как пройдёт миграция — придётся ли заставлять всех менять пароли?

Не обязательно. Учётные записи переносятся, а пароли можно синхронизировать через федерацию с текущим хранилищем или оставить вход по старому паролю на переходный период. Обычно запускаем SSO параллельно с прежним входом, переводим по одному приложению и отключаем старую схему, когда убедимся, что все сценарии входа отрабатывают. Откат на любом шаге — возврат к прежней конфигурации без потери учётных записей.

Кто получит доступ к данным пользователей и как это регулируется?

Провайдер идентификации хранит только атрибуты, необходимые для входа и ролей, — остальные данные остаются в приложениях. Права раздаются по группам, а не вручную, поэтому при увольнении или смене роли доступ закрывается в одном месте и сразу во всех системах.

Обсудим вашу задачу по единому входу

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

По итогам разбора мы возвращаемся с оценкой и планом внедрения — с этапами, сроками и зонами ответственности. Вам не нужно готовить детальное техническое задание: достаточно описать задачу и текущий ландшафт, остальное мы структурируем сами.

Что вы получите на старте работы:

• Разбор текущей схемы аутентификации и точек, где она даёт сбой.
• Список приложений и сервисов, которые войдут в единый вход, с приоритетом подключения.
• Модель ролей и прав: кто к чему получает доступ и как это меняется при увольнении или переводе.
• Варианты реализации SSO под ваш ландшафт — с плюсами и ограничениями каждого.
• План миграции пользователей без простоя и с возможностью отката.
• Перечень рисков: несовместимые системы, устаревшие приложения, внешние подрядчики.
• Оценку сроков и состава работ по этапам.

Опишите задачу — какие приложения нужно объединить, сколько пользователей, есть ли внешние партнёры и требования к безопасности. Мы вернёмся с оценкой и планом внедрения, по которому можно принимать решение.