Технологии единого входа (SSO) для корпоративных ресурсов

Введение

С ростом числа внутренних сервисов и платформ в компаниях всё актуальнее становится задача унификации доступа сотрудников к корпоративным ресурсам. HR-системы, CRM, документооборот  — каждый из этих инструментов требует авторизации. В итоге у сотрудников накапливается десятки учётных записей, а у администраторов — необходимость управлять ими. Чтобы сократить избыточные точки входа и упростить контроль доступа, компании всё чаще внедряют механизм единого входа — SSO (Single Sign-On).

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

Примеры SSO в реальной практике:

Один из наиболее известных примеров — автоматическая авторизация в экосистеме Google. Войдя в аккаунт, пользователь получает доступ ко всем сервисам — Gmail, Google Drive, Docs, YouTube — без повторной авторизации. Это типичный сценарий SSO внутри единой платформы, где все приложения работают с одной учётной записью и общей сессией.

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

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

Почему это важно для бизнеса и ИТ-отделов

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

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

ИТ-подразделения получают возможность централизованного управления учётными записями, настройки политик доступа и быстрой интеграции новых систем. Внедрив один IdP, организация может подключать любые поддерживающие SAML, OAuth 2.0 или OpenID Connect сервисы без дублирования логики аутентификации.

В этой статье я проведу детальный анализ технологий единого входа (SSO), подходящих для корпоративной среды. Мы разберем их сильные и слабые стороны, а также определим, в каких сценариях каждая из них будет наиболее эффективна.

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

Ключевые моменты, которые будут раскрыты:

1. Обзор и сравнение технологий SSO?
2. Интеграция с AD/LDAP — какие технологии выбрать?

Этот анализ – служит первым шагом к построению целостной системы идентификации.

Обзор технологий и стандартов SSO  корпоративной среде с Active Directory и LDAP

SAML (Security Assertion Markup Language)

SAML — это XML-ориентированный протокол, предназначенный для безопасного обмена данными о пользователях между двумя сторонами: системой, подтверждающей личность (IdP, Identity Provider), и системой, предоставляющей услугу (SP, Service Provider). Основная задача SAML — предоставить механизм единого входа (SSO), позволяющий пользователю аутентифицироваться в одном месте и получить доступ к множеству связанных сервисов без повторного ввода пароля.

Когда SAML особенно полезен:

• у вас несколько корпоративных систем (CRM, ERP, HR-портал), требующих единого входа (SSO),
• используется Active Directory/LDAP, и нужна централизованная аутентификация,
• требуется усиленная безопасность — MFA, аудит, контроль доступа и быстрый отзыв прав,
• планируется масштабирование — рост числа сервисов и сотрудников в будущем,
• интеграция с IdP-системами (ADFS, Okta, Keycloak) или SaaS-приложениями, где нужна синхронизация с внутренними политиками безопасности.

Когда SAML не нужен:

• только 1-2 облачных сервиса — проще использовать OIDC,
• нет ИТ-ресурсов для поддержки ADFS/Keycloak,
• все приложения поддерживают OAuth 2.0 — тогда OIDC будет удобнее.

ADFS как мост между AD и внешними приложениями:

ADFS (Active Directory Federation Services) — компонент Windows Server, который позволяет использовать учетные записи из Active Directory в качестве централизованного хранилища идентификационных данных. Он предоставляет интерфейс на базе SAML и может использоваться как IdP.

Ключевые особенности ADFS:

• дает возможность использовать внутренние учетные записи (AD) для входа во внешние веб-приложения;
• не требует дублирования паролей вне периметра компании,
• выступает в роли посредника между корпоративной сетью и сторонними системами.

Как работает SAML-аутентификация (на примере корпоративной системы):

1. Пользователь открывает приложение. (Пример: сотрудник заходит на корпоративный портал на Spring Boot).

Приложение (SP) видит, что пользователь не авторизован.

2. Перенаправление на вход. (Пример: портал отправляет пользователя на страницу входа ADFS).

Приложение перенаправляет браузер в корпоративный ADFS (IdP).

3.Проверка логина/пароля. (Пример: ADFS проверяет учетку в Active Directory).

—   ADFS показывает форму входа или использует Windows-авторизацию.

—   Проверяет данные через Active Directory.

4. Создание цифрового пропуска. (Пример: ADFS формирует подписанный SAML-документ)

—  После успешного входа ADFS создает «цифровой пропуск» (SAML-ассершен).

—  В пропуске указано: кто пользователь и какие у него права.

