Собственный провайдер пользователей для Keycloak
Интегрируя Keycloak в уже существующую систему, высока вероятность столкнуться с необходимостью во время аутентификации загружать пользователей из древней базы данных, где информация о них может храниться в довольно причудливом виде. Такая задача решается созданием собственного провайдера пользователей (User Federation Provider в терминологии Keycloak). Ниже будет представлено краткое руководство по написанию такого провайдера.
Если вдруг вы не знакомы с Keycloak, то вот вам цитата из Wikipedia:
Keycloak продукт с открытым кодом для реализации single sign-on с возможностью управления доступом, нацелен на современные применения и сервисы.
В современном микросервисном мире Keycloak интересен прежде всего как провайдер OAuth 2.0, с помощью которого можно выдавать клиентам токены для доступа к тем или иным сервисам.
Наш плагин для Keycloak будет представлять собой небольшое приложение, упакованное в WAR. Для его сборки будет достаточно Java 8. В качестве инструмента сборки возьмём Gradle, а в зависимостях укажем следующие модули:
Модули Spring Framework могут показаться лишними, тем более, что наш плагин не будет работать в контексте Spring. Использовал я их исключительно для облегчения работы с базой данных, а также для валидации паролей.
Для логирования действий нашего провайдера был выбран JBoss Logging, как «родное» решение в случае сервера WildFly. Допускаю, что можно писать в лог, пользуясь чем-то более привычным, вроде SLF4J.
Далее нам понадобится реализация интерфейса org.keycloak.models.RoleModel для представления ролей пользователя. Для неё я не обнаружил удобного адаптера, поэтому придётся предоставить реализации всех необходимых методов самостоятельно:
Модель роли фактически состоит лишь из названия роли, которое также выбрано в качестве её идентификатора. По аналогии с адаптером модели пользователя, методы-мутаторы бросают исключения.
Теперь переходим непосредственно к провайдеру пользователей. Загружать информацию о пользователях будем только по имени пользователя или по его идентификатору. Адрес электронной почты проигнорируем. Метод загрузки по имени выглядит следующим образом:
Загрузка информации о пользователе по его идентификатору не намного сложнее. Потребуется лишь извлечь имя пользователя из этого идентификатора:
Наконец, метод валидации пароля:
создадим источник данных для соединения с базой данных;
создадим подходящий кодировщик паролей.
Параметры для инициализации фабрики по умолчанию будем добывать из системных свойств:
Но это на мой взгляд уже вкусовщина.
Источник данных у нас будет крайне простой, без пула соединений:
Здесь стоит сделать важное замечание: драйвер базы данных должен присутствовать либо в WAR-файле нашего плагина, либо в модулях Keycloak. Здесь я пошёл по второму пути, а значит плагин должен явно декларировать зависимость от определённого модуля драйвера, что будет продемонстрировано чуть позже. Если нужный модуль драйвера отсутствует, его легко добавить. Процесс добавления нового модуля описан в официальной документации Keycloak.
SSO на микросервисной архитектуре. Используем Keycloak. Часть №1
В любой крупной компании, и X5 Retail Group не исключение, по мере развития возрастает количество проектов, где требуется авторизация пользователей. С течением времени требуется бесшовный переход пользователей из одного приложения в другой и тогда возникает необходимость использования единого сервера Single-Sing-On (SSO). Но как быть, когда такие идентификационные провайдеры как AD или иные, не обладающие дополнительными атрибутами, уже используются в различных проектах. На помощь придет класс систем под названием «идентификационные брокеры». Наиболее функциональными являются его представители, такие как Keycloak, Gravitee Access management и пр. Чаще всего сценарии использования могут быть различны: машинное взаимодействие, участие пользователей и пр. Решение должно поддерживать гибкий и масштабируемый функционал, способный объединить все требования в одном, и такие решением в нашей компании сейчас является индикационный брокер – Keycloak.
Keycloak – это продукт с открытым исходным кодом, предназначенный для идентификации и контроля доступа и поддерживаемый компанией RedHat. Он является основой для продуктов компании использующих SSO – RH-SSO.
Основные понятия
Прежде чем начать разбираться с решениями и подходами следует определиться в терминах и последовательности процессов:
Идентификация — это процедура распознавания субъекта по его идентификатору (проще говоря, это определение имени, логина или номера).
Аутентификация – это процедура проверки подлинности (пользователя проверяют с помощью пароля, письмо проверяют по электронной подписи и т.д.)
Авторизация – это предоставление доступа к какому-либо ресурсу (например, к электронной почте).
Идентификационный брокер Keycloak
Keycloak — это решение для управления идентификацией и доступом с открытым исходным кодом, предназначенное для использования в ИС где могут использоваться паттерны микросервисной архитектуры.
Keycloak предлагает такие функции, как единый вход (SSO), брокерская идентификация и социальный вход в систему, федерация пользователей, клиентские адаптеры, консоль администратора и консоль управления учетными записями.
Базовый функционал, поддерживаемый в Keycloak:
REST API https://www.keycloak.org/docs-api/8.0/rest-api/index.html
JAVA API https://www.keycloak.org/docs-api/8.0/javadocs/index.html
Идентификационные провайдеры уровня предприятия (On-Premise)
Возможность аутентификации пользователей через User Federation сервисы.
Также может быть использована сквозная аутентификация — если пользователи проходят аутентификацию на рабочих станциях с Kerberos (LDAP или AD), то они могут быть автоматически аутентифицированы на Keycloak без необходимости снова указывать свое имя пользователя и пароль.
Для аутентификации и дальнейшей авторизации пользователей возможно использование реляционной СУБД, что наиболее применимо для сред разработки, так как не влечет длительных настроек и интеграций на ранних стадиях проектов. По умолчанию в Keycloak используется встроенная СУБД для хранения настроек и данных о пользователях.
Список поддерживаемых СУБД обширен и включает в себя: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle и другие. Наиболее протестированными на данный момент являются Oracle 12C Release1 RAC и Galera 3.12 cluster для MariaDB 10.1.19.
Идентификационные провайдеры — social login
Возможно использование логина из социальных сетей. Для активации возможности аутентифицировать пользователей используется консоль администратора Keycloack. Изменений в коде приложений не требуется и данный функционал доступен «из коробки» и может быть активирован в любой стадии реализации проекта.
Для аутентификации пользователей возможно использование OpenID/SAML Identity провайдеров.
Типовые сценарии авторизации с использование OAuth2 в Keycloak
Authorization Code Flow — используется с серверными приложениями (server-side applications). Один из наиболее распространенных типов разрешения на авторизацию, поскольку он хорошо подходит для серверных приложений, в которых исходный код приложения и даные клиента не доступны посторонним. Процесс в данном случае строится на перенаправлении (redirection). Приложение должно быть в состоянии взаимодействовать с пользовательским агентом (user-agent), таким как веб-браузер — получать коды авторизации API перенаправляемые через пользовательский агент.
Implicit Flow — используется мобильными или веб-приложениями (приложения, работающие на устройстве пользователя).
Неявный тип разрешения на авторизацию используется мобильными и веб-приложениями, где конфиденциальность клиента не может быть гарантирована. Неявный тип разрешения также использует перенаправление пользовательского агента, при этом токен доступа передается пользовательскому агенту для дальнейшего использовании в приложении. Это делает токен доступным пользователю и другим приложениям на устройстве пользователя. При этом типе разрешения на авторизацию не осуществляется аутентификация подлинности приложения, а сам процесс полагается на URL перенаправления (зарегистрированный ранее в сервисе).
Implicit Flow не поддерживает токены обновления токена доступа (refresh tokens).
Client Credentials Grant Flow — используются при доступе приложения к API. Этот тип разрешения на авторизацию обычно используется для взаимодействий «сервер-сервер», которые должны выполняться в фоновом режиме без немедленного взаимодействия с пользователем. Поток предоставления учетных данных клиента позволяет веб-службе (конфиденциальному клиенту) использовать собственные учетные данные вместо олицетворения пользователя для проверки подлинности при вызове другой веб-службы. Для более высокого уровня безопасности возможно вызывающей службе использовать сертификат (вместо общего секрета) в качестве учетных данных.
Спецификация OAuth2 описана в
RFC-6749
RFC-8252
RFC-6819
JWT токен и его преимущества
JWT (JSON Web Token) — открытый стандарт (https://tools.ietf.org/html/rfc7519), который определяет компактный и автономный способ для защищенной передачи информации между сторонами в виде JSON-объекта.
Согласно стандарту, токен состоит из трех частей в base-64 формате, разделенных точками. Первая часть называется заголовком (header), в которой содержится тип токена и название хэш-алгоритма для получения цифровой подписи. Вторая часть хранит основную информацию (пользователь, атрибуты и т.д.). Третья часть – цифровая подпись.
Refresh-токен — это токен, позволяющий клиентам запрашивать новые access-токены по истечении их времени жизни. Данные токены обычно выдаются на длительный срок.
Основные преимущества применения в микросервисной архитектуре:
JWT токен — состав
Заголовок — по умолчанию, заголовок содержит только тип токена и алгоритм, используемый для шифрования.
Тип токена хранится в ключе «typ». Ключ «typ» игнорируется в JWT. Если ключ «typ» присутствует, его значение должно быть JWT, чтобы указать, что этот объект является JSON Web Token.
Второй ключ «alg» определяет алгоритм, используемый для шифрования токена. По умолчанию он должен быть установлен в HS256. Заголовок кодируется в base64.
< "alg": "HS256", "typ": "JWT">
Payload (содержимое) — в полезной нагрузке хранится любая информация, которую нужно проверить. Каждый ключ в полезной нагрузке известен как «заявление». К примеру, в приложение можно войти только по приглашению (закрытое промо). Когда мы хотим пригласить кого-то поучаствовать, мы отправляем ему письмо с приглашением. Важно проверить, что адрес электронной почты принадлежит человеку, который принимает приглашение, поэтому мы включим этот адрес в полезную нагрузку, для этого сохраним его в ключе «e-mail»
< "email": "example@x5.ru" >
Ключи в payload могут быть произвольными. Тем не менее, есть несколько зарезервированных:
Берутся закодированные в base64: заголовок и payload, они объединяются в строку через точку. Затем эта строка и секретный ключ поступает на вход алгоритма шифрования, указанного в заголовке (ключ «alg»). Ключом может быть любая строка. Более длинные строки будут наиболее предпочтительнее, поскольку потребуется больше времени на подбор.
Построение архитектуры отказоустойчивого кластера Keycloak
При использовании единого кластера для всех проектов возникают повышенные требования к решению для SSO. Когда количество проектов невелико эти требования не так ощутимы для всех проектов, однако с увеличением количества пользователей и интеграций повышаются требования к доступности и производительности.
Повышение рисков отказа единого SSO повышает требования к архитектуре решения и используемых методов резервирования компонентов и приводит к очень жесткому SLA. В связи с этим чаще при разработке или ранних стадиях внедрения решений проекты имеют собственную не отказоустойчивую инфраструктуру. По мере развития требуется заложить возможности развития и масштабирования. Наиболее гибко строить отказоустойчивый кластер с применением контейнерной виртуализации или гибридного подхода.
Для работы в режиме Active/Active и Active/Passive кластера требуется обеспечивать консистентность данных в реляционной базе данных — оба узла базы данных должны синхронно реплицироваться между различными геораспределенными ЦОД.
Самый простой пример отказоустойчивой инсталяции.
Какие преимущества дает использование единого кластера:
На что стоит обратить внимание при планировании кластера
Keycloak использует систему управления СУБД для сохранения: realms, clients, users и пр.
Поддерживается большой спектр СУБД: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak поставляется с собственной встроенной реляционной базой данных. Рекомендуется использование для ненагруженных сред – такие как среды разработки.
Для работы в режиме Active/Active и Active/Passive кластера требуется обеспечивать консистентность данных в реляционной базе данных и оба узла кластера баз данных синхронно реплицируются между ЦОД.
Распределенный кеш (Infinspan)
Для корректной работы кластера требуется дополнительная синхронизация следующих типов кеша с использованием JBoss Data Grid:
Authentication sessions — используемый для сохранения данных при аутентификации конкретного пользователя. Запросы из этого кэша обычно включают только браузер и сервер Keycloak, а не приложение.
Action tokens — используются для сценариев, когда пользователю необходимо подтвердить действие асинхронно (по электронной почте). Например, во время потока forget password кэш actionTokens Infinispan используется для отслеживания метаданных о связанных маркерах действий, которые уже использовались, поэтому его нельзя использовать повторно.
Caching and invalidation of persistent data – используется для кэширования постоянных данных, чтобы избежать лишних запросов к базе данных. Когда какой-либо сервер Keycloak обновляет данные, все остальные серверы Keycloak во всех центрах обработки данных должны знать об этом.
Work — используется только для отправки сообщений о недействительности между узлами кластера и центрами обработки данных.
User sessions — используются для сохранения данных о сеансах пользователя, которые действительны в течение сеанса браузера пользователя. Кэш должен обрабатывать HTTP-запросы от конечного пользователя и приложения.
Brute force protection — используется для отслеживания данных о неудачных входах.
Балансировка нагрузки
Балансировщик нагрузки является единой точкой входа в keycloak и должен поддерживать sticky sessions.
Сервера приложений
Используются для контроля взаимодействия компонентов между собой и могут быть виртуализированы или контейнерезированы с применением имеющихся средств автоматизации и динамического масштабирования средств автоматизации инфраструктуры. Наиболее распространенные сценарии развертывания в OpenShift, Kubernates, Rancher.
На этом первая часть – теоретическая — закончена. В следующих циклах статей будут разобраны примеры интеграций с различными идентификационными провайдерами и примеры настроек.
KeyCloak – щит от JBOSS для WEB приложений
Из диалога двух программистов:
— Кажется, у нас дыра в безопасности!
— Слава Богу, хоть что-то у нас в безопасности…
1. Введение
Пару лет назад мы уже затрагивали тему безопасности в веб-приложениях. Тогда в рамках исследовательских работ был реализован собственный Service Provider для интеграции с продуктом Shibboleth по протоколу SAML 2.0.
В сегодняшней статье речь снова пойдет о безопасности веб-приложений. Мы сделаем небольшой обзор продукта KeyCloak (доселе оставленного без внимания сообществом Habr).
В качестве практической ценности будет разобран пример, как защитить простое JEE приложение средствами KeyCloak, а также как осуществить взаимодействие между двумя защищенными приложениями.
Совсем немного теории об аутентификации и авторизации. Когда мы говорим, что приложение защищено – это означает, что у него есть ресурсы, доступ к которым ограничен наличием определенных прав доступа. Чтобы эти права получить мы должны пройти процесс аутентификации (доказательство, что пользователь является тем, за кого себя выдает). Самым элементарным примером аутентификации является форма введения логина и пароля. Т.е. пользователь вводит свой идентификатор (или логин) и подкрепляет его паролем, тем самым доказывая, что этот идентификатор действительно принадлежит ему. Далее система на основе идентификатора пользователя находит те права, которые этому пользователю назначены. Как эти правила задаются и откуда система их получает не так важно. Вариантов здесь может быть масса, среди которых простой текстовый файл, реляционная БД, LDAP или отдельный сервер авторизации.
Последний шаг – это сравнение необходимых прав доступа ресурса, с правами конкретного пользователя. Он называется процессом авторизации.
2. KeyCloak и PicketLink – два продукта под одной крышей
В настоящее время JBoss ведет разработку двух продуктов в области безопасности веб-приложений: KeyCloak и PicketLink. Вероятно, в ближайшем будущем оба продукта объединят в один, о чем уже давненько ходят разговоры: picketlink.org/news/2015/03/10/PicketLink-and-Keycloak-project-merge.
Сегодня мы не будем останавливаться на проведении детального сравнения двух продуктов, хотя кое-что на эту тему можно посмотреть перейдя по ссылке: planet.jboss.org/post/what_is_the_difference_between_picketlink_and_keycloak.
Буквально в двух словах хочется отметить, что PicketLink защищает приложения, используя программную модель конфигурации. PicketLink предоставляет набор библиотек, хорошо документированный API и широкий набор примеров, оформленных в виде quick start приложений. Все это вы найдете на официальном сайте picketlink.org. Придется потратить кое-какое время, чтобы разобраться с API и научиться правильно его использовать. Около года назад у нас был опыт применения PicketLink в качестве idP сервера для построения SSO на протоколе SAML 2.0. Также средствами PicketLink был сконфигурирован STS сервис для защиты REST сервисов. Однако это отдельная тема, выходящая за рамки данного обсуждения.
KeyCloak, в свою очередь, предоставляет простой административный интерфейс для настройки уровня безопасности в веб-приложениях. Хотите быстро защитить приложение через форму логина/пароля, отделить управление пользователями и правами от логики приложения, организовать SSO, поднять SAML 2.0 idP сервер – это повод посмотреть в сторону KeyCloak. Возможно, это то, что вам нужно.
3. KeyCloak – берем все из коробки…
Keycloak (http://keycloak.jboss.org/) — это open-source сервер аутентификации и управления учетными записями (IDM) от JBoss, построенный на базе спецификаций OAuth 2.0, Open ID Connect, JSON Web Token (JWT) и SAML 2.0.
Список фич KeyCloak достаточно большой и включает поддержку SSO, Social Login, интеграцию с LDAP серверами, управление пользователями, группами и ролями, и много других плюшек. Полный список фич можно посмотреть тут: keycloak.github.io/docs/userguide/keycloak-server/html_single/index.html#Overview.
3.1 Как работает аутентификация в KeyCloak?
После этапа настройки приложения и KeyCloak сервера схема авторизации выглядит так: 
Шаг 1: Запрос защищенного ресурса. Пользователь в браузере обращается по URL к закрытому ресурсу.
Шаг 2: Закрытое приложение перенаправляет неавторизованного пользователя на сервер аутентификации KeyCloak.
Шаг 3: KeyCloak отображает страницу аутентификации (логин/пароль, социальный логин, и т.д.).
Шаг 4: Пользователь проходит этап аутентификации. Для простоты будем считать, что вводит логин и пароль.
Шаг 5: KeyCloak выдает временный токен (секрет) и делает редирект на страницу защищенного приложения.
Шаг 6 и Шаг 7: Приложение проверяет валидность временного токена и меняет временный на постоянный JWT токен.
Шаг 8: На защищенном приложении проходит этап формирования контекста безопасности. Пользователю отображается защищенный ресурс.
3.2 Немного о JWT
JWT (JSON Web Token) — молодой открытый стандарт (https://tools.ietf.org/html/rfc7519), который определяет компактный и автономный способ для защищенной передачи информации между сторонами в виде JSON-объекта.
3.3 Настройка SSO
Получив JWT токен, мы по сути дела уже имеем готовый SSO. Несколько простых конфигурационных шагов и мы сможем использовать защищенные данные другого приложения без необходимости повторной аутентификации.
4. Практическая часть
Знакомство с KeyCloak будем продолжать в рамках практической части, в ходе которой будут выполнены следующие шаги:
4.1 Используемые технологии
4.2 Родительский модуль – keycloak-demo
Родительский модуль хранит версии общих библиотек, версию JVM.
4.2.1 Файл зависимости – pom.xml
4.3 Модуль общих ресурсов (common)
В данном модуле определим общие интерфейсы, которые будут использоваться в остальных модулях/приложениях нашего практического примера.
SSO на микросервисной архитектуре. Используем Keycloak. Часть №1
В любой крупной компании, и X5 Retail Group не исключение, по мере развития возрастает количество проектов, где требуется авторизация пользователей. С течением времени требуется бесшовный переход пользователей из одного приложения в другой и тогда возникает необходимость использования единого сервера Single-Sing-On (SSO). Но как быть, когда такие идентификационные провайдеры как AD или иные, не обладающие дополнительными атрибутами, уже используются в различных проектах. На помощь придет класс систем под названием «идентификационные брокеры». Наиболее функциональными являются его представители, такие как Keycloak, Gravitee Access management и пр. Чаще всего сценарии использования могут быть различны: машинное взаимодействие, участие пользователей и пр. Решение должно поддерживать гибкий и масштабируемый функционал, способный объединить все требования в одном, и такие решением в нашей компании сейчас является индикационный брокер – Keycloak.
Keycloak – это продукт с открытым исходным кодом, предназначенный для идентификации и контроля доступа и поддерживаемый компанией RedHat. Он является основой для продуктов компании использующих SSO – RH-SSO.
Основные понятия
Прежде чем начать разбираться с решениями и подходами следует определиться в терминах и последовательности процессов:
Идентификация — это процедура распознавания субъекта по его идентификатору (проще говоря, это определение имени, логина или номера).
Аутентификация – это процедура проверки подлинности (пользователя проверяют с помощью пароля, письмо проверяют по электронной подписи и т.д.)
Авторизация – это предоставление доступа к какому-либо ресурсу (например, к электронной почте).
Идентификационный брокер Keycloak
Keycloak — это решение для управления идентификацией и доступом с открытым исходным кодом, предназначенное для использования в ИС где могут использоваться паттерны микросервисной архитектуры.
Keycloak предлагает такие функции, как единый вход (SSO), брокерская идентификация и социальный вход в систему, федерация пользователей, клиентские адаптеры, консоль администратора и консоль управления учетными записями.
Базовый функционал, поддерживаемый в Keycloak:
Идентификационные провайдеры уровня предприятия (On-Premise)
Возможность аутентификации пользователей через User Federation сервисы.
Также может быть использована сквозная аутентификация — если пользователи проходят аутентификацию на рабочих станциях с Kerberos (LDAP или AD), то они могут быть автоматически аутентифицированы на Keycloak без необходимости снова указывать свое имя пользователя и пароль.
Для аутентификации и дальнейшей авторизации пользователей возможно использование реляционной СУБД, что наиболее применимо для сред разработки, так как не влечет длительных настроек и интеграций на ранних стадиях проектов. По умолчанию в Keycloak используется встроенная СУБД для хранения настроек и данных о пользователях.
Список поддерживаемых СУБД обширен и включает в себя: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle и другие. Наиболее протестированными на данный момент являются Oracle 12C Release1 RAC и Galera 3.12 cluster для MariaDB 10.1.19.
Идентификационные провайдеры — social login
Возможно использование логина из социальных сетей. Для активации возможности аутентифицировать пользователей используется консоль администратора Keycloack. Изменений в коде приложений не требуется и данный функционал доступен «из коробки» и может быть активирован в любой стадии реализации проекта.
Для аутентификации пользователей возможно использование OpenID/SAML Identity провайдеров.
Типовые сценарии авторизации с использование OAuth2 в Keycloak
Authorization Code Flow — используется с серверными приложениями (server-side applications). Один из наиболее распространенных типов разрешения на авторизацию, поскольку он хорошо подходит для серверных приложений, в которых исходный код приложения и даные клиента не доступны посторонним. Процесс в данном случае строится на перенаправлении (redirection). Приложение должно быть в состоянии взаимодействовать с пользовательским агентом (user-agent), таким как веб-браузер — получать коды авторизации API перенаправляемые через пользовательский агент.
Implicit Flow — используется мобильными или веб-приложениями (приложения, работающие на устройстве пользователя).
Неявный тип разрешения на авторизацию используется мобильными и веб-приложениями, где конфиденциальность клиента не может быть гарантирована. Неявный тип разрешения также использует перенаправление пользовательского агента, при этом токен доступа передается пользовательскому агенту для дальнейшего использовании в приложении. Это делает токен доступным пользователю и другим приложениям на устройстве пользователя. При этом типе разрешения на авторизацию не осуществляется аутентификация подлинности приложения, а сам процесс полагается на URL перенаправления (зарегистрированный ранее в сервисе).
Implicit Flow не поддерживает токены обновления токена доступа (refresh tokens).
Client Credentials Grant Flow — используются при доступе приложения к API. Этот тип разрешения на авторизацию обычно используется для взаимодействий «сервер-сервер», которые должны выполняться в фоновом режиме без немедленного взаимодействия с пользователем. Поток предоставления учетных данных клиента позволяет веб-службе (конфиденциальному клиенту) использовать собственные учетные данные вместо олицетворения пользователя для проверки подлинности при вызове другой веб-службы. Для более высокого уровня безопасности возможно вызывающей службе использовать сертификат (вместо общего секрета) в качестве учетных данных.
JWT токен и его преимущества
JWT (JSON Web Token) — открытый стандарт (https://tools.ietf.org/html/rfc7519), который определяет компактный и автономный способ для защищенной передачи информации между сторонами в виде JSON-объекта.
Согласно стандарту, токен состоит из трех частей в base-64 формате, разделенных точками. Первая часть называется заголовком (header), в которой содержится тип токена и название хэш-алгоритма для получения цифровой подписи. Вторая часть хранит основную информацию (пользователь, атрибуты и т.д.). Третья часть – цифровая подпись.
Refresh-токен — это токен, позволяющий клиентам запрашивать новые access-токены по истечении их времени жизни. Данные токены обычно выдаются на длительный срок.
Основные преимущества применения в микросервисной архитектуре:
JWT токен — состав
Заголовок — по умолчанию, заголовок содержит только тип токена и алгоритм, используемый для шифрования.
Тип токена хранится в ключе «typ». Ключ «typ» игнорируется в JWT. Если ключ «typ» присутствует, его значение должно быть JWT, чтобы указать, что этот объект является JSON Web Token.
Второй ключ «alg» определяет алгоритм, используемый для шифрования токена. По умолчанию он должен быть установлен в HS256. Заголовок кодируется в base64.
< "alg": "HS256", "typ": "JWT">
Payload (содержимое) — в полезной нагрузке хранится любая информация, которую нужно проверить. Каждый ключ в полезной нагрузке известен как «заявление». К примеру, в приложение можно войти только по приглашению (закрытое промо). Когда мы хотим пригласить кого-то поучаствовать, мы отправляем ему письмо с приглашением. Важно проверить, что адрес электронной почты принадлежит человеку, который принимает приглашение, поэтому мы включим этот адрес в полезную нагрузку, для этого сохраним его в ключе «e-mail»
< "email": "example@x5.ru" >
Ключи в payload могут быть произвольными. Тем не менее, есть несколько зарезервированных:
Берутся закодированные в base64: заголовок и payload, они объединяются в строку через точку. Затем эта строка и секретный ключ поступает на вход алгоритма шифрования, указанного в заголовке (ключ «alg»). Ключом может быть любая строка. Более длинные строки будут наиболее предпочтительнее, поскольку потребуется больше времени на подбор.
Построение архитектуры отказоустойчивого кластера Keycloak
При использовании единого кластера для всех проектов возникают повышенные требования к решению для SSO. Когда количество проектов невелико эти требования не так ощутимы для всех проектов, однако с увеличением количества пользователей и интеграций повышаются требования к доступности и производительности.
Повышение рисков отказа единого SSO повышает требования к архитектуре решения и используемых методов резервирования компонентов и приводит к очень жесткому SLA. В связи с этим чаще при разработке или ранних стадиях внедрения решений проекты имеют собственную не отказоустойчивую инфраструктуру. По мере развития требуется заложить возможности развития и масштабирования. Наиболее гибко строить отказоустойчивый кластер с применением контейнерной виртуализации или гибридного подхода.
Для работы в режиме Active/Active и Active/Passive кластера требуется обеспечивать консистентность данных в реляционной базе данных — оба узла базы данных должны синхронно реплицироваться между различными геораспределенными ЦОД.
Самый простой пример отказоустойчивой инсталяции.
Какие преимущества дает использование единого кластера:
На что стоит обратить внимание при планировании кластера
Keycloak использует систему управления СУБД для сохранения: realms, clients, users и пр.
Поддерживается большой спектр СУБД: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak поставляется с собственной встроенной реляционной базой данных. Рекомендуется использование для ненагруженных сред – такие как среды разработки.
Для работы в режиме Active/Active и Active/Passive кластера требуется обеспечивать консистентность данных в реляционной базе данных и оба узла кластера баз данных синхронно реплицируются между ЦОД.
Распределенный кеш (Infinspan)
Для корректной работы кластера требуется дополнительная синхронизация следующих типов кеша с использованием JBoss Data Grid:
Authentication sessions — используемый для сохранения данных при аутентификации конкретного пользователя. Запросы из этого кэша обычно включают только браузер и сервер Keycloak, а не приложение.
Action tokens — используются для сценариев, когда пользователю необходимо подтвердить действие асинхронно (по электронной почте). Например, во время потока forget password кэш actionTokens Infinispan используется для отслеживания метаданных о связанных маркерах действий, которые уже использовались, поэтому его нельзя использовать повторно.
Caching and invalidation of persistent data – используется для кэширования постоянных данных, чтобы избежать лишних запросов к базе данных. Когда какой-либо сервер Keycloak обновляет данные, все остальные серверы Keycloak во всех центрах обработки данных должны знать об этом.
Work — используется только для отправки сообщений о недействительности между узлами кластера и центрами обработки данных.
User sessions — используются для сохранения данных о сеансах пользователя, которые действительны в течение сеанса браузера пользователя. Кэш должен обрабатывать HTTP-запросы от конечного пользователя и приложения.
Brute force protection — используется для отслеживания данных о неудачных входах.
Балансировка нагрузки
Балансировщик нагрузки является единой точкой входа в keycloak и должен поддерживать sticky sessions.
Сервера приложений
Используются для контроля взаимодействия компонентов между собой и могут быть виртуализированы или контейнерезированы с применением имеющихся средств автоматизации и динамического масштабирования средств автоматизации инфраструктуры. Наиболее распространенные сценарии развертывания в OpenShift, Kubernetes, Rancher.
На этом первая часть – теоретическая — закончена. В следующих циклах статей будут разобраны примеры интеграций с различными идентификационными провайдерами и примеры настроек.
