Очередной пост о том, что мы делаем. В этот раз расскажу вам о том, как мы обеспечили  безопасность информационных баз 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С согласно документации.

2. Создали и опубликовали информационные базы 1С, согласно официальной документации.

3. Настроили параметры подключения к Keycloak для каждой информационной базы 1С в файле default.vrd, указав адрес, идентификатор и секрет клиента, созданного в Keycloak.

4. Настроили параметры пользователей 1С, указав тип аутентификации (OpenID Connect) и адрес электронной почты в качестве имени пользователя.

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

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

1. Пользователь подключается тонким клиентом 1С к информационной базе на веб‑сервере.

2. Перенаправляется на страницу входа Keycloak.

3. Вводит имя и пароль. Если пользователь входит впервые, ему предлагается выполнить смену пароля.

4. Перенаправляется на страницу подтверждения f2a, где он должен ввести OTP‑код, полученный в OTP‑приложении на мобильном устройстве. Если пользователь входит впервые, ему предлагается привязать новое устройство с приложением для генерации OTP‑кода.

5. Вводит OTP‑код и нажимает кнопку «Подтвердить».

6. Тонкий клиент 1С получает (незаметно для пользователя) access token от Keycloak, который содержит информацию о его идентификации.

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

8. Сервер 1С проверяет подлинность и валидность токена, используя ключи и конечные точки, предоставленные Keycloak.

9. Сервер 1С сопоставляет имя пользователя из маркера доступа с именем пользователя в базе 1С и предоставляет пользователю доступ к ней в соответствии с его правами.

10. Пользователь может работать с базой 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. Если у вас остались вопросы или вы готовы дополнить материал, мы будем рады вашей обратной связи в комментах.