5. Возврат в приложение. (Пример: браузер передает пропуск обратно в Spring Boot приложение)

—  Браузер автоматически возвращает этот пропуск в приложение

6. Проверка и вход. (Пример: приложение проверяет подпись ADFS и пускает пользователя)

—  Приложение проверяет, что пропуск подписан доверенным ADFS.

—  Извлекает информацию о пользователе.

—  Создает сессию и дает доступ.

Компоненты в примере:

·  Active Directory — база сотрудников.

·  ADFS — корпоративный вход (IdP).

· Spring Boot приложение — сервис с защищенным доступом (SP).

·  Браузер — посредник между всеми компонентами.

Весь процесс занимает 2-3 секунды и происходит автоматически для пользователя.

Вывод:

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

OAuth 2.0 и OpenID Connect

Разница между OAuth 2.0 и OpenID Connect

OAuth 2.0 и OpenID Connect (OIDC) — современные протоколы для аутентификации и авторизации.

Сравнительная таблица OAuth 2.0 и OpenID Connect

Когда использовать OAuth 2.0, а когда OpenID Connect?

• OAuth 2.0 подходит, если нужно предоставить доступ к API (например, для интеграции с внешними сервисами).
• OpenID Connect необходим, если требуется аутентификация пользователя (например, вход в корпоративный портал).

Когда OIDC особенно полезен:

—   Несколько корпоративных систем (порталы, внутренние сервисы).

—   Используется Active Directory/LDAP как хранилище учетных записей.

—   Требуется современная аутентификация с поддержкой MFA.

—  Нужна интеграция с мобильными приложениями и SPA.

—  Планируется масштабирование инфраструктуры.

Когда OIDC не нужен:

—  Только SAML-совместимые legacy-системы.

—  Уже развернута и работает инфраструктура ADFS.

—  Требуется интеграция исключительно с XML-ориентированными системами.

Как работает OAuth 2.0/OpenID Connect аутентификация (на примере корпоративной системы):

1. Пользователь открывает приложение. (Пример: сотрудник заходит на корпоративный портал на Spring Boot).

—  Приложение (OAuth Client) определяет отсутствие активной сессии

2. Перенаправление на вход. (Пример: портал отправляет пользователя на страницу входа Keycloak).

—  Приложение перенаправляет браузер в Identity Provider (Keycloak)

3. Проверка учетных данных. (Пример: Keycloak проверяет учетную запись в Active Directory).

—  IdP показывает форму входа или использует интегрированную аутентификацию.

—  Проверяет логин/пароль через Active Directory/LDAP.

4. Создание токенов доступа. (Пример: Keycloak генерирует JWT-токены).

—  После успешной аутентификации IdP создает ID Token (JWT) — «цифровой паспорт» с информацией о пользовател и Access Token — ключ для доступа к API.

5. Возврат в приложение. (Пример: браузер передает токены обратно в Spring Boot приложение).

—  Браузер автоматически возвращает токены через callback-URL.

6. Проверка и вход. (Пример: приложение проверяет JWT и предоставляет доступ).

—  Приложение проверяет подпись ID Token.

—  Извлекает данные пользователя из payload JWT.

—  Создает сессию и предоставляет доступ.

Ключевые компоненты системы:

• Active Directory/LDAP — центральное хранилище учетных записей.
• Keycloak — Identity Provider (поддерживает OIDC, AD/LDAP, MFA).
• Spring Boot приложение — OAuth 2.0 Client (использует spring-security-oauth2-client).
• Браузер — посредник в процессе аутентификации.

Преимущества перед SAML/ADFS:

—  Лёгкость интеграции: Keycloak проще настроить с AD, чем ADFS.

—  Современные токены: JWT (JSON) вместо громоздких XML в SAML.

—  Гибкость: Поддержка мобильных приложений, SPA, микросервисов.

Вывод:

OIDC — оптимальный выбор для современных корпоративных SSO-решений с поддержкой мобильных приложений и облачных сервисов. Он обеспечивает гибкую аутентификацию через AD/LDAP и совместим с MFA, но не подходит для legacy-систем, где предпочтителен SAML или CAS.

CAS (Central Authentication Service)

Что такое CAS и зачем он нужен?

CAS (Central Authentication Service) — это система единого входа (SSO), разработанная для централизованной аутентификации пользователей в корпоративных, образовательных и государственных системах.

Основные задачи CAS:

—  Упрощение входа – пользователь входит один раз и получает доступ ко всем подключенным сервисам.

