Опыт внедрения и работы с Keycloak

• Приветствие участников и представление спикеров.  

• Описание структуры мероприятия: три блока с перерывами.  

• Первый блок: знакомство, презентация, вопросы и ответы, партнерский блок.  

• Второй блок: разминка, презентация, вопросы и ответы, партнерский блок.  

• Третий блок: интерактив, лекция, вопросы и ответы, заполнение формы обратной связи.  

• Инструкция по использованию QR-кода и ссылки в чате YouTube для вопросов.  

• Тестирование интерактива и переход к знакомству.  

• Вопросы о городах участников и их часовых поясах.  

• Оценка тяги к новым знаниям участников.  

• Представление Василия Романа, инженера платформы корневой системы X5 Group.  

• Важность делегирования безопасности и причины для этого.  

• Проблемы с повторением кода и необходимость стандартизации аутентификации.  

• Исследования о хранении паролей в открытом тексте и важность делегирования безопасности.  

• Экономия времени и денег благодаря стандартизации аутентификации.  

• Преимущества делегирования безопасности внешнему централизованному решению.  

• Описание решения Skeylock для аутентификации и авторизации пользователей.  

• Идентификация: определение имени, логина, номера пользователя.  

• Аутентификация: проверка подлинности пользователя.  

• Авторизация: предоставление доступа к ресурсу.  

• Keycloak использует изолированные пространства для клиентов.  

• Процесс аутентификации начинается с браузера, который перенаправляет пользователя в Keycloak.  

• Keycloak генерирует автономный токен с полезной нагрузкой.  

• Security Tokens: стандарты для передачи данных.  

• TOTP: популярный стандарт, используемый в Keycloak.  

• SAML: сложный формат, поддерживающий множество вариантов шифрования.  

• Хедер: тип токена и используемые алгоритмы подписи.  

• Полезная нагрузка: утверждения в формате ключ-значение.  

• Три типа утверждений: зарегистрированные, публичные и частные.  

• Данные шифруются в Base64 и подписываются по указанному алгоритму.  

• Пример токена: хедер, полезная нагрузка и подпись.  

• ID Token: хранит информацию о пользователе.  

• Access Token: используется для авторизации.  

• Refresh Token: для выпуска нового Access Token.  

• Пользователь авторизуется в Keycloak.  

• Keycloak передает подписанную информацию о пользователе веб-приложению.  

• Решение проблем безопасности учетных записей.  

• Внутренняя база данных Keycloak.  

• Использование LDAP и других провайдеров.  

• Внешняя идентификация через протоколы SAML и OpenID Connect.  

• Добавление кастомных полей и групп.  

• Сброс и восстановление паролей.  

• Синхронизация изменений пользователей с Active Directory и LDAP.  

• Keycloak поддерживает регистрацию пользователей и верификацию через email.  

• Возможность изменения внешнего вида окон входа, регистрации и писем.  

• Темы можно устанавливать глобально или на конкретного клиента.  

• Темы написаны на языке Apache FreeMarker.  

• Возможность подключения CSS и JavaScript скриптов.  

• Проект Keycloakify позволяет интегрировать решения на React.  

• Keycloak позволяет экономить на авторизации через DAP, DFS или Directory.  

• Интеграция с GetLab через OAuth 2.0.  

• Keycloak перенаправляет авторизацию на GetLab, что позволяет использовать его бесплатно.  

• Настройка конечных точек аутентификации в Keycloak.  

• Использование Active Directory для федерации пользователей.  

• Создание клиента и настройка мапперов для авторизации.  

• Keycloak не имеет визуального конструктора форм.  

• Возможность использования внешних проектов для верстки.  

• Интеграция с CRM системами через опыт сервер или экспорт пользователей.  

• Возможность настройки правил для отсечения пользователей.  

• Ограничение доступа по доменным почтам и групповым политикам.  

• Создание групп клиентов и назначение прав.  

• Keycloak может группировать пользователей в роли.  

• Клиенты могут быть назначены на роли, но не сами клиенты.  

• Уточнение вопроса о группах клиентов и ролях.  

• Обсуждение взаимодействия Keycloak с другими системами.  

• Проблемы с отображением вопросов в видео.  

• Вопрос о реализации синглсим-оф.  

• Возможность разрушения токенов по времени.  

• Использование инпоинтов и выхода для разрушения токенов.  

