В этой статье я расскажу об интеграции с Keycloak — популярным опенсорсным продуктом для управления доступом (IAM). Многие компании используют его для организации единого входа (Single Sign-On, SSO) в свои системы, что упрощает доступ сотрудников ко всем приложениям. Мы уже имели опыт работы с авторизацией клиентов на «1С-Битрикс: Управление сайтом» (БУС), но интеграция с «королем» опенсорсных IAM'ов — это для нас новый вызов. В статье поделюсь, с какими трудностями мы столкнулись и почему до сих пор не существует готового модуля интеграции Keycloak для Битрикс.
Задача клиента
Наш клиент — ведущий мировой производитель систем отопления и вентиляции, представленный в более чем 60 странах. Компания решила создать интернет-магазин для своих партнеров и для этого мы предложили использовать нашу B2B-платформу, построенную на базе 1С-Битрикс:Управление сайтом (БУС). Она помогает автоматизировать процессы продаж и сокращать издержки.
Однако, заказчика не устраивала стандартная авторизация на платформе, так как компания уже использовала единую систему входа (SSO) через Keycloak для всех своих приложений.
Это удобно: чтобы авторизоваться в сразу в нескольких приложениях нужно ввести логин/пароль всего один раз.
Среди систем заказчика не было ничего на Битрикс, поэтому готового решения по интеграции B2B-платформы с Keycloak тоже не было. В процессе внедрения платформы разработчикам пришлось перебрать и протестировать несколько вариантов.
Поиск решения
В Магазине приложений Битрикса нет готового модуля интеграции с Keycloak. Это связано с тем, что универсального подхода для редиректов, аутентификации, создания и удаления пользователей сложно добиться — каждая система может иметь свои уникальные требования.
Ранее мы уже работали с Keycloak и CRM Битрикс24, модифицировав модуль социальных сервисов для входа через Keycloak. Однако в данном проекте клиенту требовалась более глубокая интеграция, без посредников в виде соцсетей. Поэтому стандартные решения не подошли.
Первоначально была идея подключить 1С-Битрикс через модуль OpenID Connect (OIDC) для Apache, который заказчик использовал для других систем. Но после нескольких попыток мы поняли, что модуль не обеспечивал необходимую работу с платформой, и решили разработать собственное решение на основе API Keycloak и API нашей платформы.
Как была реализована интеграция Keycloak и 1С-Битрикс
Мы внедрили авторизацию через Keycloak по протоколу OpenID Connect. Основная задача — сделать процесс авторизации незаметным для пользователя, чтобы переход между системами был плавным.
Чтобы пользователи не ощущали перехода между системами всё было сделано на скрытых редиректах.
Для этого с самого начала определились со ссылкой по которой будем перенаправлять пользователя. Любая ссылка взаимодействия с keycloak строится по следующему принципу:
<keycloakUrl> – Это базовый URL, на котором развернут сервер аутентификации, например https://your-keycloak-domain.com
<realmName> – область работы, создаваемая на стороне Keycloak, используется для организации пользователей, клиентов и настроек безопасности.
Методами <method> могут быть:
auth – используется для начала процесса аутентификации пользователя;
logout – используется для выхода пользователя из системы;
token – используется для получения, обновления или отзыва токенов;
userinfo – используется для получения информации о пользователе.
В качестве GET-параметров <params> выступают:
response_type – код ответа, который мы ждем в ответе. Обычно это code для авторизационного кода.
scope – область доступа в которой мы хотим работать. Обычно включает openid и может включать другие области, такие как profile или email.
client_id – ID клиента, который используется для аутентификации.
redirect_uri – URI, на который Keycloak будет перенаправлять пользователя после аутентификации с кодом авторизации. redirect_uri должна быть закодирована в формате процентного кодирования (percent-encoding). В эту ссылку можно положить обработчик аутентификации.
Все постоянные параметры были вынесены в настройки модуля и указываются при первоначальной настройке интеграции.
Если настройки пустые, то авторизация работать не будет.
Когда пользователь заходит на сайт, то вместо формы авторизации он попадает на ссылку вида:
https://your-keycloak-domain.com/auth/realms/your-realm-name/protocol/openid-connect/auth?response_t...
Дальше происходит его идентификация на стороне Keycloak.
Если пользователь авторизован в Едином личном кабинете (ЕЛК) компании, но в профиле в Keycloak доступ на B2B-платформу ему не разрешен, то попасть на нее он не сможет.
Если пользователь авторизован в ЕЛК, то он сразу перенаправляется по ссылке redirect_uri, куда в GET-параметры передается code (код авторизации).
С помощью code нельзя получить информацию о пользователе, но можно получить access_token. Это нужно по следующим причинам:
Code передается через браузер пользователя и может быть перехвачен. Поэтому он не предоставляет прямого доступа к ресурсам пользователя. Access_token же передается защищенным образом.
Code действителен только в течение короткого времени и предназначен только для однократного использования для получения access_token.
После аутентификации пользователь перенаправляется обратно с кодом авторизации, который затем обменивается на access_token на сервере приложения. Это позволяет серверу приложения получать токены безопасно, без риска их утечки через браузер.
Использование кода как токена доступа было бы небезопасным, так как это упростило бы атаки типа “man-in-the-middle”. Поэтому после получения кода авторизации приложение делает отдельный запрос к серверу Keycloak для обмена кода на access_token.
В обработчике мы проверяем наличие параметра code. Если он есть, то зная его можно получить access_token. Для этого делаем запрос к Keycloak на URL вида:
<keycloakUrl>/auth/realms/<realmName>/protocol/openid-connect/token
В теле передаются следующие параметры:
grant_type – используемый тип авторизации, для получения access_token значение должно authorization_code;
code – код авторизации, полученный на предыдущем шаге;
client_id – идентификатор клиента, который используется для аутентификации. Он должен совпадать с тем, что был зарегистрирован в Keycloak;
client_secret – секретный ключ клиента;
redirect_uri – URI, на который keycloak перенаправит пользователя.
В случае успеха в ответ приходит access_token, который представляет собой JSON Web Token (JWT). Он содержит данные, необходимые для безопасного взаимодействия с API. Зная access_token мы получаем информацию о пользователе из Keycloak, чтобы выполнить вход в Битрикс. Для этого нужно сформировать URL вида:
<keycloakUrl>/auth/realms/<realmName>/protocol/openid-connect/userinfo
Далее необходимо выполнить авторизацию по Bearer-токену, значением которого будет access_token. Для этого в запрос добавляем строку:
Authorization: Bearer YOUR_ACCESS_TOKEN
В случае успеха, обработчиком будет получен ответ в JSON с информацией о пользователе:
На основании данных, содержащихся в ответе, можно определить существует ли данный пользователь в БУС (на b2b-платформе). Если нет, то его можно создать и сразу же деактивировать, чтобы администратор самостоятельно принял решение по его дальнейшей настройке. До активации пользователь будет видеть «заглушку» о том, что учетная запись находится на проверке.
Как вы можете видеть, в JSON с информацией о пользователе нет пароля, он генерируется на стороне B2B-платформы. В качестве пароля выступает длинная случайно-генерируемая строка. Таким образом, доступ к платформе можно получить только через Keycloak. Если внутри брокера ограничить доступ пользователя к какому-либо приложению, то войти в него он не сможет даже при наличии валидных учетных данных.
Если пользователь найден, то он автоматически авторизуется на платформе.
Выход из аккаунта происходит также по ссылке, создаваемой на бэкенде. При нажатии на кнопку “Выйти из аккаунта”, осуществляется выход из аккаунта B2B-платформы, далее пользователь перенаправляется на Keycloak, где выходит автоматически.
Функционал регистрации и восстановления пароля не реализовывался — за это целиком отвечает Keycloak.
Отметим, что вход в административную часть 1С-БУС через стандартную форму авторизации также возможен. Такая возможность требуется, чтобы обмен с 1С оставался доступным и выполнялся без проблем.
Индивидуальные сценарии и поддержка
Наш модуль интеграции не является универсальным — его логика, редиректы и создание пользователей зависят от конкретных бизнес-процессов и требований. Для каждой компании могут потребоваться свои доработки.
На этом всё. Буду рад ответить на вопросы, задавайте в комментариях! Или делитесь своим опытом, тоже интересно! ;)
А если вы бизнес и ищете решение для безопасного управления доступом в своих системах и хотите интегрировать Keycloak с Битрикс — мы готовы помочь. У нас есть опыт внедрения Keycloak как штатного брокера авторизации. Рассмотрим ваши задачи, предложим решение и обеспечим поддержку на протяжении всего проекта.
