Как объединить авторизацию в легаси и микросервисах с помощью Apereo CAS

В любой компании со стажем от пяти лет неизбежно появляется зоопарк внутренних сервисов. Бухгалтерия сидит в старой ERP, разработчики заходят в GitLab через SAML, мобильное приложение общается по OpenID Connect, а несколько служебных утилит до сих пор принимают только базовую HTTP-аутентификацию через LDAP. Когда руководство просит настроить единый вход (SSO) и добавить второй фактор, команда обычно встает перед выбором: платить за облачные сервисы вроде Okta или разворачивать собственный Identity Provider внутри своего контура.

Если облака не подходят из-за требований безопасности или законов о хранении персональных данных, список вариантов резко сокращается. Один из самых проверенных инструментов для этой задачи — проект Apereo CAS.

Что такое CAS

Аббревиатура расшифровывается как Central Authentication Service. Проект зародился в Йельском университете в начале двухтысячных годов. С тех пор он вырос из университетской разработки в промышленный сервер аутентификации на базе Spring Boot и Spring Cloud. В репозитории проекта на GitHub собралось более 11 тысяч звезд и почти 4 тысячи форков.

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

Архитектурный подход через WAR Overlay

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

Вместо этого используется концепция WAR Overlay. Вы создаете компактный проект на Gradle или Maven, подключаете стартер CAS и точечно переопределяете нужные свойства, шаблоны страниц или Java-бины:

// build.gradle в вашем overlay-проекте
dependencies {
    implementation "org.apereo.cas:cas-server-webapp-starter:${casVersion}"
    implementation "org.apereo.cas:cas-server-support-ldap:${casVersion}"
    implementation "org.apereo.cas:cas-server-support-mfa-gauth:${casVersion}"
}

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

Основные возможности

Сервер умеет связывать между собой разнородные механизмы входа:

1. Поддержка протоколов авторизации. Сервер одновременно принимает запросы по протоколам CAS (v1-v3), SAML 1.1 и 2.0, OAuth 2.0, OpenID Connect и WS-Federation. Сервер может выступать как источник идентификации, так и делегировать проверку внешним провайдерам.

2. Разнообразие источников данных. Пользовательские записи можно читать из Active Directory, баз данных через JPA, Redis, MongoDB, Apache Cassandra или извлекать из сертификатов X.509.

3. Многофакторная аутентификация. В систему встроены модули для WebAuthn (FIDO2), YubiKey, Google Authenticator и Duo Security. Доступна адаптивная проверка: второй фактор запрашивается только при смене IP-адреса или входе в нетипичное время.

4. Кластеризация и хранение сессий. Для распределенной работы под балансировщиком тикеты и пользовательские сессии реплицируются через Hazelcast, Redis или Memcached.

Конфигурация настраивается через привычные YAML-файлы:

cas:
  authn:
    ldap[0]:
      ldap-url: ldap://ldap.corp.internal:389
      base-dn: dc=company,dc=com
      user-filter: (sAMAccountName={user})
      bind-dn: cn=admin,dc=company,dc=com
      bind-credential: secretpassword
      type: AUTHENTICATED

Подводные камни

У универсальности CAS есть обратная сторона. Проект сложный, а количество настроек в документации исчисляется сотнями.

Если допустить опечатку в названии параметра в YAML, Spring Boot может тихо проигнорировать строчку и применить значение по умолчанию. В результате поиск причины, почему не работает сопоставление атрибутов LDAP, иногда затягивается на часы.

Стек Spring Boot и Spring Webflow к тому же требователен к памяти. Чтобы инстанс сервера чувствовал себя уверенно под боевой нагрузкой, закладывайте от 2 до 4 ГБ оперативной памяти на контейнер.

Кому подойдет проект

CAS покажет себя с лучшей стороны в следующих ситуациях:

• Университеты и научные центры с десятками старых веб-порталов, написанных на разных языках и фреймворках.
• Закрытые корпоративные контуры с жесткими требованиями регуляторов, запрещающими использовать сторонние SaaS-решения для аутентификации.
• Банки и финтех-компании, где требуется совместить вход по аппаратным ключам WebAuthn с проверкой учетных данных в нескольких разрозненных доменах Active Directory.
• Долгие проекты миграции, когда нужно постепенно переводить сервисы на OpenID Connect, не ломая доступ по старым протоколам.

Итоги

Разворачивать CAS ради двух простых микросервисов избыточно, для этого хватит стандартных библиотек вашего веб-фреймворка. Но если вам досталась разрозненная инфраструктура с десятком разношерстных сервисов, Apereo CAS избавит от необходимости писать собственные шлюзы авторизации. Для первого знакомства проще всего взять официальный репозиторий шаблона cas-overlay-template и запустить его локально в Docker.