• Проблемы с множественными токенами и их обновлением.  

• Пример использования Keycloak для авторизации в разных компаниях.  

• Проблемы синхронизации данных между Keycloak и другими системами.  

• Важность внешнего хранилища для пользователей.  

• Проверка состояния пользователей при интеграции с другими системами.  

• Механизмы синхронизации и задержки в Keycloak.  

• Проблемы с блокировкой пользователей и их синхронизацией.  

• Авторизация происходит на сервере Keycloak.  

• Необходимость балансировщика при масштабировании.  

• Подробности будут освещены ближе к концу выступления.  

• Представление Сергея из компании X5.  

• Описание работы команды по DevOps и мониторингу.  

• Обзор бизнеса X5 в сегменте еды и доставки.  

• Продажа помидоров в магазинах оказывается сложной задачей.  

• Нужно формировать ассортимент на основе данных о продажах и фидбека пользователей.  

• Цены зависят от множества факторов, включая макроэкономические показатели.  

• Прогнозирование спроса и доставка помидоров требуют автоматизации.  

• Логистика включает склады и водителей, которые конкурируют за заказы.  

• Продажа помидоров возможна через различные каналы, включая кассы и приложения.  

• Все этапы производственного цикла требуют автоматизации.  

• В компании работает более 3000 ИТ-специалистов.  

• Используются современные технологии, такие как микросервисная архитектура и контейнеры.  

• Компания активно ищет новых сотрудников в различных ИТ-направлениях.  

• Вакансии доступны на сайте HeadHunter.  

• Приглашение к сотрудничеству и работе в компании.  

• Участники делятся своими занятиями во время перерыва.  

• Обсуждение различных тем, включая работу и отдых.  

• Переход к следующему заданию и обсуждение картинки.  

• Тема выступления: как избавить разработчиков от необходимости реализовывать идентификацию.  

• Объяснение, как пришел клок и его роль в компании.  

• Объединение сервисов для партнеров в единую экосистему.  

• Настройка кейклока и дополнительных компонентов для упрощения внедрения.  

• Сервисы развернуты в Kubernetes с использованием сайдкаров.  

• Цель: сократить затраты и увеличить скорость внедрения новых проектов.  

• Запрос из браузера попадает на конгресс или сервис.  

• Приложение проверяет наличие токена и его актуальность.  

• Работа с токенами может выполняться вручную или с использованием Gatekeeper.  

• Gatekeeper является проксирующим звеном и оболочкой вокруг приложения.  

• Запросы сначала попадают в Gatekeeper, который проверяет наличие токена.  

• Если токена нет, Gatekeeper перенаправляет пользователя на Keycloak для аутентификации.  

• Gatekeeper позволяет реализовать Keycloak и обновлять токены.  

• Приложение избавляется от необходимости думать об аутентификации.  

• Gatekeeper извлекает данные из JWT и передает их в заголовки HTTP.  

• В экосистеме есть несколько уровней микросервисов.  

• Gatekeeper развернут в демилитаризованной зоне DMZ.  

• Пользователи аутентифицируются через Keycloak, который выдает временные токены.  

• Пользователь без токена попадает в Gatekeeper.  

• Gatekeeper перенаправляет на Keycloak для аутентификации.  

• Keycloak выдает временный токен и перенаправляет обратно на Gatekeeper.  

• Порталы поставщика и рекламного таргетинга объединены под SS.  

• Пользователи аутентифицируются через Keycloak для разных доменов.  

• Gatekeeper перенаправляет пользователей на форму ввода логина и пароля при отсутствии токена.  

• Сквозные токены позволяют автоматически авторизовать пользователя на другом портале без ввода логина и пароля.  

• Это обеспечивает бесшовный переход между порталами.  

• Существуют гайдкиперы перед джинсом, публичным бэкендом и закрытыми бэкендами.  

• Это позволяет соблюдать разные требования безопасности для разных бэкендов.  

• Гайдкиперы могут работать в режиме форвардинга, обрабатывая исходящие запросы.  

• Это позволяет разработчикам не писать код для получения токенов, а использовать гайдкиперы.  

• Гайдкипер форвардинг обрабатывает запросы, обогащая их необходимыми заголовками.  

• Это позволяет бэкендам не знать, под каким пользователем происходит доступ.  

• Гайдкиперы передают необходимые данные для авторизации, такие как имя пользователя и группы.  

