2FA для 1С по протоколу OpenID Connect на базе Keycloak

Очередной пост о том, что мы делаем. В этот раз расскажу вам о том, как мы обеспечили безопасность информационных баз 1С с использованием сервиса аутентификации Keycloak через протокол OpenID Connect и настройку двухфакторной аутентификации с помощью OTP-кода.

Немного о задаче и почему выбрали Keycloak?

В проекте миграции 1С в «облако» у нашего заказчика было требование по обеспечению 2FA при авторизации пользователей в 1С. При этом технической возможности использовать в качестве первого фактора имеющуюся инфраструктуру заказчика не было. Причины описать не можем, так как они находились вне рамок проекта.

Было необходимо предложить реализацию, которая:

использует централизованное хранилище информации о пользователях (логинах, паролях и втором факторе);
не требует вмешательства в конфигурацию информационных баз 1С;
предполагает минимальную настройку пользователей на стороне баз данных.

Решили использовать сервис аутентификации, который взаимодействует с 1С по протоколу OpenID Connect. Как вариант максимально соответствующий предъявленным требованиям. На ИТС в инструкции «Совместное использование провайдеров маркеров доступа учетных данных и платформы 1С:Предприятие» упоминались следующие провайдеры: Azure AD, AD FS, Google, ЕСИА и Keycloak.

При всём «богатстве выбора» в качестве провайдера аутентификации решено было использовать решение на базе Keycloak. Во-первых, Keycloak продукт с открытым кодом для реализации single sign-on, во-вторых, в нём существует возможность управления доступом, в-третьих, продукт сфокусирован на современных приложениях и сервисах. Кроме того, Keycloak «из коробки» предлагает возможность использования в качестве второго фактора OTP-код и поддерживает работу со следующими приложениями:

FreeOTP
Google Authenticator
Microsoft Authenticator

Как настраивали Keycloak?

Для авторизации пользователей 1С создали сервер Keycloak. Чтобы хранить данные сервиса, создали один кластер Yandex Managed Service for PostgreSQL.

Настройка Keycloak включала следующие этапы:

Установили и запустили сервер в соответствии с документацией Keycloak.
Сгенерировали реалм (realm) нашего проекта и провели конфигурирование основных параметров: имя, настройка событий, политики паролей и т. д.
Создали клиентов (client) для каждой информационной базы 1С и настроили: имя, тип, секрет, конечные точки, редиректы и т.д.
Создали пользователей для реалма и настроили их параметры, такие как имя, пароль, 2fa, атрибуты и т.д.

Как настроили 1С?

Для настройки 1С мы выполнили следующие шаги:

Установили и запустили серверы приложений 1С и серверы веб-публикации 1С согласно документации.
Создали и опубликовали информационные базы 1С, согласно официальной документации.
Настроили параметры подключения к Keycloak для каждой информационной базы 1С в файле default.vrd, указав адрес, идентификатор и секрет клиента, созданного в Keycloak.
Настроили параметры пользователей 1С, указав тип аутентификации (OpenID Connect) и адрес электронной почты в качестве имени пользователя.

Как работает решение?

После настройки Keycloak и 1С получили такой процесс авторизации пользователей 1С:

Пользователь подключается тонким клиентом 1С к информационной базе на веб‑сервере.
Перенаправляется на страницу входа Keycloak.
Вводит имя и пароль. Если пользователь входит впервые, ему предлагается выполнить смену пароля.
Перенаправляется на страницу подтверждения f2a, где он должен ввести OTP‑код, полученный в OTP‑приложении на мобильном устройстве. Если пользователь входит впервые, ему предлагается привязать новое устройство с приложением для генерации OTP‑кода.
Вводит OTP‑код и нажимает кнопку «Подтвердить».
Тонкий клиент 1С получает (незаметно для пользователя) access token от Keycloak, который содержит информацию о его идентификации.
Перенаправляется обратно в информационную базу 1С, к которой он хочет получить доступ, и передает свой маркер доступа.
Сервер 1С проверяет подлинность и валидность токена, используя ключи и конечные точки, предоставленные Keycloak.
Сервер 1С сопоставляет имя пользователя из маркера доступа с именем пользователя в базе 1С и предоставляет пользователю доступ к ней в соответствии с его правами.
Пользователь может работать с базой 1С пока его токен не истечет или не будет отозван.

Преимущества решения

Безопасность доступа к 1С, защита от несанкционированного входа с помощью двухфакторной аутентификации.
Упрощение управления пользователями, централизация данных авторизации пользователей (логин, пароль, 2fa) в Keycloak. Администратор 1С не сможет отключить использование второго фактора какому‑то пользователю, если ему захочется.
Не требуется вносить изменения в конфигурацию информационной базы 1С, использовать внешние обработки и т. п.
Совместимость с различными конфигурациями информационных баз 1С. OpenID Connect — это штатный функционал платформы 1С.
Применение разных OTP‑приложений на выбор пользователя.

Особенности

Требуются дополнительные ресурсы для развертывания и поддержки серверов Keycloak и базы данных PostgreSQL.
Дополнительные действия пользователей для ввода OTP‑кода при каждом входе в 1С.
Нет поддержки «из коробки» других типов двухфакторной аутентификации, кроме OTP‑кода (SMS, электронная почта, push‑уведомления и т. д.)
1С не поддерживает другие протоколы аутентификации, кроме OpenID Connect, такие как SAML, OAuth и т. д.
На данный момент (февраль 2024) использование данного сценария возможно, только если клиентские лицензии выдаются кластером 1С (установлены на сервере 1С). Если же клиентская лицензия установлена у пользователя локально, то тонкий клиент не сможет подключиться и получит от сервера сообщение «Невозможно установить сеанс пользователя».(подробнее — в следующей части).
По этому поводу зарегистрирована ошибка 70 076 754: https://bugboard.v8.1c.ru/error/000151413. Надеемся, что ее скоро исправят.

Решение проблемы с клиентскими лицензиями 1С при аутентификации через OpenID Connect

При реализации столкнулись с проблемой: если в кластере 1С отсутствуют клиентские лицензии, при попытке авторизации через OpenID Connect возникает ошибка «Невозможно установить сеанс пользователя». Это происходит даже если клиентская лицензия установлена локально и для подключения используется тонкий клиент 1С.

Заказчик использует следующую схему размещения лицензий:

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

Пользователи подключаются к информационным базам, опубликованным на веб‑сервере (ws=»https://server/ib»), используя тонкий клиент. При использовании типа «Аутентификация 1С:Предприятия» проблем с подключением не возникало, а на сервере успешно создавались сессии пользователей с клиентской лицензией. При попытке аутентификации через OpenID Connect возникает ошибка «Невозможно установить сеанс пользователя», так как сервер не мог отыскать лицензию.

Мы обратились в поддержку 1С и, как я уже упоминал, проблема была зарегистрирована как ошибка (https://bugboard.v8.1c.ru/error/000 151 413). Временное решение — использовать достаточное количество клиентских лицензий на сервере и в кластере 1С.

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

Заключение

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

ссылка на оригинал статьи https://habr.com/ru/articles/799961/