«С ростом числа внутренних сервисов и платформ в компаниях всё актуальнее становится задача унификации доступа сотрудников к корпоративным ресурсам. 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 — не просто ИТ-проект, а стратегическая инициатива для цифровой устойчивости бизнеса.

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