• Права доступа реализуются через группы, назначаемые через интерфейсы кей клока.  

• Аналитический портал имеет фронт, публичное API и закрытые сервисы.  

• Ранее использовались токены для аутентификации и авторизации, что было неэффективно.  

• Внутренние сервисы могут содержать как публичные, так и форвардинговые гайдкиперы.  

• Гайдкиперы проксируют запросы и обрабатывают токены для авторизации.  

• Гайдкиперы могут пропускать статический контент без авторизации.  

• При обращении к правам зоне, гайдкипер редиректит на получение токенов.  

• Гайдкиперы на входе и выходе обрабатывают запросы и получают токены.  

• Микросервисы используют гайдкиперы для аутентификации и авторизации.  

• Сервисы с двумя гайдкиперами обрабатывают запросы с помощью форвардинга.  

• Сервисы с одним гайдкипером обрабатывают запросы без форвардинга.  

• Для работы Keycloak необходимо настроить доверительные отношения между клиентами.  

• Один клиент будет получать токены для другого клиента.  

• Внутри токена добавляется нода аудиенс, указывающая на доступные клиенты.  

• Рекомендуется использовать кастомные мапперы для каждого взаимодействия.  

• Роли позволяют разграничивать доступ между пользователями и микросервисами.  

• Роли назначаются пользователям и проверяются при доступе к конечным точкам.  

• Keycloak должен знать, откуда брать образ и конечные точки.  

• Важно указать порт и секреты для безопасного доступа.  

• Сервисы могут рефреш токены и шифровать их с помощью инкриптов.  

• Keycloak форвардит токены и аутентифицирует запросы.  

• Важно указать порт и идентификаторы для аутентификации.  

• Система готова к работе без необходимости написания кода.  

• Для создания пользователей можно использовать API Keycloak.  

• Пользователи создаются без пароля, который устанавливается позже.  

• Keycloak использует внутренние идентификаторы для пользователей и групп.  

• Keycloak не делает работу Gatekeeper, а лишь упрощает реализацию микросервисов.  

• Gatekeeper проверяет токены, избавляя от необходимости ручной проверки.  

• Авторизация через SMS возможна, но требует кастомных плагинов.  

• Keycloak поддерживает множество продуктов, включая Bitrix, HubSpot, NextCloud и Atlassian.  

• Некоторые продукты, такие как Bitrix, уже имеют встроенные плагины для Keycloak.  

• Keycloak набирает популярность и используется в различных продуктах.  

• Active Directory Federation Services AD FS реализует функции, аналогичные Keycloak.  

• В Keycloak можно строить кастомные поля для пользователей, но это не всегда делается.  

• Аутентификация и авторизация реализуются через выпуск дополнительных токенов.  

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

• Можно настраивать поля токена самостоятельно.  

• Рекомендуется использовать микросервисы для хранения кастомных атрибутов пользователей.  

• Токены можно убивать через функционал Revoke или административную консоль Keycloak.  

• Keycloak не предназначен для отображения транзакционной информации, такой как баланс или сальдо.  

• Профиль пользователя можно редактировать, но это не используется в проектах.  

• Keycloak имеет встроенные средства для предотвращения брутфорса.  

• Можно настраивать количество попыток входа и время блокировки пользователя.  

• Данные о попытках входа хранятся в кэше, который не реплицируется между репликами.  

• Вопрос о прохождении видеокурса по Keycloak.  

• 63% участников хотят пройти курс, 24% не уверены, 9% не хотят.  

• Курс будет стоить 2500 рублей, если наберется 50 заявок.  

• Курс будет включать темы по кастомной федерации, масштабированию, модулям на Java и другим темам.  

• Участники делятся, что делали во время перерыва.  

• Виктор упоминает, что пил чай.  

• Некоторые участники лежали на полу на балконе.  

• Из 69 участников ответили только 10.  

• Участники корректируют свои ответы.  

• Ведущий просит описать состояние одним словом.  

• Участники описывают свое состояние как "чай".  

• Некоторые упоминают чайный гриб.  

• Ведущий отмечает, что многие уже должны спать.  

• Виктор рассказывает о кейклоке, которым занимается больше года.  

• Кейклок используется как сервис авторизации.  

• Виктор поддерживает крупнейший кейклок в компании.  

• Кейклок работает в кубе с тремя репликами.  

• Используются различные чарты, но Виктор предпочитает простые.  