—   Безопасность – минимизация рисков утечки паролей (билетная система вместо передачи логинов).

—  Интеграция с корпоративной инфраструктурой – поддержка Active Directory (AD), LDAP, SAML, OAuth 2.0.

—  Совместимость с устаревшими системами – работает с приложениями, не поддерживающими OAuth/OpenID Connect.

Когда CAS особенно полезен:

Корпоративный портал с legacy-приложениями.

—  Старые системы без поддержки OAuth/SAML.

—  Внутренние веб-приложения (интранет, Wiki, старые CRM).

Простая LDAP/AD-аутентификация.

—  Без сложных сценариев MFA.

—  Достаточно логина/пароля из Active Directory.

Единая точка входа без сложных протоколов.

—  Нужен простой SSO для внутренних сервисов.

—  Поддержка CAS Protocol (билеты TGT/ST).

Бюджетные ограничения.

—  Бесплатное open-source решение.

—  Нет необходимости в облачных SSO (Okta, Azure AD).

Когда CAS не подходит:

Нужна поддержка мобильных приложений.

—  Лучше OAuth 2.0 / OpenID Connect (OIDC).

Требуется встроенная MFA/биометрия.

—  Лучше SAML + Keycloak / ADFS.

Интеграция с современными SaaS-сервисами.

—  Многие облачные приложения работают только с OIDC/SAML.

Cложные сценарии авторизации.

—  Динамические роли, ABAC-политики (лучше Keycloak).

Как работает CAS-аутентификация (на примере корпоративной системы):

1.  Пользователь открывает приложение. (Пример: сотрудник заходит на корпоративный портал).

—   Приложение (CAS-клиент) определяет отсутствие валидного билета.

2. Перенаправление на вход. (Пример: портал отправляет пользователя на страницу входа CAS Server).

—  Приложение перенаправляет браузер на CAS Server.

3. Проверка учетных данных. (Пример: CAS Server проверяет учетную запись в Active Directory)

—  CAS Server:

Проверяет наличие активной сессии (по TGT cookie).

При отсутствии сессии показывает форму входа.

Верифицирует логин/пароль через интеграцию с AD/LDAP.

4. Выдача билетов. (Пример: CAS Server генерирует билеты доступа).

—  После успешной аутентификации: TGT (Ticket-Granting Ticket) — долгосрочный билет (хранится как cookie). ST (Service Ticket) — одноразовый билет для доступа к приложению.

5. Возврат в приложение. (Пример: браузер передает ST обратно в корпоративный портал).

—  Браузер автоматически перенаправляется обратно с Service Ticket.

6. Валидация и доступ. (Пример: приложение проверяет билет через CAS Server).

—  Приложение отправляет ST на проверку в CAS Server.

—   После подтверждения создает локальную сессию.

—  Предоставляет доступ пользователю.

Ключевые компоненты системы:

• Active Directory/LDAP — центральное хранилище учетных записей.
• CAS Server — центральный сервер аутентификации.
• Корпоративный портал — CAS-клиент (поддерживает CAS Protocol).
• Браузер — обеспечивает передачу билетов между компонентами.

Вывод:

CAS — оптимальное решение для legacy-систем и простых корпоративных SSO-сценариев с AD/LDAP. Он идеален для интранет-приложений, но не подходит для современных мобильных и облачных сервисов, где лучше использовать OIDC/SAML.

Выбор подходящей технологии

Вывод:

Все три технологии могут интегрироваться с Active Directory, что делает их подходящими для корпоративного использования.

CAS – идеален для интранет-систем и legacy-приложений с простой аутентификацией.

 SAML и OIDC – лучше для современных облачных и мобильных решений.

Если у вас много старых веб-приложений, CAS отличный выбор. Если преобладают облачные сервисы, лучше OIDC или SAML.

Заключение

Представленный анализ — первый шаг к построению целостной системы идентификации.  Чтобы перейти от теории к практике и выбрать оптимальное SSO-решение, рекомендуем следующий план действий:

1.Составьте матрицу совместимости всех используемых в компании сервисов с технологиями sso.

2.Выявите «узкие места» (например, legacy-приложения без поддержки современных стандартов).

3.  Рассмотрите не только прямые затраты, но и скрытые выгоды (например, снижение затрат на поддержку).

4.Определите конкретные шаги для внедрения выбранной технологии.

Переход на SSO — не просто ИТ-проект, а стратегическая инициатива для цифровой устойчивости бизнеса.