Интеграция B2B-платформы на Битрикс с системой авторизации Keycloak

• Задача клиента
• Варианты интеграции Битрикс и Keycloak
• Настройка и интеграция Keycloak с 1С-Битрикс управление сайтом через API

В статье пойдет речь об IAM-продукте (Identity and Access Management), с которым многие компании интегрируют свои системы, чтобы обеспечить сотрудникам единый (Single Sign-On, SSO) доступ сразу ко всем рабочим приложениям. До этого мы делали собственные механизмы авторизации для клиентов с «Битрикс: Управление сайтом», но опыта работы с «королем» опенсорсных IAM'ов еще не было. Расскажем о том какие шишки набили и почему ещё никто не сделал готового модуля интеграции с KeyCloack для магазина приложений Битрикс.

Задача клиента

Главное действующее лицо — ведущий мировой производитель систем отопления и вентиляции, представленный более чем в 60 странах мира. Технологии продаж компании достаточно традиционны, многие вопросы решаются по электронной почте и телефону. В планах было создание интернет-магазина для продаж партнерам.

Для решения этой задачи мы предложили внедрить нашу B2B-платформу. Она позволяет достичь цели снижения трудоемкости и себестоимости продаж путем перевода покупателей на самообслуживание.

B2B-платформа оптовых продаж построена на 1С-Битрикс: Управление сайтом (БУС). Когда пользователь заходит на платформу, его встречает типовая форма авторизации.

Форма авторизации B2B-платформы

Такая обособленная авторизация заказчика не устраивала, т.к. для сотрудников и клиентов в компании используется единая точка входа по технологии SSO на базе Keycloak. 

Форма авторизации в ЕКП

Это удобно: чтобы авторизоваться в сразу в нескольких приложениях нужно ввести логин/пароль всего один раз.

Среди систем заказчика не было ничего на Битрикс, поэтому готового решения по интеграции B2B-платформы с Keycloak тоже не было. В процессе внедрения платформы разработчикам пришлось перебрать и протестировать несколько вариантов.

Варианты интеграции Битрикс и Keycloak

1. В Магазине приложений Битрикса готового модуля интеграции, увы, нет. Хотя интерес к такой разработке со стороны корпоративных пользователей Битрикса есть. Причина отсутствия готового продукта не в том, что его никто не может сделать, а скорее в том, что при наличии определенного общего набора параметров невозможно создать универсальную логику редиректов, аутентификации/выхода пользователей, создания пользователей при первом входе и т.д. А такие универсальные вещи как методы обмена создать можно, но этого недостаточно для работы приложения.

2. Ранее, в одном из проектов, мы интегрировали Keycloak с CRM Битрикс24 через кастомизацию модуля социальных сервисов. Этот модуль позволяет входить через соцсети и его можно модифицировать таким образом, чтобы для авторизации использовался еще и Keycloak. Но, во-первых, заказчик хотел бесшовную интеграцию без посредников в виде соцсетей. Во-вторых, у нашей платформы есть свое API, которое позволяет реализовать эту бесшовность.

3. Заказчик предложил подключить БУС так, как они подключали другие свои системы — с помощью модуля OpenID Connect (OIDC) для Apache. Модуль веб-сервера мог решить задачу глобально. Этот модуль позволяет Apache работать как проверяющая сторона:

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

Однако после нескольких экспериментов модуль корректно так и не заработал, поэтому пришлось такую проверку написать самостоятельно. В ней используется обмен по REST API. B2B-платформа, как и Keycloak, имеет собственное API, поэтому интеграция через него — рабочий способ.

Расскажем подробнее как сделали авторизацию на B2B-платформе через keycloak по протоколу OpenID Connect.

Настройка и интеграция Keycloak с 1С-Битрикс управление сайтом через API

Проектом предусмотрено несколько сценариев авторизации пользователя на B2B-платформе. Покажем работу API на более сложном.

Схема интеграции Keycloack с B2B-платформой.

Чтобы пользователи не ощущали перехода между системами всё было сделано на скрытых редиректах.

Для этого с самого начала определились со ссылкой по которой будем перенаправлять пользователя. Любая ссылка взаимодействия с 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.

1. Если пользователь авторизован в Едином личном кабинете (ЕЛК) компании, но в профиле в Keycloak доступ на B2B-платформу ему не разрешен, то попасть на нее он не сможет.

2. Если пользователь авторизован в ЕЛК, то он сразу перенаправляется по ссылке 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-платформы заказчика.

Выход из аккаунта происходит также по ссылке, создаваемой на бэкенде. При нажатии на кнопку “Выйти из аккаунта”, осуществляется выход из аккаунта B2B-платформы, далее пользователь перенаправляется на Keycloak, где выходит автоматически.

Функционал регистрации и восстановления пароля не реализовывался — за это целиком отвечает Keycloak.

Отметим, что вход в административную часть 1С-БУС через стандартную форму авторизации также возможен. Такая возможность требуется, чтобы обмен с 1С оставался доступным и выполнялся без проблем.

Наш модуль не универсален. Для интеграции Keycloak с другими системами на Битрикс его придется доработать в зависимости от сценариев работы пользователя. Из-за них может поменяться логика редиректов, аутентификации и выхода из аккаунта, логика создания пользователей и др. Сейчас доработка под Keycloak живет внутри модуля платформы и работает только в контексте конкретной интеграции.

Если для вас важно правильно и своевременно предоставлять и отзывать доступ к закрытым ресурсам для ваших клиентов или сотрудников и вы смотрите на keycloack как на инструмент, способный решать ваши задачи — заполните форму внизу. У нас есть опыт внедрения keycloak как штатного брокера авторизации. Обсудим ваши пожелания, составим план внедрения, интегрируем и будем поддерживать весь период жизни проекта.