• Важно использовать DNS-спин для балансировки сессий.  

• Кейклок работает хорошо при небольшом количестве сессий.  

• При большом количестве сессий возникают проблемы.  

• Используется кэш-инфинити для обработки сессий.  

• В Kubernetes нет необходимости в домене мод, так как каждая реплика может быть настроена отдельно.  

• Мультидомен работает, но требует связывания кластеров через протокол HA.  

• Сессии должны реплицироваться между домену для балансировки нагрузки.  

• Конфигурации клиентов хранятся как JSON, что упрощает их управление.  

• Используется официальный антиблоковый модуль для экспорта и импорта JSON.  

• Рекомендуется использовать эталонный JSON для создания мапперов.  

• Кейклок предоставляет метрики через плагин, который можно настроить для сбора данных.  

• Метрики можно визуализировать с помощью Grafana и Prometheus.  

• Мониторинг включает коды ответов, логины, хиты и другие показатели.  

• Используются различные бенчмарки для тестирования производительности.  

• Кейклок может создавать базы тестирования для проверки производительности.  

• Тестирование показало, что Кейклок справляется с нагрузкой, но внешние сервисы могут быть узким местом.  

• Важно правильно настроить ресурсы для Кейклока, особенно в Kubernetes.  

• Необходимо указать флаги для использования всех доступных ресурсов.  

• Keycloak планирует переход на более производительный сервер Quarkus.  

• Обновления будут бесшовными между версиями, но миграция может потребовать времени.  

• Доступны готовые Docker-контейнеры и превью-версии.  

• В Keycloak можно делегировать права на уровне рима.  

• Это позволяет администраторам предоставлять разные уровни доступа для разных пользователей.  

• Админка Keycloak имеет отдельный эндпоинт для авторизации.  

• Используется PostgreSQL с тремя репликами.  

• База данных растет быстро, особенно таблица событий и таблица пользователей.  

• Рекомендуется регулярно чистить базу данных для оптимизации.  

• Рекомендуется использовать Gatekeeper для авторизации.  

• Gatekeeper позволяет легко интегрировать приложения с Keycloak.  

• Gatekeeper обеспечивает встроенный функционал для проверки токенов и настройки доступов.  

• Gatekeeper можно пересобрать на минимальном образе RedHat.  

• Важно добавлять внутренние сертификаты для корректной работы.  

• Пересоборка контейнера необходима для работы с недоверенными сертификатами.  

• Разбираться с Infinispan, вынести его в отдельный кластер.  

• Настроить мониторинг и здоровье кластера.  

• Подружить Keycloak с Kerberos для упрощения авторизации.  

• Настройка единого SSO между Keycloak и другими провайдерами.  

• Планируется нагрузочное тестирование Keycloak с 50 миллионами пользователей.  

• Создание комьюнити вокруг Keycloak для поддержки и консультаций.  

• Обсуждение кастомных провайдеров и их поддержки.  

• Вопросы о токенах и их использовании в больших цепочках вызовов.  

• Решение проблемы больших токенов через авторизацию на стороне сервиса.  

• Сравнение Keycloak с другими продуктами, такими как Hydra.  

• Важность живого комьюнити для поддержки и решения проблем.  

• Стандартизация и гибкость Keycloak, что делает переход на другие продукты менее сложным.  

• Токены хранятся у клиента и валидируются Keycloak.  

• Куки и рефреш-токены не хранятся в Keycloak, а только у клиента.  

• Токены могут быть записаны в постоянное хранилище для оффлайн использования.  

• Токины могут передаваться как куками, так и через заголовки.  

• Куки передаются с каждым запросом, что может быть накладным с точки зрения сетевого трафика.  

• Можно прописывать токины вручную в заголовках, чтобы избежать этого.  

• В компании используют разные подходы к написанию микросервисов.  

• Разработчики рекомендуют использовать библиотеки, а не прокси.  

• Это решение более дорогое и сложное, но может быть более поддерживаемым в долгосрочной перспективе.  

• В компании предпочитают использовать одну точку правды для пользователей.  

• Используются группы в Active Directory для авторизации.  

• Конкретная реализация зависит от конкретного продукта.  

• Вопрос о настройке идентификации пользователей по сертификатам остался без ответа.  

• Важно правильно настраивать редиректы и защищать куки.  

• Если токен утечет, нужно детектировать аномальное поведение и отзывать токены.  

