SSO-авторизация в Битрикс24 с Keycloak

• Глава, которую можно пропустить
• Задача
• Варианты SSO-авторизации в Битрикс24
  • «Облачная» авторизация от Microsoft
  • Локальная NTLM-авторизация от Битрикс
  • Вход через службу аутентификации 
  • Интеграция с внешним сервисом аутентификации, поддерживающим SSO
• Адаптация Keycloak
  • А. Доработка модуля интеграции Keycloak: добавление возможности просматривать портал неавторизованным пользователям
  • Б. Доработка модуля интеграции Keycloak с добавлением определения устройства
• Перспективы развития модуля интеграции

Когда мы писали о своем опыте интеграции Keycloak (система аутентификации и управления доступом) с B2B-платформой на базе CMS «1С-Битрикс:Управление сайтом», то не предполагали, что тема так популярна. Оказалось, что многие ищут варианты организации доступа к нескольким приложениям и сервисам с помощью одной учетной записи, но сталкиваются с различными ограничениями. Сегодня расскажем о том, как Keycloak может помочь в этом вопросе, и покажем, как интегрировали его с еще одним продуктом — корпоративным порталом Битрикс24.

Глава, которую можно пропустить

AD (Active Directory) — самостоятельная локальная служба каталогов, хранящая учетные данные пользователей, компьютеров и групп в домене. Она обеспечивает: аутентификацию (проверку логинов/паролей), авторизацию (управление правами доступа), централизованное управление политиками. Используется в корпоративных сетях для входа в Windows, VPN, почту и другие локальные сервисы. Поддерживает протоколы Kerberos, NTLM (устарел).

ADFS (Active Directory Federation Services) — служба, которая расширяет возможности AD, позволяя организовать единый вход (SSO) в системы и приложения за пределами границ организации (облачные приложения, другие AD-домены). Поддерживает стандарты SAML, OAuth, OpenID Connect.

OAuth2 — протокол авторизации, позволяющий различным системам обмениваться данными с разрешения пользователя (без передачи логина/пароля).

OIDC (OpenID Connect) — безопасный механизм, позволяющий приложению связаться со службой идентификации, чтобы получить необходимые данные о пользователе и вернуть их обратно в приложение, обеспечив полную защиту информации. Является расширением OAuth2. Применяется, если нужно реализовать «Войти через Google» и узнать кто пользователь.

SSO — метод, позволяющий пользователю проходить аутентификацию один раз для доступа ко всем доверенным системам.

Задача

Крупному столичному телекоммуникационному провайдеру потребовалось настроить сквозную авторизацию (SSO): при входе в операционную систему сотрудник должен быть автоматически авторизован и в Битрикс24 (Б24) без повторного ввода логина/пароля. При выборе способа авторизации нужно было учесть, что пользователь может попасть на портал любым из трех способов:

• непосредственно с рабочего компьютера в офисе;

• работая удаленно через VPN;

• через мобильное приложение.

Варианты SSO-авторизации в Битрикс24

«Облачная» авторизация от Microsoft

У Б24 уровня Энтерпрайз есть встроенная возможность настройки единого входа, где управление доступом обеспечивается Microsoft Azure Active Directory — системой управления доступом к приложениям и сервисам в «облаке», но с сентября 2024 года для российских пользователей доступ к ней ограничен. У тех компаний, которые найдут возможность оплачивать «облако», Microsoft Azure AD, скорее всего, продолжит работать, но риски никуда не денутся. Такой вариант не получил развития еще и потому, что заказчику нужно было обеспечить закрытый контур, а для этого потребовалось бы что-то донастраивать на сетевом уровне.

Локальная NTLM-авторизация от Битрикс

Для централизованного управления доступом к ресурсам корпоративной сети заказчик использует AD. Можно было пойти по пути подключения авторизации пользователей из AD в Б24 через модуль, доступный из «коробки». Однако этот модуль использует протокол NTLM и способы проверки подлинности Basic Auth или Digest, которые уже не дотягивают до современных стандартов. Чтобы не подвергать систему опасности было решено отказаться от готового модуля. Еще одним аргументом «против» стало то, что провайдер работает с Docker-контейнерами. Настроить авторизацию в приложении, находящемся в Docker, проблематично, т.к.:

• контейнеру нужно как-то обращаться к LDAP/AD или OAuth-провайдерам;

• пароли, API-ключи или SSL-сертификаты нельзя хранить в коде образа;

• приложения с сессиями могут некорректно работать из-за динамических IP контейнеров;

• SSL-терминация должна быть настроена либо в контейнере, либо на обратном прокси-сервере.

Более современный способ — через SPNEGO/Kerberos — мог бы помочь с этим, т.к. Битрикс такой способ тоже поддерживает. Но попытка заказчика самостоятельно настроить авторизацию посредством развертывания еще одного контейнера nginx с модулем SPNEGO не увенчалась успехом.

Вход через службу аутентификации 

Авторизовываться в различных веб-сервисах через Яндекс ID, VK ID, Сбер ID, T-ID, которые используют OAuth 2.0, WebAuthn и другие, стало уже привычным делом. 

