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

Со временем это приводит к типичным проблемам: пользователи начинают повторно использовать пароли, записывать их в заметки, клеить стикеры с паролями на монитор или просто забывать. ИТ-поддержка тратит время на сбросы, а служба информационной безопасности получает дополнительные точки потенциальной компрометации.

На этом фоне технология Single Sign-On (SSO) из удобной опции превратилась в базовый элемент современной инфраструктуры доступа. Она позволяет централизовать аутентификацию и убрать избыточные проверки, не снижая (а при правильной реализации — повышая) уровень безопасности.

Разберёмся, как SSO устроен на уровне протоколов и архитектуры, и как эта технология реализована в системе для многофакторной аутентификации и контроля доступа MULTIFACTOR.

Что такое SSO и как он работает

Single Sign-On — это механизм, при котором пользователь проходит аутентификацию один раз и получает доступ ко всем подключённым системам без повторного ввода учётных данных.

Элементы системы на примере MULTIFACTOR

IdP (Identity Provider) — само SSO-решение, включающее в себя логику аутентификации, управления мастер- и клиентскими сессиями, аудит.

DBs (main/history) — хранилища IdP (main — оперативные данные (активные сессии), history — аудит (логи, все сессии)).

Внешний Identity Server — источник учётных данных (LDAP, AD, Azure AD, OIDC и т.п.).

SSP (Self Service Portal) — интерактивный портал IdP, где пользователь может управлять своими сессиями, MFA, профилем. По сути UI IdP.

SP (Service Provider) — приложение/сервис, которому нужен вход (например, CRM). Оно делегирует аутентификацию IdP и получает от него токены/ассерции.

Ключевой момент здесь — разделение ролей. Аутентификация выносится в отдельный компонент — Identity Provider (IdP), а сами приложения становятся потребителями этой аутентификации — Service Provider (SP). Приложения больше не проверяют пароль пользователя самостоятельно, они доверяют результату проверки, выполненной IdP.

С технической точки зрения процесс выглядит как цепочка редиректов и обмена токенами.

Когда пользователь открывает приложение (например, корпоративный портал), оно не аутентифицирует его напрямую, а перенаправляет в IdP. Там пользователь вводит логин и пароль (а в MULTIFACTOR— ещё и проходит второй фактор). После успешной проверки IdP формирует утверждение о том, что пользователь аутентифицирован, и передаёт его обратно в приложение. Это утверждение может быть реализовано в виде SAML Assertion или токена (например, JWT в случае OIDC).

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

Протоколы и техническая реализация

SSO — это не один протокол, а набор стандартов, которые решают одну задачу разными способами.

В корпоративной среде чаще всего используется SAML 2.0. Это XML-ориентированный протокол, в котором IdP формирует Assertion — документ с информацией о пользователе, подписанный цифровой подписью. Приложение (SP) получает этот документ через браузер пользователя и валидирует его.

В более современных сценариях (особенно для веб и мобильных приложений) используется связка OAuth 2.0 и OpenID Connect. Здесь вместо XML используется JSON, а подтверждение личности пользователя передаётся через ID Token. В отличие от SAML, OIDC проще интегрируется в SPA (одностраничные приложения) и мобильные приложения.

Kerberos решает ту же задачу, но совсем другом уровне — сетевом. Выглядит это так: пользователь один раз вводит пароль и получает специальный билет — Ticket Granting Ticket (TGT). Это как пропуск на входе. Дальше же, когда пользователь хочет попасть в какой-то сервис, Kerberos сам выписывает ему сервисный билет на основе TGT. Пароль повторно не спрашивается. Это классический механизм SSO внутри Active Directory.

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

Сценарии работы SSO

Разберём два типовых сценария: когда у пользователя ещё нет сессии в Identity Provider и когда она уже существует.

Сценарий 1: SP-initiated login без мастер-сессии

Контекст: пользователь находится в приложении (SP) и нажимает «Войти». При этом у него нет активной мастер-сессии в IdP (SSP).

Последовательность действий:

1.Приложение (SP) инициирует процесс аутентификации, формируя запрос:

  • для OIDC — /authorize?client_id=...

  • для SAML — AuthnRequest

2.Далее браузер пользователя редиректится в Identity Provider (SSP).

3.На стороне IdP происходит первичная проверка: система ищет cookie master_session_id. В данном сценарии сессия отсутствует или истекла, поэтому пользователь перенаправляется на страницу логина.

4.После ввода логина и пароля IdP не проверяет учётные данные самостоятельно, а обращается к внешнему источнику идентификации — например, Active Directory, LDAP или внешнему OIDC-провайдеру.

5.При успешной аутентификации происходит ключевой этап — создание мастер-сессии:

  • в main.master_sessions создаётся запись со статусом active

  • аналогичная запись сохраняется в history (для аудита)

  • через NATS планируется событие истечения сессии (delayed message)

  • в аудит пишется событие успешного входа

6.Если в системе включена многофакторная аутентификация, запускается MFA-челлендж. После подтверждения:

  • в мастер-сессии устанавливается флаг mfa_verified = true

  • фиксируется событие MFA success

7.Далее IdP создаёт клиентскую сессию для конкретного приложения:

  • запись добавляется в main.client_sessions

  • дублируется в history

  • планируется событие истечения клиентской сессии

8.После этого IdP формирует ответ для SP:

  • в OIDC — authorization code или токены

  • в SAML — SAMLResponse