• В компании используют PostgreSQL.  

• Использование кастомных плагинов не рекомендуется, если это возможно.  

• Важно заполнять форму обратной связи для улучшения продукта.  

• Подтокины используются для делегирования прав сервисам.  

• Авторизация через SMS возможна через кастомные плагины.  

• API Keycloak позволяет управлять пользователями и создавать новых.  

• Пользователи могут быть авторизованы на разных доменах через Keycloak.  

• Токины для разных доменов могут быть независимыми.  

• Можно настроить выпуск одного токина на основании другого.  

• Апгрейд базы Keycloak из-под PostgreSQL сложен и требует времени.  

• Разные токены для бэка и фронта не обязательны, но могут быть полезны для безопасности.  

• Важно отслеживать срок жизни токенов для предотвращения утечек.  

• Видеокурс от Sler и документация на Хабре и Медиуме полезны для начинающих.  

• Для более продвинутых пользователей рекомендуется комьюнити и эксперименты.  

• Рассылки и старые документы часто содержат устаревшую информацию.  

• В Keycloak пользователи и сервисные пользователи  

• Кэширование в Keycloak происходит на уровне тем, которые он сам кэширует.  

• Валидация токенов происходит быстрее, так как не требует интерактивного режима проверки.  

• Keycloak делегирует проверку валидности токенов за счет криптостойких алгоритмов.  

• В Keycloak есть офлайн-токены, которые хранятся в базе данных.  

• Долгоживущие офлайн-токены важны для поддержания активности пользователей.  

• Нет простого способа отличить мертвую сессию от живой, поэтому токены хранятся долго.  

• Tarantool используется как сторож Keycloak, но имеет свои нюансы.  

• Проблемы с подсчетом пользователей и необходимость постраничного запроса.  

• Рекомендуется избегать кастомных решений, если это возможно.  

• Gatekeeper проверяет токены в заголовках HTTP-запросов.  

• Gatekeeper хранит токены в своей памяти для режима форвардинга.  

• Несколько копий Gatekeeper работают нормально, если они используют один и тот же стейтлс.  

• Gatekeeper может проксировать трафик на разные порты.  

• Можно использовать один Gatekeeper для нескольких микросервисов.  

• Один Gatekeeper может обслуживать все конечные точки в одном пода.  

• Роли пользователей можно передавать в токены.  

• Аналоги Keycloak: Adent Server, Hydra, Ciscada, DFS, Auth0.  

• Keycloak удобен для репликации между производственной и тестовой средой.  

• Keycloak хранит базу данных, которую регулярно копируют и восстанавливают.  

• Клиенты хранятся как JSON для прозрачного менеджмента.  

• Регулярное резервное копирование и проверка базы данных необходимы для надежности.  

• Использование прокси-сервиса для авторизации клиентов.  

• Возможность использования GitKeeper для автоматизации процесса.  

• Простота установки GitKeeper перед прокси-сервером.  

• Использование нативной библиотеки для веб-составляющей.  

• Важность указания литре дирекшн урлс для безопасности.  

• Использование Java-оснастки для создания сервисов.  

• Использование GitKeeper для передачи данных в заголовках.  

• Возможность парсинга токена для получения данных.  

• Использование конечных точек для получения и расшифровки токенов.  

• Invoke как альтернатива GitKeeper для реализации функционала.  

• Возможность использования Invoke для авторизации через Keycloak.  

• Уточнение о сервисных полях токена.  

• Возможность редактирования атрибутов пользователей через личный кабинет.  

• Написание микросервиса для редактирования атрибутов.  

• Примеры кастомных трибьютов и кастомных полей.  

• Red Hat SSO как более младшая версия Keycloak.  

• Использование платных компонентов и поддержка через Red Hat SSO.  

• Скептическое отношение к Red Hat SSO из-за высокой стоимости поддержки.  

• Настройка GitKeeper для редиректа на Keycloak.  

• Указание сервисных эндпоинтов Keycloak.  

• Реализация Keycloak через GitKeeper, браузер или бэкенд.  

• Использование одинаковых прав для всех потребителей.  

• Возможность управления правами через токены и роли.  

• Реализация проброса клиентского токена через цепочку сервисов.  

• Использование обычных DBA для работы с базами данных.  

• Экспорт и импорт данных в GitKeeper.  

• Благодарность зрителям за участие и завершение встречи.