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С). Если же клиентская лицензия установлена у пользователя локально, то тонкий клиент не сможет подключиться и получит от сервера сообщение «Невозможно установить сеанс пользователя».(подробнее — в следующей части)
По этому поводу зарегистрирована ошибка 70076754: 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/000151413), в будущем она, вероятно, будет исправлена. Временное решение — использовать достаточное количество клиентских лицензий на сервере и в кластере 1С.
Эта ситуация подчеркивает важность наличия клиентских лицензий на сервере для успешной аутентификации через OpenID Connect и может служить уроком для других компаний, сталкивающихся с подобными задачами.
Заключение
Надеемся, что наш опыт будет полезен коллегам, если они столкнутся с подобной задачей в своих проектах, а потенциальные клиенты узнали достаточно о наших способностях и компетенциях в интеграции систем 2FA. Если у вас остались вопросы или вы готовы дополнить материал, мы , будем рады вашей обратной связи в комментах.