9.Браузер редиректится обратно в приложение, которое валидирует ответ (подпись, audience, срок жизни) и создаёт локальную сессию пользователя.

Итог состояния системы

После завершения сценария:

  • в main.master_sessions существует активная мастер-сессия

  • в main.client_sessions создана сессия для конкретного SP

  • history содержит полный аудит (login success, MFA success, session create)

  • в NATS находятся отложенные события истечения сессий

  • пользователь авторизован и в SSP, и в приложении

Фактически это «полный цикл» аутентификации с созданием базовой SSO-сессии.

Сценарий 2: SP-initiated login с активной мастер-сессией

Контекст: пользователь уже ранее прошёл аутентификацию в SSP, у него есть активная мастер-сессия, и он снова нажимает «Войти» в приложении.

Последовательность действий

1.Приложение (SP) так же инициирует редирект в IdP (/authorize или SAML AuthnRequest).

2.На этот раз IdP обнаруживает cookie master_session_id и находит соответствующую запись в main.master_sessions со статусом active.

3.Далее система оценивает контекст аутентификации:

  • достаточно ли текущего уровня доверия

  • требуется ли дополнительный фактор (step-up authentication)

4.Если политика безопасности требует — пользователь может быть дополнительно запрошен на MFA. Если нет — используется существующая сессия.

5.IdP создаёт новую клиентскую сессию, связанную с уже существующей мастер-сессией:

  • запись добавляется в main.client_sessions

  • фиксируется в history

6.После этого IdP сразу формирует ответ для SP (auth code / tokens / SAMLResponse) и возвращает пользователя в приложение.

7.Приложение валидирует ответ и создаёт локальную сессию.

Итог состояния системы

  • мастер-сессия уже существует, поэтому повторное создание не требуется

  • создаётся новая клиентская сессия для конкретного SP

  • пользователь получает доступ без повторного ввода логина и пароля

  • в аудите фиксируется факт использования существующей сессии

Это и есть SSO — быстрый вход без повторной аутентификации, но с сохранением контроля со стороны IdP.

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

Когда аутентификация централизована, появляется возможность:

  • Применять единые политики (например, обязательная 2FA).

  • Контролировать все сессии из одной точки.

  • Быстро отключать доступ при увольнении или инциденте.

  • Отслеживать поведение пользователя в разных системах.

Для бизнеса это выражается в снижении рисков и затрат. Чем меньше паролей — тем меньше вероятность их утечки. Чем меньше ручных операций — тем ниже нагрузка на ИТ.

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

Как реализован SSO в MULTIFACTOR

В MULTIFACTOR SSO реализован как полноценный Identity Provider, встроенный в систему многофакторной аутентификации. Центральным элементом выступает Self-Service Portal (SSP), который одновременно выполняет роль точки входа, витрины приложений и интерфейса управления.

Фактически SSP становится тем самым IdP, через который проходит вся аутентификация пользователей.

Пользователь заходит в портал, проходит проверку (логин/пароль + второй фактор), после чего формируется мастер-сессия. Эта сессия используется для доступа ко всем подключённым приложениям. Повторный ввод учётных данных не требуется.

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

Поддержка протоколов и интеграций

MULTIFACTOR поддерживает основные протоколы SSO: SAML 2.0, OAuth 2.0 и OpenID Connect. Это позволяет интегрироваться практически с любыми современными приложениями — от Microsoft 365 и Google Workspace до внутренних порталов и самописных систем.

Дополнительно система может работать с LDAP-каталогами (например, Active Directory или MULTIDIRECTORY), используя их как источник учётных записей. Это важно для построения гибридных инфраструктур, где аутентификация централизуется, но данные о пользователях остаются в существующих каталогах.

В сценариях с доменной инфраструктурой может использоваться Kerberos, который обеспечивает «прозрачный» вход для пользователей внутри сети. MULTIFACTOR в этом случае добавляет второй фактор на этапе получения билета или доступа к ресурсу.

Как выглядит поток аутентификации

Рассмотрим типичный сценарий.

Пользователь открывает корпоративный портал. Вместо локальной формы входа он перенаправляется в SSP. Там он вводит учётные данные и проходит второй фактор — например, подтверждает вход через push в мобильном приложении.

После успешной проверки SSP формирует сессию и, в зависимости от протокола, выдаёт либо SAML Assertion, либо OIDC-токен. Пользователь возвращается в приложение, которое проверяет подпись и валидность токена.

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

Таким образом, SSO в MULTIFACTOR строится вокруг единой мастер-сессии и доверия приложений к IdP.

Управление сессиями и безопасностью

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

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

Дополнительно MULTIFACTOR реализует защиту от типичных атак: перебора паролей, сессионных атак, попыток входа с подозрительных IP. Всё это работает на уровне централизованной точки аутентификации, что упрощает контроль.

Отдельно стоит отметить, что система не хранит пароли пользователей — она работает поверх существующих каталогов.

Практический эффект от внедрения

На практике внедрение SSO в MULTIFACTOR даёт эффект сразу на нескольких уровнях.

Пользователи перестают жонглировать паролями и быстрее работают с системами. ИТ-служба получает централизованный контроль и снижение нагрузки. Безопасность усиливается за счёт обязательного второго фактора и уменьшения количества точек входа.

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

Single Sign-On — это архитектурный подход, который переносит аутентификацию в одну контролируемую точку и делает управление доступами предсказуемым и централизованным. В итоге достигается важный баланс: один вход для пользователя плюс централизованный контроль для ИБ.