Open Source Identity and Access Management
Add authentication to applications and secure services with minimum effort.
No need to deal with storing users or authenticating users.
Keycloak provides user federation, strong authentication, user management, fine-grained authorization, and more.
Latest release 22.0.5
Single-Sign On
Users authenticate with Keycloak rather than individual applications. This means that your applications don’t have to deal with login forms, authenticating users, and storing users. Once logged-in to Keycloak, users don’t have to login again to access a different application.
This also applies to logout. Keycloak provides single-sign out, which means users only have to logout once to be logged-out of all applications that use Keycloak.
Identity Brokering and Social Login
Enabling login with social networks is easy to add through the admin console. It’s just a matter of selecting the social network you want to add. No code or changes to your application is required.
Keycloak can also authenticate users with existing OpenID Connect or SAML 2.0 Identity Providers. Again, this is just a matter of configuring the Identity Provider through the admin console.
User Federation
Keycloak has built-in support to connect to existing LDAP or Active Directory servers. You can also implement your own provider if you have users in other stores, such as a relational database.
Admin Console
Through the admin console administrators can centrally manage all aspects of the Keycloak server.
They can enable and disable various features. They can configure identity brokering and user federation.
They can create and manage applications and services, and define fine-grained authorization policies.
They can also manage users, including permissions and sessions.
Account Management Console
Through the account management console users can manage their own accounts. They can update the profile, change passwords, and setup two-factor authentication.
Users can also manage sessions as well as view history for the account.
If you’ve enabled social login or identity brokering users can also link their accounts with additional providers to allow them to authenticate to the same account with different identity providers.
Standard Protocols
Keycloak is based on standard protocols and provides support for OpenID Connect, OAuth 2.0, and SAML.
Authorization Services
If role based authorization doesn’t cover your needs, Keycloak provides fine-grained authorization services as well. This allows you to manage permissions for all your services from the Keycloak admin console and gives you the power to define exactly the policies you need.
Всё о Keycloak: зачем нужен, кому подходит и какие преимущества даёт
14 марта в Слёрм стартует курс «Безопасность проекта: аутентификация в Keycloak». Мы пообщались с его автором Виктором Поповым, техлидом DevOps-команды дирекции больших данных в X5 Group. Он рассказал, какие задачи помогает решать инструмент и кто его выбирает — стартапы или энтерпрайз. А также поделился мнением о перспективах Keycloak и о том, даёт ли умение работать с ним карьерные преимущества.
Действительно ли тема настройки Keycloak набирает популярность
За последние полтора-два года Keycloak довольно сильно вырос и выстрелил. Это видно и по количеству вакансий, и по комьюнити, и по публикующимся материалам.
Когда я только начинал разбираться в Keycloak, что-то спросить можно было только у Google. Ты попадал в рассылки разработчиков, а это, мягко говоря, не самая удобная форма подачи информации. Если и попадались какие-то статьи, то только базовые в духе «Мы за 20 минут поднимаем демку и прикручиваем приложение». А дальше просто бездна в виде официальной документации. То есть, на начальном уровне информация ещё была, а чуть дальше — вакуум, и ты бил шишки на собственном проде.
Identity-провайдеры одновременно и давно с нами, и сравнительно недавно. Просто Keycloak — как будто бы самый популярный. Он универсальный и закрывает большое количество потребностей. Да, это не идеальный инструмент, но если без опыта, бюджета и должной компетенции пытаться сделать что-то подобное самостоятельно, получится сильно хуже и дороже.
Какие задачи решает Keycloak
Как и все identity-провайдеры, Keycloak используется для аутентификации и авторизации. Но в целом он ещё про управление пользователями и про безопасность в широком смысле. Безопасность — это всегда сложно и больно, а Keycloak берёт эту историю на себя.
Как было когда-то: мы приходили в приложение с логином и паролем, получали постоянный токен и дальше нас по нему авторизовало. Если токен утекал, начинались серьёзные проблемы. А потом в Oauth2 предложили вариант с динамически меняющимися токенами. Это уменьшило площадь атаки и сделало систему надёжнее и безопаснее. Теперь пароль мы используем, а значит, подвергаем риску утечки редко, а ключи, по которым пользователь авторизуется на сайте, автоматически обновляются каждые несколько минут.
В чём преимущества
У Keycloak 2 основных преимущества. Первое — развитое русскоязычное и международное комьюнити. Популярным инструментом проще пользоваться, потому что вам всегда есть кому задать вопрос.
Второе — нормальный порог входа. Keycloak считается не самым тривиальным инструментом, но он проще аналогичных продуктов, скажем, той же Ory Hydra.
Конкретно у Ory Hydra адовый порог входа. Это мощный конструктор «собери сам», где ты под себя создаёшь решение авторизации, что довольно трудозатратно. Keycloak можно прикрутить за 20 минут к демоприложению и за пару дней к небольшому проду.
Кто обычно выбирает Keycloak
С Keycloak работают и небольшие стартапы, и тяжёлый энтерпрайз. Но есть специфика его использования.
У стартапов обычно меньше требований, поэтому они могут взять продукт из коробки, быстро и базово его настроить, и этого будет достаточно. Если речь об энтерпрайзе, это всегда история про то, как куча людей с огромным опытом по локоть закапываются в инструменте делают какие-то неочевидные вещи под себя и свои задачи. На совместном митапе X5 и Слёрма коллеги из Сбера говорили, что весь Сбер ID работает на Keycloak. Он сильно кастомизирован, и это не тот Keycloak, который можно взять из Docker Hub, но вся кодовая база оттуда.
Есть ли ограничения, которые не позволяют компании использовать Keycloak
Ограничения скорее не в инструменте, а в стандарте OpenID Connect. Со стандартом нельзя торговаться — он либо подходит вам, либо нет.
Хотя есть некоторые расхождения, Keycloak работает максимально близко к стандарту. Если вам не подходит OpenID Connect, то вам не подходит Keycloak. Городить что-то перпендикулярно стандарту не получится.
Какие сложности могут возникать при работе с Keycloak
Самая распространённая проблема связана с большим количеством сессий — когда их много, кэш Keycloak начинает странно вести себя. Но есть надежда, что эта проблема решится в новой версии — Keycloak X. В ней кэш можно полностью отделить от самого keycloak и работать с infinispan, как с самостоятельным приложением. То есть, используя официальную документацию, а не её интерпретацию от разработчиков Keycloak.
На этапе подключения приложения к Keycloak у многих стреляет СORS. Подробнее про CORS вот тут: https://developer.mozilla.org/ru/docs/Web/HTTP/CORS
На практике ты прописываешь в настройках один адрес, а кто-то поднимает тестовый стенд на другом, или какой-то путь не учли. В браузере начинают сыпаться СORS-ошибки.
Ещё могут стрелять внешние зависимости, например, тюнинг подключения к базе данных. Пока у тебя маленький инстанс, всё классно. Но он растёт, выжирает коннект, и в какой-то момент ты понимаешь, что база, которую развернули на коленке, не справляются.
В остальном Keycloak — одна из немногих штук, которая при небольшой нагрузке “просто работает”
Когда вреда больше, чем пользы
Самый яркий пример — over-engineering. Например, когда вы делаете сайтик с котиками для трёх друзей и гробите 400 часов и кучу денег на энтерпрайз грейд авторизацию. Это просто не нужно, достаточно более простого решения.
Есть сервисы, которым не критичны безопасность и надёжность, потому что они не Amazon, у которого каждая секунда простоя стоит миллиарды долларов. Им не нужен Keycloak.
Внедрение технологии всегда чего-то стоит. Вам нужно оплатить курс инженеру, оплатить его работу или просто посидеть вечер и поковыряться в документации. Если внедрение стоит больше, чем даёт, оно не нужно.
Про перспективы Keycloak и карьерные преимущества
Мы живём в прикольное время, когда постоянно рождается что-то новое. Никто не может гарантировать, что завтра какой-нибудь стартап не анонсирует штуку в 10 раз удобнее и производительнее Keycloak. Но при этом есть Oauth2 и OpenID Connect — фундаментальные вещи, которые не меняются часто. И Keycloak — лишь одна из их реализаций. Умея работать с Keycloak и понимая его сущности, вы без проблем перейдёте на другой инструмент.
Сам по себе Keycloak — точно не фича, которая сразу открывает десятизначные зарплаты. Ко всему прочему вам нужно быть хорошим разработчиком или инженером. Но умение работать с Keycloak — востребованный навык и хорошая строчка в резюме, расширяющая пул работы, на которую можно претендовать.
Чему бы отдал предпочтение: самостоятельному обучению или курсам
Я люблю курсы, но больше как интро в технологию. Если можно не биться о базовую документацию 2 месяца, а сходить на 2-дневный курс, получить фундамент и дальше уже биться о более интересную документацию — я за. Это проще и понятнее.
Если говорить о глубоких знаниях, не очень верю, что есть ещё какая-то опция кроме как ковырять стенды и документацию. Так не только в Keycloak, а в любой технологии.
Но для начального этапа классно, когда есть курс, который объясняет азы и логику и даёт целостные, а не фрагментарные знания. И наш курс как раз об этом.
Моя цель — дать фундамент и помочь сэкономить время на поиске информации и погружении в тему. За 5 вечеров я объясню, как всё работает, как пользоваться Keycloak, как развернуть его в пристойной конфигурации и в какую сторону копать дальше под конкретные задачи.
Курс «Безопасность проекта: аутентификация в Keycloak»
На курсе вы получите фундаментальные знания по работе с Keycloak и узнаете, как обеспечьте безопасность проекта с минимальными усилиям.
тут блог
Общественные обязательства интроверта.
Сообщения на ИТ тематику, но не обязательно.
О Keycloak
Есть такая штука. Называется Keycloak. Это не то, что вы подумали, а плащ или мантия, типа для ключей, или «ключевая мантия». Это сервер для Single-Sing-On (SSO), и для хранения учётных записей, и для всего такого, связанного с аутентификацией и авторизацией. Это — часть JBoss, который, оказывается, теперь называется WildFly, сервера приложений (Java EE) от RedHat. Кажется, это самый популярный среди свободных сервер SSO. Потому что на нас одновременно свалилось аж два с половиной проекта, где для авторизации юзеров используется именно Keycloak.
Keycloak умеет OpenID Connect (aka OIDC) и SAML (aka Security Assertion Markup Language).
SAML — это привет из начала двухтысячных на считающимся ныне монструозным XML. Близкий друг действительно монструозного SOAP. Но теперь строить API на XML не модно. Поэтому забудем про SAML.
OpenID Connect будет поинтереснее. Он не имеет ничего общего с протоколами OpenID версий 1.1 и 2.0. Точнее, если верить Википедии, это следующая версия OpenID. И построено оно поверх OAuth 2.0.
OpenID Connect — это конкретный протокол аутентификации, построенный поверх фреймворка авторизации OAuth 2.0.
Помните, OAuth 2.0 — это лишь фреймворк. Там не прописано чётко, какими должны быть токены, как именно их получать, и прочие мелкие детали. Вот OpenID Connect эти детали конкретизирует. И у нас даже есть конкретная реализация: Keycloak.
Keycloak сервер — весь такой multitenancy. На нём положено создавать Realms — независимые пространства со своими юзерами, группами, ролями, ключами, страницами авторизации и клиентами. Клиентами (clients) в смысле OAuth, со своим ClientID и Redirect URI.
Если у нас есть Realm и мы знаем, где находится Keycloak, можно попробовать поавторизоваться. Есть у нас чётко определённый набор Endpointов, с которых можно начать. И их список тоже можно получить.
$ curl https://keycloak.example/auth/realms/gelin/.well-known/openid-configuration | jq . "issuer": "https://keycloak.example/auth/realms/gelin", "authorization_endpoint": "https://keycloak.example/auth/realms/gelin/protocol/openid-connect/auth", "token_endpoint": "https://keycloak.example/auth/realms/gelin/protocol/openid-connect/token", "token_introspection_endpoint": "https://keycloak.example/auth/realms/gelin/protocol/openid-connect/token/introspect", "userinfo_endpoint": "https://keycloak.example/auth/realms/gelin/protocol/openid-connect/userinfo", "end_session_endpoint": "https://keycloak.example/auth/realms/gelin/protocol/openid-connect/logout", "jwks_uri": "https://keycloak.example/auth/realms/gelin/protocol/openid-connect/certs", . Как положено в OAuth, попробуем получить токен.
$ curl -v \ --url https://keycloak.example/auth/realms/gelin/protocol/openid-connect/auth \ --header 'content-type: application/x-www-form-urlencoded' \ --data 'response_type=code&scope=openid&client_id=test&redirect_uri=http%3A%2F%2Flocalhost%3A8080' В ответ нам выдадут форму логина, которая ставит кучку куки. В общем, логично.
$ curl -v \ --url https://keycloak.example/auth/realms/gelin/protocol/openid-connect/auth \ --header 'content-type: application/x-www-form-urlencoded' \ --data 'response_type=token&scope=openid&client_id=test&redirect_uri=http%3A%2F%2Flocalhost%3A8080&nonce=123' В ответ будет подобная же форма логина.
Ну типа почти обычный OAuth 2.0. Только нам точно известно, куда ходить за логином, где получать токен, где спрашивать сведения о пользователе.
Более того, токены у нас подписаны RSA ключом. И мы можем получить публичный ключ для их проверки.
$ curl https://keycloak.example/auth/realms/gelin/protocol/openid-connect/certs | jq . "keys": [ "kid": "AOaPQjC_jwnQG3tx4dqQYSKZyfgSlMLOjy_KFjikvcw", "kty": "RSA", "alg": "RS256", "use": "sig", "n": "j11PAJZ36mh0q1Inn1CsJZ7V_KckqZgFxzPgysrODl9P1k2-yNjpCWzY4UFJlqRalbYG9eLmb5gZAz_8R95BGj8C3u9vFOJYpWhj2PdHgb59KUPHvvn6CLJW_V1xac8uUcDlGnpxbFsztE19qlTFCeFOBhhdzHQW5tHtZhZZvdp6GVrCa9-CTKoP4LjRW7phJk-V-t93AkXWyXufXGzbpQzu4chcsfmgBDGaoDBm1_PomB_d6orOURdAIZi_-rkkcUz9Zz4e_Seo-RxeQ_p4LvWzmTFsPM4o3argnN7TYmT7G8iXeNw3pFQ0O-SUgz070-Ph0gl2mcWso7Pwya-MDQ", "e": "AQAB" > ] > В OpenID Connect, как положено, имеется Access Token, который нужно включать в заголовок Authorization, чтобы получить те же сведения о пользователе, и Refresh Token, который нужен для обновления Access Token. А ещё есть ID Token.
Именно ID Token является JWT токеном, который можно проверить публичным RSA ключом. И именно там содержатся некоторые сведения о пользователе. Можно не делать дополнительных запросов на Keycloak, а сразу извлечь всё, что надо, из ID Token.
На самом деле, все эти curlы вам не понадобятся. Ибо политикой Keycloak является использование адаптеров. То есть библиотек для ваших любимых языков программирования или middleware для ваших любимых веб фреймворков. Берёте нужный адаптер, настраиваете его JSON файлом, который можно скачать прямо в настройках клиента в админке Keycloak, и пользуетесь.
Если адаптера для Keycloak не нашлось, вполне может сгодиться адаптер для просто OpenID Connect. Их много, для разных языков (например, для Go).
Если у вас, допустим, есть какой-то UI на React, то вам достаточно подключить адаптер, и позаботиться о логине в нужный момент, и обновлении токенов, например, по таймеру.
import Keycloak from 'keycloak-js'; export const kc = Keycloak( url: process.env.REACT_APP_KEY_CLOAK_SERVER_URL, realm: process.env.REACT_APP_KEY_CLOAK_REALM, clientId: process.env.REACT_APP_KEY_CLOAK_CLIENT_ID, >); const updateLocalStorage = () => localStorage.setItem('kc_token', kc.token); localStorage.setItem('kc_refreshToken', kc.refreshToken); >; kc.init(onLoad: 'login-required'>) .success((authenticated) => if (authenticated) updateLocalStorage(); setInterval(() => kc.updateToken(11) .success((refreshed) => if (refreshed) updateLocalStorage(); > else > >) .error(() => kc.logout()); >, 10000); ReactDOM.render(app, document.getElementById('root')); > else kc.login(); > >) .error(() => kc.login(); >); kc.onTokenExpired = () => kc.logout(); console.log('Token Expired'); >; Потом этот токен из Keycloak можно вставлять в заголовки запросов к API. А API уже будет проверять валидность этого токена.
Если взять адаптер для Spring Boot, то достаточно его подключить:
implementation 'org.keycloak:keycloak-spring-boot-2-starter:4.0.0.Final' keycloak.realm: gelin keycloak.resource: test keycloak.auth-server-url: https://keycloak.example/auth keycloak.public-client: true keycloak.securityConstraints[0].authRoles[0]: user keycloak.securityConstraints[0].authRoles[1]: admin keycloak.securityConstraints[0].securityCollections[0].name: api resource keycloak.securityConstraints[0].securityCollections[0].patterns[0]: /api И всё. Эта магия работает.
Не нравится мне, когда такие довольно сложные для понимания штуки, как всякие токены, где, чтобы разобраться во всём, нужно нарисовать не одну диаграмму последовательностей, полностью закрываются очень простым фасадом. А если что-нибудь сломается, как выяснять, в чём проблема?
Как работать с Keycloak и перестать бояться OAuth 2: вызовы в проекте, с которыми мы справились
Привет! Меня зовут Никита Роатэ, я Java Developer в NIX. Уже около двух лет я очень плотно работаю с Keycloak и построением микросервисной архитектуры вокруг него. За это время у меня накопилось достаточно полезных знаний, которыми хотелось бы поделиться с вами.
Курс Англійської.
Обери викладача за своїми вимогами серед 1100+ фахівців в Englishdom.
Сама по себе тема OAuth 2 довольно обширная, сложная и поначалу даже может слегка напугать. Но с Keycloak ее вполне можно осилить. Главное — разобраться в самом Keycloak, и этот гайд поможет вам увереннее подойти к его использованию.
В статье мы коснемся таких тем:
- OAuth 2 и концепции SaaS-платформы, выясним, как ее масштабировать;
- сущности в Keycloak: какие есть и как их можно использовать;
Курс UI/UX для геймдеву.
Під час навчання ви розробите проекти для портфоліо, що складається з 5 ключових аспектів UX/UI-дизайну, та отримаєш необхідні навички для професійного росту.
Основные принципы работы Keycloak
Безопасность — важный аспект разработки и всего проекта в целом. Каждый API должен быть защищен. Для этого можно разработать полностью кастомное решение, воспользоваться Spring Security или не изобретать велосипед, а выбрать готовое решение по типу Okta и Keycloak. Я расскажу именно о последнем, и причин такого выбора несколько:
- Keycloak — проверенный продукт с хорошим коммьюнити.
- Он опенсорс — то есть бесплатный и с открытым исходным кодом. А в него приходится смотреть часто.
В статье я уделю внимание OAuth 2. Где он может нам встретиться? Допустим, мы хотим скачать свою фотографию из Google-диска. Мы приходим на портал, который достанет нашу фотку по ID. Если мы не аутентифицированы, нас перенаправят с клиентского приложения на авторизационный сервис, где откроется логин-страница для ввода логина и пароля. Так Authorization Service проверит, что мы — это действительно мы, и имеем право скачать это фото.
Если мы успешно авторизировались и получили заветный токен, то через портал идем на Resource Server. Resource Server — это микросервисная архитектура, в которой и происходит вся бизнес-логика. То есть это именно то, что мы и разрабатываем.
Курс Проджект-менеджмент в IT.
Навчайся у найкращих, курс проводить Тарас Федорук, найкращий PM за версією Ukrainian IT Awards у 2019 році.
Если вернуться к примеру с Google Фото, то чтобы достать файл, нужно обратиться к API этого микросервиса. Но микросервис не должен отдавать API кому угодно, даже если он пришел с токеном. Он должен убедиться, что токен подписан именно нашими Authorization-сервисом, то есть Keycloak. Микросервис делает запрос за JWKS, по одному из ключей валидирует токен, и если он валидный, возвращает ответ — в нашем случае фотографию.
На верхнем уровне система изображена на иллюстрации. Это стандартная трехступенчатая схема OAuth 2-аутентификации. Владельцем ресурса выступаем мы, как пользователь, клиентским приложением является веб-портал, Authorization Service — это Keycloak, а Resource Server — набор микросервисов.
Вы можете спросить: что такое JWKS, за которым ходит ресурс? За этой аббревиатурой скрывается JSON Web Key Set. По сути, это набор ключей, которым валидируют подпись токена. В токене лежит Key ID — айдишник ключа, которым можно проверить подпись токена. Если подпись валидна, процесс идет дальше по флоу.
Сущности в Keycloak: объясню на примере супермаркета
Представьте, что вы заходите в большой торговый центр с множеством магазинов. Этот ТРЦ — Keycloak, а магазины — это наши realm Независимое пространство для нескольких платформ. . Все действие происходит внутри этих реалмов. Наши «магазины» разбиты по отделам. Вы не можете быть в ТРЦ и не быть ни в каком отделе — даже зайдя в супермаркет, мы оказываемся в «отделе входа». Эти отделы — это наши клиенты. Когда мы логинимся в Keycloak, то логинимся в realm в определенный клиент или, если продолжить отсылку к ТРЦ, в определенную секцию торгового отдела. А еще у нас есть пользователи — те, кто покупают, стоят за кассой, обслуживают и так далее.
Keycloak позволяет осуществлять менеджмент ролей. Если есть кассир, то у него есть свои роли: чтобы он мог доставать деньги из кассового аппарата, менять цену, удалять товар и т.п. У пользователей другие задачи: брать или не брать ту или иную вещь. В этом случае нужно разграничивать не только пользователей по отделам, но и наши магазины в целом. То есть если кто-то может бесплатно брать вещи в магазине-1, это не значит, что он может бесплатно брать вещи и в магазине-2.
Далее я приведу стандартный пример URL при логинке Keycloack, где красным выделены realm и client:
https://someDomain/auth/realms/ myRealm /protocol/openid-connect/auth?client_id= myClient . ..
Построение микросервисной архитектуры
Перейдем к созданию микросервисов. Начнем с построения архитектуры. Ниже вы можете увидеть верхнеуровневую схему того, как должен выглядеть микросервис, и как он должен взаимодействовать с Keycloak.
Как я уже писал, у Keycloak есть реалмы, пользователи, группы, клиенты, роли. Всю метадату о них он хранит в PostgreSQL. Но не стоит свою метадату хранить вместе с сущностями Keycloak. Все-таки нужно придерживаться single responsibility — все должно быть изолировано друг от друга.
Курс Англійської.
Навчання для різних цілей та рівнів: робоча англійська, початковий рівень, курси для дітей та підлітків.
Нам нужно написать кастомный микросервис или набор микросервисов, которые будут общаться с Keycloak. Он позволяет обращаться к нему по определенным URL. И если мы хотим создать realm, то это будет post-запрос, а если хотим обновить — put-запрос. И так со всеми сущностями. Соответственно, нужен микросервис, который будет предоставлять такую API для выполнения кастомной логики при обращении к Keycloak.
Как вариант, будем хранить в нашей базе данных свою метадату, которая нужна только нам. Если говорить о большом enterprise-проекте на крупной SaaS-платформе, то здесь будет очень много данных. Их лучше держать в нереляционной базе данных (например, MongoDB).
Возникает вопрос: есть ли в Keycloak решения для обращения к API «из коробки»? Ответ короткий — нет. Поэтому нам нужно самим придумать SDK, которую бы по необходимости подключали в микросервисы.
Благодаря этому можно будет осуществлять HTTP-запросы в Keycloak не через веб-клиент, а с использованием готовых методов, реализованных в SDK.
Проблемы масштабирования
А вот и следующий челлендж. Мы хотим привлекать все больше кастомеров. Представим, что приходит к нам крупная организация и говорит: «Хочу, чтобы были станки и сотрудники для работы с ними». Для этого нам нужно наладить юзер-менеджмент API, чтобы пользователи могли работать с устройствами. Также надо реализовать те или иные роли и те или иные возможности станков.
К примеру, заказчик говорит, что на станках есть суперфича. Благодаря ей удается делать HTTP-вызовы в портал и присылать свою дату — и, соответственно, заказчик хочет воспользоваться вашей платформой. И таких смежных, но с разными требованиями заказчиков пришло 10, 100, 1000! Что делать?
Keycloak позволяет создать сколько угодно реалмов и в них — любое количество клиентов и пользователей. Но тут необходимо действовать вдумчиво, масштабироваться. С ростом количества сущностей Keycloak станет замедляться. По факту он предназначен для пары реалмов и работы с ними. Когда же мы будем логиниться суперпользователем в админку даже при 1500 реалмов, логин будет идти несколько минут, а то и падать по таймауту. Если мы говорим о создании нового реалма, процесс займет порядка 20-30 секунд в лучшем случае. Поэтому надо менять логику и взаимодействие с Keycloak.
Одно из решений этой задачи — внедрение асинхронного механизма. Допустим, пришел кастомер и говорит: нужно насетапить всю сеть пользователей, которые будут работать в контексте нашего заказа, но делать они это будут потом. То есть прямо сейчас не нужно нагружать Keycloak. Для этого мы можем научить микросервис посылать ивент в Kafka с созданием пользователя, а Keycloak — слушать эти запросы. За счет этого станет возможно асинхронно создавать пользователей: в кастомном микросервисе создавать какую-то метадату, а уже в Keycloak она приедет позже.
Или же наоборот: используя Kafka и асинхронно создавая, удаляя или изменяя сущности, мы сможем из Keycloak удалять и создавать пользователей, а в кастомных микросервисах они появятся потом. Конечно, можно попробовать решить проблему вертикальным масштабированием, то есть наращиванием ресурсов, но это стоит денег.
Есть и другое решение: ограничить один инстанс 500 реалмами, а на каждый 501-й реалм создавать новый инстанс. Для этого понадобится сделать входную точку, которая бы понимала, что если пришел пользователь из определенного реалма, то нужно идти в этот инстанс из Keycloak, а если из другого — то в другой инстанс.
Этот механизм — и помощь, и челлендж. Ведь нужно придумать, как соединять инстансы и кастомный сервис. Плюс ко всему надо помнить, что это своеобразный bottleneck «Узкое место» — это процесс, ограниченная пропускная способность которого снижает пропускную способность всей цепочки процессов. . Если он упадет, то не будет удобного механизма понимания, куда должен входить пользователь. А это вызовет серьезные проблемы.
Но не будем забывать, что Keycloak не стоит на месте. Его команда разработки обещает к июлю 2022 года представить Keycloak.X. Все-таки разработчики понимают, что их продукт часто используют не так, как они ожидали изначально. Поэтому они обещают улучшенную работу с большим количеством данных, более быстрый старт и меньше «болей» при апдейте той или иной версии Keycloak.
Работа с темами Keycloak
Все кастомеры разные, а инструмент в виде Keycloak — один. При этом пользователям надо дать понимание того, что они уникальны. Проще всего это сделать кастомизацией логин-страницы. Для этого в Keycloak есть реализация тем. На иллюстрации ниже приведена стандартная тема: она простая и невзрачная.
Но ее можно довольно легко и быстро превратить в такую:
Для этого предусмотрен набор FTL-страниц. FTL (Freemarker Template) — это некий симбиоз Java, JavaScript и HTML. Переопределив набор FTL-страниц, мы сможем как добавлять кастомные темы, так и менять базовую.
Организация менеджмента ролей
Теперь давайте представим набор из тысяч пользователей в каждом реалме. У всех должна быть роль чтения ресурса, но мы хотим, чтобы к этой роли добавилось еще несколько либо они объединились в одну кастомную. На этот случай в Keycloak есть композитные роли. Мы указываем, что он администратор, который получит доступ для чтения, удаления, обновления и т.д.
А если у нас другая задача: чтобы во всех организациях роль «администратор» получила дополнительную роль либо вообще исчезла и на ее месте появилось несколько маленьких? И это требуется сделать во всех реалмах для всех пользователей сразу. Как это реализовать? Пример микросервиса для решения этой задачи — ниже.
Мы все так же логинимся в Keycloak и получаем токен. Но ответственность за менеджмент ролей перекладываем из Keycloak на этот кастомный продукт. Затем при взаимодействии сервисов друг с другом они обращаются в этот permission-сервис и получают тот или иной набор разрешений. А уже на стороне сервиса валидируется, может ли пользователь в соответствии с разрешением выполнять операцию.
Как вариант, можно реализовать API, которые в реальном времени будут добавлять роли или изменять их — вместо того, чтобы делать риквест на девелоперов, которые должны будут своими силами выполнять ту же операцию.
Создание организаций на основе шаблонов
Заказчиков становится еще больше. У всех разные цели, возможности и приоритеты. Одним нужен менеджмент ролей в большей степени, другим — требуется более гибкая настройка взаимодействия с сущностями. В таком случае мы можем задать определенные шаблоны, по которым такие организации будут создаваться. И когда появляется новый кастомер, мы предлагаем разные наборы «из коробки». Можем реализовать и базовый набор функций под требования заказчика, а он уже доделает, как ему нужно.
Также можно создать этот realm в Keycloak. Тогда кастомный микросервис, который занимается генерацией реалмов, будет в запросе получать информацию, какой тип он хочет создать, вытаскивать realm из Keycloak, добавлять переданную кастомную информацию и формировать новый realm. Есть вариант, конечно, хранить это все на какой-то машине. Ведь по факту realm — обычный JSON-объект, который можно изменять . Но в этом случае возникает проблема с тем, что его нужно как-то изменять от релиза к релизу и хранить актуальную версию, плюс быть уверенным в его валидности. Мы обязаны обеспечить процедуру кеширования. Тогда микросервис при поднятии сохранит темплейты и не будет добивать Keycloak запросами.
Продвижение изменений по окружениям
Весь процесс создания продукта включает разработку, потом тестирование, а доход приносит прод, которым пользуется конечный пользователь.
И здесь возникает вопрос: как изменения с низших инвайроментов доставить до наивысших в созданном виде и количестве, и быть уверенным в их правильности?
К примеру, в релизе создано 100 реалмов, в них по 100 клиентов с разной бизнес-логикой. Нужно перенести их и на тестирование, и на прод после замечаний от тестировщиков. Можно заставить девелопера переносить все эти изменения мануально… А можно написать кастомный микросервис, который раз в релиз доставлял бы все изменения посредством миграции.
Liquibase позволяет насетапить миграции на реляционной базе данных. В нашем проекте мы используем нереляционную базу MongoDB и нам отлично подходит Mongock.
Как это выглядит? Сначала создаем чейндж-логи — списки изменений, которые должны быть доставлены. В них есть чейндж-сеты — описанные изменения. При помощи Mongock-аннотаций мы указываем точную последовательность, в которой должны идти миграции. Сначала должен создаться realm, а уже потом обновляться — и только в таком порядке. Плюс можно хранить кастомную метадату по типу автора, список, как все должно выполняться, а также ID. Именно последнее — главное, ведь по ID проверяется уникальность миграции. Если она уже бежала, она просто не пробежит в следующий раз — это и делает Mongock.
Разделение миграций на мажорные и минорные
Но все это подводит к следующей проблеме. Все-таки нам надо доставить изменения из разработки на тестирование и дальше на прод, что происходит в процессе деплоймента. Если миграций много, они могут бежать очень долго и следить за ними стоит много человеко-часов. Потому необходимо приоритезировать миграции, которые должны бежать до старта всех остальных микросервисов.
Как я уже отметил выше, некоторые микросервисы должны закешировать темплейтные реалмы с уже правильными изменениями. Если нужно в организации нашего заказчика какому-то работнику добавить read permission, то это уже неважно в контексте большого проекта. И мы по факту не обязаны эту миграцию запустить в самом начале — ее можно запустить потом и быть уверенным, что она побежит. Как это решить?
Spring предоставляет такую прекрасную аннотацию, как Profile. Мы можем создать профайлы (например, мажорные и минорные) и отмечать: эта миграция мажорная и должна бежать до деплоймента, а эта — минорная, и ее можно запустить потом.
К мажорным миграциям относятся темплейтные изменения и добавления и удаления клиентов OAuth 2, о которых поговорим далее.
Минорные — это все остальные, которые не кэшируются на стороне микросервиса и не важны на данный момент для старта остальных микросервисов.
Авторизация и аутентификация на уровне микросервисов
Очень важно продумать, как микросервисы будут коммуницировать между собой. Их может быть много, и они могут обращаться к API друг друга. Следовательно, нужно наладить процедуры авторизации и аутентификации для этих процессов. Для этого можно воспользоваться процедурой аутентификации по Client ID и Client Secret. В таком случае для каждого сервиса создается клиент OAuth 2 в Keycloak. На каждой стороне сервиса зашивается секрет, с которым он будет получать токен и затем обращаться в нужный микросервис. Как это реализовать?
В первую очередь мы можем передавать его как environment variable, зашив где-нибудь в зашифрованном виде. Но представим: в релиз создалось 10-15 микросервисов. И нужно, чтобы во время деплойментов в каждый из них зашивался его секрет. Ведь без этого он просто не заведется и не сможет общаться с другими микросервисами. Как автоматизировать этот процесс? Надо научить машину делать все самой.
Допустим, нужно, чтобы микросервис получил секрет. Он хранится в клиенте в Keycloak. Мы можем реализовать дополнительного пользователя, креды которого зашьем в environment variable в заинкрипченном виде. Сервис будет получать эти креды, ходить за клиентом за его ID, а потом сам же за секретом. Зная свой секрет, он с самого начала будет хранить его у себя.
Какие могут быть способы тестирования
И в заключительной части я бы хотел рассказать про тесты. Чем лучше написан тест, тем быстрее идет процесс девелопмента, и тем выше уверенность разработчика и кастомера в корректности изменений и нововведений.
Я предлагаю написать тестовую библиотеку, которая будет реализовывать так называемые стабы этих коллов в Keycloak. Ведь когда мы пишем тест, мы хотим пройти все флоу. И если мы можем подложить в базу нужную метадату и обратиться к какому-то API нашего микросервиса, то эти коллы в Keycloak мы напрямую как-то помокать не можем. Если говорить про Keycloak SDK, то мы можем замокать, используя Mockito. Обратите внимание: этот кол мокается не в другой сервис, а в вызов методов внутри сервиса.
Поэтому я предлагаю внедрить WireMock Утилита, библиотека на Java для создания заглушек над веб-сервисами. Он создает HTTP-сервер, к которому мы могли бы подключиться, как к реальному веб-сервису. , который будет стабать HTTP-коллы. То есть мы проходим полностью флоу от начала и до конца, а уже ушел или нет HTTP-колл в другой сервис — не сильно важно.
Главное — послать колл и получить придефайненный респонс. Следовательно, в тестах можно навешивать кастомные разрешения для обращения на тот или иной API и подкладывать респонсы при взаимодействии с другими микросервисами и Keycloak в целом.
Все это подтверждает тот факт, что Keycloack — функциональный инструмент, с которым процесс разработки становится заметно проще, а конечный продукт — безопаснее, стабильнее и удобнее. Надо просто не бояться вникнуть в эту технологию и полюбить ее, как это удалось мне. Удачи!
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.