«С ростом числа внутренних сервисов и платформ в компаниях всё актуальнее становится задача унификации доступа сотрудников к корпоративным ресурсам. HR-системы, CRM, документооборот — каждый из этих инструментов требует авторизации. В итоге у сотрудников накапливается десятки учётных записей, а у администраторов — необходимость управлять ими. Чтобы сократить избыточные точки входа и упростить контроль доступа, компании всё чаще внедряют механизм единого входа — SSO (Single Sign-On)», — рассказывает моя коллега Екатерина.
Екатерина
разработчик Java компании Programming Store
Введение
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, но есть потребность в безопасной и удобной аутентификации. Моя цель — не просто сравнить технологии, но и подобрать оптимальный вариант, который легко интегрируется с уже используемой инфраструктурой.
Ключевые моменты, которые будут раскрыты:
Обзор и сравнение технологий SSO?
Интеграция с 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 (OIDC) |
Основное назначение | Авторизация (доступ к API) | Аутентификация + авторизация |
Токены | Access Token | Access Token + ID Token (JWT) |
Идентификация | Нет | Да (данные пользователя в ID Token) |
Поддержка SSO | Частичная | Полноценная |
Когда использовать 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 аутентификация (на примере корпоративной системы):
Пользователь открывает приложение. (Пример: сотрудник заходит на корпоративный портал на 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.
Выбор подходящей технологии
Критерий | CAS | SAML | OIDC |
Legacy-системы | Хорошо | Средне | Плохо |
Мобильные приложения | Нет | Через прокси | Отлично |
MFA/Безопасность | Ограниченная | Полная | Полная |
Интеграция с AD | Хорошая | Отличная | Отличная |
Сложность настройки | Средняя | Высокая | Низкая |
Вывод:
Все три технологии могут интегрироваться с Active Directory, что делает их подходящими для корпоративного использования.
CAS – идеален для интранет-систем и legacy-приложений с простой аутентификацией.
SAML и OIDC – лучше для современных облачных и мобильных решений.
Если у вас много старых веб-приложений, CAS отличный выбор. Если преобладают облачные сервисы, лучше OIDC или SAML.
Заключение
Представленный анализ — первый шаг к построению целостной системы идентификации. Чтобы перейти от теории к практике и выбрать оптимальное SSO-решение, рекомендуем следующий план действий:
1.Составьте матрицу совместимости всех используемых в компании сервисов с технологиями sso.
2.Выявите "узкие места" (например, legacy-приложения без поддержки современных стандартов).
3. Рассмотрите не только прямые затраты, но и скрытые выгоды (например, снижение затрат на поддержку).
4.Определите конкретные шаги для внедрения выбранной технологии.
Переход на SSO — не просто ИТ-проект, а стратегическая инициатива для цифровой устойчивости бизнеса.