Битрикс также поддерживает авторизацию по OAuth 2.0 (OIDC) через настройку в модуле «Социальные сервисы», но вход на портал через аккаунт Google или социальную сеть — не то решение, которое удовлетворит корпоративного клиента. Тем более, это не замена, а просто еще один дополнительный способ входа. И, что критически важно, провайдер аутентификации никак не связан с пользователями из AD и не имеет к ним доступа.

Если вариант с модулем «Социальных сервисов» не подходит (OAuth не поддерживает AD как источник), то придется лезть в ядро Битрикса и добавлять эту поддержку. Способ интересный, но есть нюансы:

• ядро Битрикс дорабатывать всегда не желательно;

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

Интеграция с внешним сервисом аутентификации, поддерживающим SSO

Таких сервисов достаточно много, большая часть — проприетарные, но есть и open source, например, Casdoor, Zitadel или Keycloak. Именно вариант интеграции с Keycloak оказался наиболее рациональным, тем более он уже был установлен и настроена привязка к AD.

Адаптация Keycloak

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

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


Общая схема работы keycloak.

За стартовую точку разработки был взят модуль интеграции Keycloak с нашей B2B-платформой. Только с выходом версии Keycloak 17 в нем немного поменялся шаблон URL.

Прежний URL: <keycloakUrl> + '/auth/realms/' + <realmName> + '/protocol/openid-connect/' + <method> + ? + <params>

Новый URL: <keycloakUrl> + '/realms/' + <realmName> + '/protocol/openid-connect/' + <method> + ? + <params>

У заказчика Keycloak выступает в качестве прослойки между AD и порталом, которая гарантирует, что пользователи из AD будут проходить аутентификацию через единую точку. Однако следовало учесть одну особенность: некоторые разделы портала (например, Ленту) хотели разрешить просматривать неавторизованным пользователям.

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

Как это работает.

В любой «закрытой» системе на этапе авторизации проверяется наличие соответствующих прав у пользователя ещё до момента загрузки контента, и Битрикс здесь не исключение. При установке модуля интеграции с Keycloak его можно внедрить в логику, которая срабатывает во время загрузки страницы. Тогда вместо формы авторизации Б24 пользователь будет перенаправлен на форму Keycloak, где авторизуется и получит доступ к ресурсам системы.

Чтобы позволить неавторизованному пользователю просматривать страницы портала, нужно немного изменить подход и настройки. Вместо внедрения в логику, срабатывающую перед загрузкой страницы, нужно внедриться в логику, которая срабатывает перед отображением формы авторизации. Битрикс24 будет сам определять, имеет ли неавторизованный пользователь право на просмотр страницы или нет, и если нет — будет отображать форму авторизации. Так как в Б24 форма авторизации хранится в виде компонента system.auth.authorize, то можно внедрится в логику, обрабатываемую непосредственно перед отображением этого компонента, и поставить там перенаправление на Keycloak.

Другими словами, если портал настроен на просмотр отдельных страниц неавторизованным пользователем, то «разрешенные» страницы загрузятся. Если пользователь попробует попасть в закрытый раздел, то модуль интеграции предложит авторизоваться. Если все условия для входа по Keycloak совпали (об этом ниже) — пользователь будет перенаправлен на его форму авторизации, если не совпали — будет показана форма Битрикса.

Решение стабильно работает: если пользователи заходят с корпоративных ПК, то попадают на портал без дополнительной авторизации. Не нужно еще раз вводить логин/пароль и нажимать кнопку «Войти».

Б. Доработка модуля интеграции Keycloak с добавлением определения устройства

Бесшовная авторизация работает, если сотрудники находятся в офисе. А что с удаленщиками и пользователями мобильных устройств? Они ведь могут заходить на портал с девайсов, которые не привязаны к Active Directory, например, через мобильное приложение или личный ПК с использованием корпоративного VPN. Сюда же относятся и десктопные приложения Б24, так как для переадресации на Keycloak каждому из них должны быть выданы соответствующие разрешения и доступы в админке.

После анализа ситуации было принято решение, что интеграция с Keycloak будет работать только через web версию. Для этого функционал модуля был дополнен функциями, определяющими, с какого устройства пользователь зашел на портал.

• VPN: проверка разрешенной подсети.

• Мобильное приложение: проверяем, определена ли константа BX_MOBILE, а также дополнительная проверка классом конверсии, который определяет, зашёл ли пользователь с мобильного устройства.

• Десктоп: по наличию в запросах атрибута BXD_API_VERSION или BitrixDesktop в заголовке запросов.

• Веб: во всех остальных случаях.

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

Итоговая схема работы модуля выглядит так.

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

Мы уже умеем «сшивать» Keycloak с сайтом и с корпоративным порталом по отдельности и продолжаем развивать функциональность модуля интеграции. Новая задача — обеспечить условия для авторизации одновременно в Б24 и на сайте через SSO. Заказчик — российский производитель IT-оборудования. В экосистеме компании есть корпортал и два сайта: один с личным кабинетом для внешних пользователей, другой — с конфигуратором оборудования.

Сотрудники, которые авторизуются в операционной системе через AD, должны без лишних движений авторизовываться в Битрикс24 и на сайте с конфигуратором. Внешние пользователи, заходя в свой личный кабинет на сайте, также должны без повторного ввода логина/пароля попадать и в конфигуратор. Другими словами, внутри одной системы нужно создать раздельные контуры для аутентификации внутренних и внешних пользователей.