«id =» main «> Поделиться

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

В этом тексте я попытаюсь сравнить две самые популярные в настоящее время системы с открытым исходным кодом, а именно систему Apereo CAS и систему Keycloak, представив их преимущества и ограничения. Следующий текст и некоторые из содержащихся в нем тезисов основаны на моем личном опыте и могут быть субъективными. Моя цель — не начать религиозную войну и доказать превосходство одной технологии над другой, а передать некоторые факты и суждения, которые могут помочь читателю выбрать решение, лучше соответствующее требованиям его проекта.

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

Краткий исторический обзор Apereo CAS и Keycloak

Проект CAS был разработан в Йельском университете как Yale CAS. С 2004 года он был разработан фондом Java in Administration Special Intrest Group как JASIG CAS. Этот фонд в 2008 году после объединения с фондом Sakai меняет свое название на APEREO, а система переименовывается с версии 4.0 на Apereo CAS. Основная цель фонда — обеспечить образовательные учреждения надежным программным обеспечением с открытым исходным кодом, которое может выдержать рыночную конкуренцию со стороны закрытых коммерческих систем и решений. Система CAS по-прежнему является ведущим стандартом аутентификации во многих академических центрах, в том числе в нашей стране. В начале января 2019 года была выпущена версия 6.0.

История разработки проекта Keycloak составляет 10 лет от системы CAS. Первый производственный выпуск проекта, разработанного в рамках сообщества Jboss, состоялся в 2014 году. В 2016 году Red Hat изменила каркас PicketLink, используемый в его продукте Red Hat SSO, на систему KeyCloak, таким образом, начиная с версии 7.0, Red Hat SSO основана на система KeyCloak. Благодаря этому решению база кода PicketLink и доступные в ней функции интегрированы с системой KeyCloak. Прямая поддержка крупного и признанного поставщика дает дополнительное топливо для развития проекта.

Связь между проектом KeyCloak и Red Hat SSO прямая — Red Hat SSO версии 7.0 основана на KeyCloak 1.9.8, RH SSO 7.1 на KeyCloak 2.5.5 и RH SSO 7.2 на KeyCloak 3.4.3. В ноябре вышло обновление до версии 7.2.5 системы RH SSO, а в декабре — до версии 4.8 системы KeyCloak.

Основные различия между системами — Apereo CAS vs Keycloak

Первое и самое фундаментальное различие заключается в том, как система выпускается и доставляется. Система CAS построена на основе технологического стека Spring Webflow/Spring Boot. В случае с CAS сложно говорить о поставке готовой системы, на сайте поставщика мы не найдем готовых к загрузке установок SSO, подходящих для производственного использования.

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

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

< p>Система может работать на одном из множества поддерживаемых серверов приложений или контейнеров сервлетов. Сделанная таким образом компиляция должна быть тщательно протестирована перед использованием в производственной среде. В дополнение к самому серверу CAS проект предоставляет отдельное приложение, которое позволяет управлять клиентскими приложениями SSO — процесс его создания и реализации аналогичен процессу построения самого сервера CAS.

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

Просмотр функций, доступных в панели администрирования CAS-сервера

Немного иная ситуация с системой KeyCloak. KeyCloak основан на магистрали Spring, но представляет собой решение, тесно интегрированное с подсистемой JBoss/Wildfly. На сайте проекта вы найдете готовые к установке версии проекта, распространяемые с серверами приложений — для KeyCloak это Wildfly, а для Red Hat SSO JBoss EAP. Установки в обход сервера приложений не поддерживаются, как и обслуживание приложений SSO, отличных от KeyCloak/Red Hat, на данном сервере WildFly/EAP.

Сама установка системы аналогична установке самого сервера приложений, и настройка не вызывает проблем. Необходимым дополнительным шагом настройки является подключение системы единого входа к производственному источнику данных РСУБД (встроенную тестовую базу H2 следует заменить эффективной системой). Системе может потребоваться небольшая реконфигурация подсистемы WWW, если вы хотите открыть ее для обратного прокси. У опытного администратора серверов приложений JBoss EAP/WildFly не должно возникнуть проблем с внедрением системы. Фактически, примерно через десяток минут после загрузки мы получаем готовую к работе реализованную систему единого входа.

Red Hat Вид панели администрирования системы единого входа

Стоит отметить, что процесс обновления систем в случае CAS требует подготовки новой компиляции системы, для KeyCloak загрузки (замены) старой версии на новую версию системы, но в случае официально поддерживаемая система SSO Red Hat, выпускаются патчи, которые могут быть добавлены через приложение серверной подсистемы исправлений. Для систем CAS и KeyCloak процессы обновления не гарантируют полной обратной совместимости и обязательно должны быть дополнены соответствующими тестами. Выпуская исправления, Red Hat гарантирует, что они обратно совместимы с установленной версией Red Hat SSO.

