Краткое руководство по использованию Keycloak с пружинным загрузчиком
Узнайте, как настроить сервер блокировки ключей и использовать его с приложением Spring Boot.
1. Обзор
Дальнейшее чтение:
Весенняя безопасность и OpenID подключаются
Простой единый вход с помощью Spring Security OAuth2
CAS SSO С пружинной защитой
2. Что Такое Keycloak?
Keycloak-это решение для управления идентификацией и доступом с открытым исходным кодом, предназначенное для современных приложений и служб.
В нашем уроке мы будем использовать консоль администратора Keycloak для настройки, а затем подключения к Spring Boot с помощью клиентского адаптера Keycloak.
3. Настройка сервера блокировки ключей
3.1. Загрузка и установка Keycloak
Есть несколько дистрибутивов на выбор.
Однако в этом уроке мы будем использовать автономную версию.
Давайте скачаем дистрибутив Keycloak-11.0.2 Автономный сервер из официального источника.
Как только мы загрузим дистрибутив автономного сервера, мы сможем распаковать его и запустить блокировку ключей с терминала:
Теперь давайте откроем браузер и посетим http://localhost:8180 . Мы будем перенаправлены на http://localhost:8180/auth для создания административного входа:
Теперь мы можем перейти к административной консоли. На странице входа в систему мы введем первоначальные учетные данные администратора:
3.2. Создание области
Успешный вход в систему приведет нас к консоли и откроет для нас область Master по умолчанию.
Здесь мы сосредоточимся на создании пользовательской области.
Давайте перейдем в верхний левый верхний угол , чтобы открыть кнопку Добавить область :
На следующем экране давайте добавим новую область под названием SpringBootKeycloak :
3.3. Создание клиента
Теперь мы перейдем на страницу клиентов. Как мы можем видеть на изображении ниже, Keycloak поставляется с клиентами, которые уже встроены :
На следующем экране для этого урока мы оставим все значения по умолчанию, кроме | Допустимых URI перенаправления поля. Это поле должно содержать URL-адреса приложений, которые будут использовать этот клиент для аутентификации :
Позже мы создадим приложение Spring Boot, работающее на порту 8081, которое будет использовать этот клиент. Поэтому мы использовали URL-адрес перенаправления http://localhost:8081/ * выше.
3.4. Создание роли и Пользователя
Доступ на основе ролей пользователя с ключом. Поэтому у каждого пользователя должна быть своя роль.
Для этого нам нужно перейти на страницу Роли :
Затем мы добавим пользователя роль:
Теперь у нас есть роль, которую можно назначить пользователям, но пользователей пока нет. Итак, давайте перейдем на страницу Пользователи и добавим одну:
Мы добавим пользователя с именем user1:
Как только пользователь будет создан, отобразится страница с его подробными сведениями:
4. Генерация токенов доступа с помощью API Keycloak
Keycloak предоставляет API REST для создания и обновления токенов доступа. Мы можем легко использовать этот API для создания вашей собственной страницы входа в систему.
Во-первых, нам нужно получить маркер доступа от Keycloak, отправив запрос POST на этот URL:
Запрос должен содержать это тело в формате x-www-форма-url-кодированный :
Маркер доступа следует использовать в каждом запросе к ресурсу, защищенному паролем, просто поместив его в заголовок Авторизация :
Как только срок действия маркера доступа истечет, мы можем обновить его, отправив запрос POST по тому же URL-адресу, что и выше, но содержащий маркер обновления вместо имени пользователя и пароля:
Keycloak ответит на это новым access_token и refresh_token.
5. Создание приложения для загрузки Spring
5.1. Зависимости
В XML-элементе зависимостей нам нужно следующее, чтобы запустить Keycloak с помощью Spring Boot:
После XML-элемента зависимостей нам нужно указать управление зависимостями для ключевого ключа:
Теперь поддерживаются следующие встроенные контейнеры, которые не требуют никаких дополнительных зависимостей при использовании Spring Boot Keycloak Starter:
5.2. Веб-страницы Thymeleaf
Мы используем Thymeleaf для наших веб-страниц.
У нас есть три страницы:
5.3. Контроллер
Веб-контроллер сопоставляет внутренние и внешние URL-адреса с соответствующими шаблонами Thymeleaf:
Обратите внимание, что мы используем клиента здесь только в качестве исходных данных для отображения, и ничего больше.
5.4. Конфигурация блокировки ключей
Вот базовая, обязательная конфигурация :
Вот ограничения безопасности, которые мы будем использовать:
5.5. Демонстрация
Теперь мы готовы протестировать наше приложение. Чтобы запустить приложение Spring Boot, мы можем легко запустить его через среду разработки, такую как Spring Tool Suite (STS), или выполнить эту команду в терминале:
Мы видим, что нас перенаправили для аутентификации с помощью ключа, чтобы узнать, имеем ли мы право просматривать этот контент:
Теперь мы закончили настройку подключения Spring Boot к Keycloak и продемонстрировали, как это работает.
Как мы видим, весь процесс вызова сервера авторизации Keycloak был легко обработан Spring Boot для нас. Нам не нужно было вызывать API Keycloak, чтобы самостоятельно генерировать маркер доступа, или даже отправлять заголовок авторизации явно в нашем запросе на защищенные ресурсы.
Далее мы рассмотрим, как использовать Spring Security в сочетании с нашим существующим приложением.
6. Весенняя Безопасность
6.1. Зависимость
Чтобы использовать Spring Security с Spring Boot, мы должны добавить эту зависимость:
6.2. Класс конфигурации
Брелок обеспечивает Адаптер_конфигурации ключей безопасности в качестве удобного базового класса для создания WebSecurityConfigurer пример.
Это полезно, поскольку для любого приложения, защищенного Spring Security, требуется класс конфигурации, расширяющий WebSecurityConfigurerAdapter:
Другой метод, распознаватель конфигурации keycloak определяет, что мы хотим использовать поддержку файла свойств загрузки Spring вместо keycloak.json по умолчанию.
Поскольку мы настроили ограничения безопасности с помощью Spring Security, мы можем удалить или прокомментировать эти ограничения безопасности, которые мы ранее разместили в файле свойств:
Теперь, после аутентификации, мы сможем получить доступ к странице внутренних клиентов, как и раньше.
7. Заключение
В этом руководстве мы настроили сервер блокировки ключей и использовали его с приложением Spring Boot.
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.
На этом первая часть – теоретическая — закончена. В следующих циклах статей будут разобраны примеры интеграций с различными идентификационными провайдерами и примеры настроек.
Запускаем Keycloak в HA режиме на Kubernetes
TL;DR: будет описание Keycloak, системы контроля доступа с открытым исходным кодом, разбор внутреннего устройства, детали настройки.
Введение и основные идеи
В этой статье мы увидим основные идеи, которые следует помнить при разворачивании кластера Keycloak поверх Kubernetes.
Если желаете знать более детально о Keycloak — обратитесь к ссылкам в конце статьи. Для того, чтобы сильнее погрузиться в практику — можете изучить наш репозиторий с модулем, который реализует основные идеи этой статьи (руководство по запуску там же, в этой статье будет обзор устройства и настроек, прим. переводчика).
Keycloak — это комплексная система, написанная на Java и построенная поверх сервера приложений Wildfly. Если кратко, это framework для авторизации, дающий пользователям приложений федеративность и возможность SSO (single sign-on).
Приглашаем почитать официальный сайт или Википедию для подробного понимания.
Запуск Keycloak
Для Keycloak необходимо два постоянно хранимых источника данных для запуска:
Keycloak работает в четырех различных режимах:
В этой статье мы детально рассмотрим второй вариант, то есть обычный кластер, а также немного затронем тему насчет репликации между датацентрами, так как эти два варианта имеет смысл запускать в Kubernetes. К счастью в Kubernetes нету проблемы с синхронизацией настроек нескольких подов (узлов Keycloak), так что доменный кластер будет не особо сложно сделать.
Также пожалуйста обратите внимание, что слово кластер до конца статьи будет применяться исключительно насчет группы узлов Keycloak, работающих вместе, нет необходимости ссылаться на кластер Kubernetes.
Обычный кластер Keycloak
Для запуска Keycloak в этом режиме нужно:
Настройку внешней базы мы разбирать не будем, поскольку она не является целью данной статьи. Давайте будем считать, что где-то есть работающая база данных — и у нас к ней есть точка подключения. Мы просто добавим эти данные в переменные окружения.
Для лучшего понимания того, как Keycloak работает в отказоустойчивом (HA) кластере, важно знать, как сильно это все зависит от способностей Wildfly к кластеризации.
Wildfly применяет несколько подсистем, некоторые из них используются в качестве балансировщика нагрузки, некоторые — для отказоустойчивости. Балансировщик нагрузки обеспечивает доступность приложения при перегрузке узла кластера, а отказоустойчивость гарантирует доступность приложения даже в случае отказа части узлов кластера. Некоторые из этих подсистем:
mod_cluster : работает совместно с Apache в качестве балансировщика HTTP, зависит от TCP multicast для поиска узлов по умолчанию. Может быть заменен внешним балансировщиком.
infinispan : распределенный кэш, использующий каналы JGroups в качестве транспортного уровня. Дополнительно может применять протокол HotRod для связи с внешним кластером Infinispan для синхронизации содержимого кэша.
jgroups : предоставляет поддержку связи групп для высокодоступных сервисов на основе каналов JGroups. Именованные каналы позволяют экземплярам приложения в кластере соединяться в группы так, что связь обладает такими свойствами, как надежность, упорядоченность, чувствительность к сбоям.
Балансировщик нагрузки
При установке балансировщика в качестве ingress контроллера в кластере Kubernetes важно иметь в виду следующие вещи:
Активация флага proxy-address-forwarding путем установки переменной окружения PROXY_ADDRESS_FORWARDING в true дает Keycloak понимание, что он работает за proxy.
Также надо включить sticky sessions в ingress. Keycloak применяет распределенный кэш Infinispan для сохранения данных, связанных с текущей сессией аутентификации и пользовательской сессией. Кэши работают с одним владельцем по умолчанию, другими словами эта конкретная сессия сохраняется на некотором узле кластера, а другие узлы должны запрашивать ее удаленно, если им понадобится доступ к этой сессии.
Еще одни грабли — если под удаляется или перезапускается, его кэш теряется. С учетом этого стоит установить число владельцев кэша для всех кэшей не менее чем в два, так будет оставаться копия кэша. Решение — запустить скрипт для Wildfly при запуске пода, подложив его в каталог /opt/jboss/startup-scripts в контейнере:
после чего установить значение переменной окружения CACHE_OWNERS в требуемое.
Приватная сеть с поддержкой ip multicast
Если применяете Weavenet в качестве CNI, multicast будет работать сразу же — и ваши узлы Keycloak будут видеть друг друга, как только будут запущены.
Если у вас нет поддержки ip multicast в кластере Kubernetes, можно настроить JGroups на работу с другими протоколами для поиска узлов.
Репликация между датацентрами
Связь
Keycloak использует множественные отдельные кластера кэшей Infinispan для каждого датацентра, где расположены кластера Keycloack, составленные из узлов Keycloak. Но при этом нет разницы между узлами Keycloak в разных датацентрах.
Узлы Keycloak используют внешнюю Java Data Grid (сервера Infinispan) для связи между датацентрами. Связь работает по протоколу Infinispan HotRod.
Для некоторых кэшей также возможно не делать резервные копии и полностью отказаться от записи данных через сервер Infinispan. Для этого надо убрать настройку remote-store конкретному кэшу Infinispan (в файле standalone-ha.xml), после чего некоторый конкретный replicated-cache также перестанет быть нужным на стороне Infinispan сервера.
Настройка кэшей
Есть два типа кэшей в Keycloak:
Локальный. Он расположен рядом с базой, служит для уменьшения нагрузки на базу данных, а также для снижения задержки ответа. В этом типе кэша хранится realm, клиенты, роли и пользовательские метаданные. Этот тип кэша не реплицируется, даже если этот кэш — часть кластера Keycloak. Если меняется некоторая запись в кэше — остальным серверам в кластере отправляется сообщение об изменении, после чего запись исключается из кэша. См. описание work далее, для более детального описания процедуры.
Реплицируемый. Обрабатывает пользовательские сессии, offline токены, а также следит за ошибками входа для определения попыток фишинга паролей и других атак. Хранимые данные в этим кэшах — временные, хранятся только в оперативной памяти, но могут быть реплицированы по кластеру.
Кэши Infinispan
Токены действия. Очередная концепция, обычно применяется для различных сценариев, когда, к примеру, пользователь должен сделать что-то асинхронно по почте. Например, во время процедуры forget password кэш actionTokens применяется для отслеживания метаданных связанных токенов — к примеру токен уже использован, и не может быть активирован повторно. Этот тип кэша обычно должен реплицироваться между датацентрами.
Защита от перебора грубой силой. Кэш loginFailures служит для отслеживания данных ошибок входа, например сколько раз пользователь ввел неверный пароль. Репликация данного кэша — дело администратора. Но для точного подсчета стоит активировать репликацию между датацентрами. Но с другой стороны если не реплицировать эти данные, получится улучшить производительность, и если встает этот вопрос — репликацию можно и не активировать.
При раскатке кластера Infinispan нужно добавить определения кэшей в файл настроек:
Необходимо настроить и запустить кластер Infinispan перед запуском кластера Keycloak
Ссылки и дополнительная документация
Статья переведена и подготовлена для Хабра сотрудниками обучающего центра Слёрм — интенсивы, видеокурсы и корпоративное обучение от практикующих специалистов (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE)
