Привет! Я Диана, системный аналитик в Clevertec и экс-преподаватель. В этой статье = нескучной лекции продолжу тему межсистемной аутентификации. Первое занятие можно посмотреть тут. Сейчас рассчитываю, что либо вы с ней уже познакомились, либо сами разбираетесь в теме. А слова «токен», «фактор аутентификации», Single Sign-On (SSO) и OAuth 2.0 вас не пугают. На втором занятии мы снова на примерах с котами подробнее обсудим:
Что такое Keycloak и для чего он нужен?
Как Keycloak помогает с межсистемной аутентификацией?
Какие плюсы и минусы у Keycloak при использовании в продакшене?
Какие альтернативы есть у Keycloak?
1. Что такое Keycloak?
Напомню, межсистемную аутентификацию можно реализовать разными способами, но при выборе того или иного подхода необходимо учитывать ряд факторов: требования к безопасности систем, гибкость, масштабируемость, необходимость авторизации, возможности кастомных доработок и много чего еще.
Keycloak позволяет осуществлять межсистемную аутентификацию по токенам. Он поддерживает аутентификацию и авторизацию в приложениях со стандартными протоколами OpenID Connect, OAuth 2.0 и SAML 2.0. Еще один фактор делает Keycloak таким привлекательным — это open source.
Основные характеристики Keycloak:
Регистрация и управление пользователями/сервисными аккаунтами: возможность создавать и настраивать пользователей/сервисные аккаунты, управлять их правами и группами.
Single Sign-On (SSO) и Single Sign-Off: единая аутентификация для всех приложений в пределах одного realm (об этом чуть ниже) и возможность разлогинивания сразу из всех систем.
Выдача JSON Web Token (JWT): обеспечение безопасной передачи данных между клиентом и сервером с помощью стандартного формата токенов.
Интеграция со службами каталогов (LDAP, Active Directory): возможность подключения к корпоративным каталогам для управления учетными записями.
Брокер Kerberos: реализация аутентификации через Kerberos в корпоративной среде.
Поддержка мульти-realm: создание изолированных пространств для пользователей и приложений с возможностью кастомизации логин-страниц для каждого realm.
А если вспомнить, что кроме межсистемной есть пользовательская аутентификация, то к списку выше можно добавить:
Авторизация через соцсети: поддержка входа через сторонние провайдеры, такие как Google, Facebook, GitHub и другие.
Двухфакторная аутентификация (2FA): поддержка дополнительной проверки личности через OTP, аутентификационные приложения и другие методы.
Кроме того, Keycloak предоставляет удобный интерфейс для работы с ним, а детализированные руководства и туториалы помогут разобраться в настройке и интеграции (официальные гайды).
Но давайте теперь познакомимся с Keycloak поближе, а для этого пригодятся термины, определения, схемы и котики (последние вообще никогда не бывают лишними).
2. Основные сущности Keycloak
К основным сущностям можно отнести следующие (рисунок 1):
Realm — изолированное пространство, в котором управляются пользователи, приложения, роли и группы. Каждая область имеет свои собственные конфигурации и данные. Это позволяет создавать несколько независимых зон аутентификации и авторизации на одном сервере Keycloak (например, для разделения сред). Когда одна система взаимодействует с другой через Keycloak, всё это происходит в рамках одного Realm. Если у вас много систем с требованиями к безопасности, удобно разделять их на разные Realm.
Клиенты (Clients) — приложения и сервисы, которые используют Keycloak для аутентификации и авторизации пользователей. Клиенты могут работать по различным протоколам (OpenID Connect, OAuth 2.0, SAML) и имеют свои параметры конфигурации — например, URL-адреса перенаправления, разрешенные ресурсы и уровни доступа. Клиенты могут быть как пользовательскими приложениями, так и бэкенд-сервисами. Важно понимать что клиент — это не физическое лицо, а приложение или сервис, взаимодействующий с Keycloak.
Пользователи и сервисные аккаунты (Users/Service Accounts) — сущности, которые могут входить в систему. Пользователи — это физические лица, которым можно назначать роли и права доступа. Сервисные аккаунты — это специальные учетные записи, используемые для взаимодействия между сервисами без участия человека. У обеих категорий есть настраиваемые атрибуты, группы и связанные политики безопасности. То есть если мы говорим про межсистемную аутентификацию, то нас интересует в первую очередь сервисные аккаунты.
Роли (Roles) — механизм управления доступом к ресурсам. Роли могут назначаться как отдельным пользователям, так и группам.
Realm-роли — глобальные роли, доступные во всём Realm и определяющие уровень доступа на уровне всей области.
Роли клиента (Client Roles) — специфичные роли, используемые для управления доступом внутри конкретного клиента. Они позволяют задавать более гибкие настройки разрешений и политики безопасности.
На схеме изображено, как Keycloak организует работу с несколькими системами через разные Realm. У каждой может быть свой Realm со своими клиентами (как пользовательскими, так и системными, например, realm system B), пользователями, сервисными аккаунтами и ролями. Master Realm отвечает за административное управление и настройку всей инфраструктуры Keycloak. Важно отметить, что клиент в Keycloak — это не пользователь, а приложение или сервис, который запрашивает аутентификацию и авторизацию через Keycloak. У клиента может быть один и более пользователей (например, Client N) или сервисных аккаунтов (client sysA) — это учетные записи, которые могут входить в систему и получать доступ к ресурсам в соответствии со своими ролями. Если у нескольких клиентов одинаковые роли — можно объединить их в группу (как Client N и ClientM для realm SystemA).
Со всеми этими сущностями можно работать (создавать, добавлять, назначать, настраивать) при помощи программного обеспечения Keycloak. Главное понимать зачем вы это делаете.
3. Как работает Keycloak
Если вы разобрались, как происходит аутентификация по токенам, то ничего нового в этой схеме не увидите. Просто есть две системы, одна из которых (client) сначала проходит аутентификацию в Keycloak (identity provider), получает свои access-token и refresh-token, а затем уже эта система (точнее любой из ее инстансов) может обращаться ко второй системе (service provider), прилагая к запросу этот самый токен. Вторая система получает запрос, валидирует токен (либо отправляя запрос к Keycloak, либо при помощи сертификата), и в случае успешной аутентификации и авторизации возвращает ответ первой системе.
Давайте разберем, почему токена стало два, чем они отличаются кроме названия и для чего нужен каждый из них. Итак, access-token — это собственно и есть токен доступа, который система А будет отправлять системе B, чтобы подтвердить, что ей можно доверять и предоставлять допуск к ресурсам. Как правило, это JWT, который содержит всю необходимую информацию, включая, например, роли для последующей авторизации. Этим токеном могут пользоваться все инстансы системы. Однако, как и у всех токенов, у него есть lifespan — «срок годности», по истечению которого он перестает быть действительным. Время действия токена определяется настройками Keycloak для конкретного клиента в конкретном realm и зависит от того насколько чувствительными данными планируется обмениваться между системами и может отличаться для разных групп и ролей. Обычно время жизни access-token составляет от 3 до 10 минут.
Но что же делать, если срок действия истек, а запросы все не заканчиваются? Снова и снова обращаться к Keycloak, каждый раз проходя авторизацию заново, не так уж и плохо, но это может стать узким местом и снизить скорость работы. Но вы же помните, что бывают еще и refresh-token? Этот токен как раз предназначен для облегчения получения нового access-token: клиенту не нужно повторно проходить авторизацию у Keycloak, а достаточно предоставить валидный refresh-token. И да, lifespan тоже можно настроить и, как правило, он подольше, чем у access-token и обычно составляет 15-30 минут, а иногда и до нескольких часов.
Кроме того, для дополнительной безопасности, можно обеспечить ротацию refresh-token. Всякий раз, когда система обращается за новым access-token, она заодно получает и новый refresh, а старый перестает быть валидным. Это предотвращает переиспользование refresh-token и сокращает риски при перехвате токена. Повторно проверку он просто не пройдет. И конечно, не стоит хранить такие вещи в открытом виде и использовать для передачи небезопасные соединения.
Но это я так, для профилактики упомянула, я уверена вы и так помните про безопасность))) Подробнее про ротацию можно почитать: источник 1, источник 2.
Чтобы было немного понятнее, я нарисовала для вас схему процесса с использованием refresh-token.
Система А проверяет наличие access-token (для примера взят Redis, но это только для примера).
а) Если токен есть (предположим, что храним мы только свежие токены), то система А делает запрос к системе B и дальше все идет по накатанной.
б) Если токена нет, то система А проверяет наличие refresh-token
2. а) Если refresh-token есть, то система А идет с ним к Кеуcloak, получает новые access- token и refresh-token, сохраняет их — а дальше все идет по накатанной.
б) Если и refresh-token нет, то системе А придется стряхнуть пыль со своих credentials и заново проходить авторизацию, чтобы получить новые access-token и refresh-token, а дальше вы уже знаете.
Кажется, ничего сложного, ну а нюансы зависят от контекста)))
4. Плюсы и минусы практического использования Keycloak
А теперь, когда понятно, как это работает, давайте рассмотрим, почему Keycloak так популярен, как сервис авторизации для многокомпонентных систем.
Межсистемное взаимодействие: сервисные аккаунты — это как раз то, что нужно для обеспечения взаимодействия систем по API: просто добавьте JWT), а еще это удобно если у вас несколько инстансов одного модуля.
Авторизация: за счет назначения различных ролей и прав, мы можем переложить авторизацию на Keycloak;
Стандартизация: Keycloak использует стандартные протоколы OpenID Connect, OAuth 2.0 и SAML, что позволяет использовать его для самых разных систем;
Универсальность: если система действительно большая, и разные ее модули отличаются по требованиям безопасности, то наличие изолированных realm с одной стороны позволит обеспечить гибкость решения, а с другой — будет достаточно универсальным;
Развитие: если в вашей системе появится еще один компонент вы всегда можете добавить еще один realm (или несколько) и создать клиента, там где это необходимо;
Масштабируемость и отказоустойчивость: Keycloak поддерживает кластеризацию (например, можно использовать Kubernetes, если у вас так принято) (ссылки на Хабр, keycloak.org и kryukov.biz)
Кастомизация: если вдруг чего-то не хватает, Keycloak позволяет разрабатывать специализированные решения;
Логирование: Keycloak позволяет сохранять как административные события (например создание нового realm, изменение ролей или увеличение Lifespan токена), так и события аутентификации (успешные и неуспешные входы, использование refresh-token и т.д.). И да, можно подключать JSON-логи, чтобы легче было интегрироваться с внешними системами логирования, например ELK. (ссылки на keyckloak.org, medium.com и elastic.co)
Разумеется, минусы тоже есть. Конечно, из личного опыта хочется вспомнить как долго приходится переводить даже один модуль на новую систему авторизации: заявки на создание клиента для каждой среды, получение credentials, подключение базы данных, где вы будете хранить те же токены, изменение настроек, проведение различных видов тестирования, написание документации в конце-то концов. Но на самом деле, переход на любую новую технологию требует стартовых усилий, вопрос только в том, окупаются ли они в конечном итоге. Поэтому честнее здесь будет упомянуть какие-то более общие проблемы, с которыми можно столкнуться при использовании Keycloak.
Сложность системы: Если у вас действительно сложная архитектура, много разных систем с разными требованиями безопасности, с различными ролями и так далее, то управление всеми этими настройками может стать действительно громоздким. Кроме того, возможно, потребуется отдельный кластер для резервирования и мониторинга;
Дополнительные ресурсы: да, надо сразу понимать, что это все занимает место на серверах, а еще скорее всего потребуется и человеческий ресурс — кто-то должен обеспечивать поддержку, подключение новых систем, писать скрипты для настроек, обновлять систему, что потребует тестирования, поскольку могут быть несовместимости между версиями (несмотря на наличие UI, если система действительно большая, скорее всего, понадобится);
Производительность: если все системы ходят к Keycloak за токенами, то это может стать узким местом, да и не стоит забывать про зависимость от баз данных, где и будет храниться вся информация о клиентах и всем, что с ними связано;
Сложности интеграции через шину и брокеры: Keycloak в первую очередь подходит для систем, интегрирующихся по типу точка-к-точке, если между системами есть кто-то третий, то необходимо продумывать как будут передаваться и валидироваться токены, чтобы это было и безопасно, и не снижало скорость взаимодействия.
5. Не Keycloak единым
Как мы с вами убедились, далеко не всегда Keycloak будет идеальным решением. К счастью, всегда есть альтернативы. Например, Active Directory от Microsoft все еще довольно высоко ценится на рынке, но все-таки это в первую очередь инструмент для локального использования, впрочем, для облачных приложений тоже есть решение - Azure AD. Но проблемы с масштабированием, отказоустойчивостью и лицензионным использованием никуда не пропали.
А еще есть Okta, Zluri, Casdoor и другие решения, знакомство с которыми я оставляю на вашей совести, иначе эта статья грозит разрастись до невероятных размеров)
Заключение: не бывает идеального инструмента
Как всегда, надеюсь, я вас не утомила, а то что вы дочитали до конца говорит о том, что или вы очень основательный человек, или вам действительно надо со всем этим разобраться. В любом случае, теперь вы точно сможете объяснить разработчикам, почему вы не виноваты, если Keycloak снова не отдал токен.
А если серьезно, то Keycloak — это просто инструмент, работать с которым проще, если понимаешь, как он устроен и что делает. А он неплохо справляется с задачами межсистемной аутентификации, хорошо масштабируется и настраивается под конкретные нужды, если вы готовы тратить время и другие ресурсы на его настройку, поддержание и продумывание архитектуры.
И еще раз напомню, что всегда есть альтернативы, в случае Keycloak ими могут стать Active Directory, Okta, Zluri и другие. Главное — помнить, что не бывает идеального инструмента на все случаи жизни. Ну и, конечно, не забывать про мемы с котами — они помогают выжить даже в самой сложной интеграции.
Источники
Про Keycloak:
Не про Keycloak:
Надеюсь, вышло полезно. Оставить свое мнение можно в комментариях :)