Еще одно принципиальное отличие — подход к управлению клиентскими системами и настройками. KeyCloak использует модель аутентификации и авторизации с несколькими доменами (область), тогда как CAS использует один домен. Однако на практике аналогичная конфигурация может быть достигнута в обеих системах, мы просто представим ее немного по-другому. В KeyCloak такие параметры, как: источники объектов входа в систему, предоставляющие информацию о пользователях (называемые федерациями), настройки внешнего вида окон входа в систему, перенаправление аутентификации во внешние системы, расширенные настройки безопасности, потоки процесса входа в систему, параметры автоматической регистрации, принятие нормативных требований. введен на уровне домена для всей группы приложений/систем. Установка системы KeyCloak может одновременно поддерживать множество таких групп приложений, определяя несколько доменов (областей). Однако на сервере CAS мы можем определять аналогичные настройки глобально, сохраняя при этом возможность введения очень конкретной конфигурации для каждой клиентской системы, что делает CAS немного более гибкой системой.

Поддерживаемые протоколы для Apereo CAS и Keycloak

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

Для систем единого входа KeyCloak/RedHat, OpenID Connect (расширение протокола OAuth 2.0) и SAML 2.0 протоколы официально поддерживаются. В случае CAS мы можем подготовить компиляцию системы, которая поддерживает один или несколько из указанных групп протоколов: собственный протокол CAS, OpenID Connect/OpenID/OAuth 2, SAML и SAML 2.0, WS Federation.

При сравнении двух списков может показаться, что CAS обеспечивает дополнительную поддержку, однако мы должны помнить, что функциональные возможности KeyCloak могут быть расширены системой подключаемых модулей. Решение сосредоточиться на полной поддержке только двух протоколов является очень рациональным подходом, который также продиктован коммерческой поддержкой продуктов Red Hat. Сообщество пользователей KeyCloak заполняет пробелы, которые официальные разработчики не могут заполнить. Примером таких решений может быть реализация протокола CAS для KeyCloak: & nbsp; https: //github.com/Doccrazy/keycloak-protocol-cas или реализация протокола WS-Federation для KeyCloak: & nbsp; https: //github.com/cloudtrust/keycloak-wsfed.

Стоит отметить, что реализации отдельных протоколов, за исключением протоколов, присущих обеим системам, могут быть неполными, например, в случае протокола OpenID Connect для CAS реализуются только поток кода авторизации и неявный поток. Это означает, что если мы решим реализовать поддержку неродных протоколов, наш проект должен начинаться с Proof Of Concept, проверяя, соответствуют ли реализации отдельных функций и выполнения протоколов нашим ожиданиям и достаточны ли они в нашей ситуации.

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

В случае системы SSO, официально поддерживаемой Red Hat, мы можем рассчитывать на наличие клиентских библиотек и технологических адаптеров для: JBoss EAP 6.0 и 7.0, Fuse, JavaScript или Node.js. Кроме того, проект KeyCloak предоставляет библиотеки для: WidlFly версий с 9 по 14 и контейнеров сервлетов Jetty и Tomcat. У нас также не должно возникнуть проблем с поиском библиотек для протоколов OpenIDC и/или SAML 2.0 для каждой популярной технологии или среды программирования. В случае системы CAS и ее собственного протокола мы можем найти клиентские библиотеки .NET, Java и PHP. Кроме того, мы можем рассчитывать на поддержку протокола CAS в таких средах программирования, как Spring Security, Apache Shiro, Pac4J.

Практические примеры работающих приложений также будут иметь значение в процессе адаптации решений, что позволит не только изучить технологию нашими программистами, но и проверить правильность конфигурации системы SSO нашими администраторами. В случае Red Hat SSO образцы приложений можно найти в репозитории & nbsp; https: //github.com/redhat-developer/redhat-sso-quickstarts. Следует отметить, что в отдельной ветке репозитория мы найдем приложения, адаптированные для реализации в системе оркестровки контейнеризации OpenShift. Для KeyCloak еще больше примеров можно найти в репозитории: & nbsp; https: //github.com/keycloak/keycloak-quickstarts. В случае CAS список примеров приложений можно найти, посетив репозитории, собранные по адресу: & nbsp; https: //github.com/cas-projects  — список примеров приложений, доступных для CAS, однако, очень велик. меньше, чем в случае Red Hat SSO или KeyCloak.

Во второй части статьи я представлю сравнение функциональных возможностей, обеспечивающих интеграцию с базами данных служб каталогов, делегирование авторизации внешним системам или механизмы настройки внешний вид окон входа в систему. Я также представлю коллективное сравнение расширенных функций обеих систем SSO. Наконец, очевидно, я также постараюсь «ответить» на вопрос в названии статьи.

Источники: https: //apereo.github.io/cas/6.0.x/index.htmlhttps://www.apereo.org/https://www.keycloak.org/documentation.htmlhttps://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.2/