OpenID Connect в 1С: что это и как настроить

OpenID Connect (OIDC) — это протокол аутентификации, построенный поверх OAuth 2.0, который позволяет пользователю входить в приложение через внешнего провайдера идентификации вместо ввода логина и пароля самой системы. В контексте 1С это означает, что пользователь информационной базы может авторизоваться через корпоративный сервер аутентификации (например, Keycloak, Active Directory Federation Services или другой OIDC-провайдер), а 1С получает подтверждение личности в виде подписанного токена.

Платформа 1С:Предприятие поддерживает OpenID Connect как один из способов аутентификации наряду с парольной, аутентификацией операционной системы и сертификатами. Механизм работает для клиентских приложений, подключающихся к серверу 1С, и для веб-клиента, опубликованного на веб-сервере. Настройка выполняется на стороне публикации и в конфигураторе, а сам провайдер OIDC разворачивается и администрируется отдельно.

Тема актуальна для организаций, где уже действует единая точка входа (Single Sign-On): сотрудник один раз проходит аутентификацию в корпоративной системе и далее работает в 1С без повторного ввода пароля. Это снижает количество забытых паролей, упрощает блокировку доступа при увольнении и централизует политику безопасности.

Как работает аутентификация OpenID Connect в 1С

Схема взаимодействия включает три стороны: пользователя с клиентским приложением 1С, провайдера OIDC и сервер 1С (или веб-сервер с публикацией). Когда пользователь запускает клиент, платформа перенаправляет запрос аутентификации провайдеру. Пользователь вводит свои корпоративные учётные данные уже на странице провайдера — 1С этот пароль не видит и не хранит.

После успешной проверки провайдер возвращает платформе токен — подписанную структуру данных, содержащую идентификатор пользователя и дополнительные атрибуты (claims). Платформа проверяет подпись токена, срок его действия и извлекает идентификатор, по которому ищет соответствие в списке пользователей информационной базы. Если соответствие найдено, сеанс открывается от имени этого пользователя.

Важно понимать: OIDC отвечает только за аутентификацию — подтверждение того, кто пользователь. Авторизация, то есть права на объекты конфигурации, по-прежнему определяются ролями, назначенными пользователю внутри 1С. Провайдер не управляет ролями в конфигурации, если специально не настроено дополнительное сопоставление.

Что нужно подготовить перед настройкой

До начала настройки убедитесь, что выполнены базовые условия. Во-первых, должен быть развёрнут и доступен по сети OIDC-провайдер с поддержкой стандартных сценариев (authorization code flow). Во-вторых, версия платформы 1С:Предприятие должна поддерживать аутентификацию OpenID Connect — этот механизм появился не в самых ранних релизах, поэтому проверьте документацию к вашей версии платформы.

В-третьих, для веб-клиента потребуется публикация информационной базы на веб-сервере (Apache или IIS) с настроенным HTTPS: передача токенов по незашифрованному соединению недопустима, большинство провайдеров откажутся работать по HTTP. В-четвёртых, у вас должны быть административные доступы ко всем трём компонентам: провайдеру, веб-серверу и конфигуратору 1С.

На стороне провайдера потребуется зарегистрировать 1С как клиентское приложение: указать допустимые адреса перенаправления (redirect URI), получить идентификатор клиента и, если провайдер этого требует, секрет клиента. Эти параметры понадобятся при настройке публикации.

Настройка публикации и параметров провайдера

Для веб-клиента параметры OIDC указываются в файле публикации default.vrd, который лежит в каталоге публикации на веб-сервере. В нём описывается элемент, задающий адрес провайдера, идентификатор клиента и связанные параметры аутентификации. Точные имена атрибутов зависят от версии платформы, поэтому сверяйте синтаксис с документацией на ваш релиз.

Типовой фрагмент настройки в default.vrd выглядит примерно так (имена атрибутов приведены для иллюстрации структуры):

<point name="OpenIDConnect" enable="true">
  <provider url="https://idp.example.com/realms/main" clientID="onec-client" clientSecret="SECRET"/>
</point>

После изменения default.vrd перезапустите веб-сервер, чтобы публикация перечитала настройки. Для Apache это команда перезапуска службы, для IIS — перезапуск пула приложений или команда iisreset. Без перезапуска старые параметры продолжат действовать, и вы будете отлаживать несуществующую конфигурацию.

Для тонкого и толстого клиента, подключающихся к кластеру серверов, настройка выполняется иначе — параметры провайдера задаются на уровне информационной базы в консоли кластера или через конфигуратор, в зависимости от версии платформы. Принцип тот же: указать адрес провайдера и параметры клиентской регистрации.

Сопоставление пользователей провайдера и информационной базы

В карточке пользователя информационной базы (раздел администрирования или справочник пользователей в конфигураторе) указывается, что аутентификация выполняется через OpenID Connect, и задаётся идентификатор, по которому платформа будет искать соответствие. Обычно это значение одного из claims токена — чаще всего sub (уникальный идентификатор субъекта у провайдера) или предпочитаемое имя пользователя.

Практический порядок действий при добавлении пользователя:

1. 1
   Узнайте у администратора провайдера, какой claim используется как уникальный идентификатор (обычно sub)
2. 2
   Откройте карточку пользователя в конфигураторе или в режиме предприятия
3. 3
   Включите для пользователя аутентификацию OpenID Connect и укажите идентификатор из токена
4. 4
   Назначьте пользователю роли и права в конфигурации
5. 5
   Войдите под этим пользователем через OIDC и проверьте доступные функции

Если пользователей много, заводить их вручную трудоёмко. В таких случаях пишут обработку загрузки пользователей из выгрузки провайдера (через его API или файл) с автоматическим заполнением идентификаторов. Это уже задача разработки, и её сложность зависит от того, какие данные отдаёт конкретный провайдер.

Проверка результата и диагностика

После настройки проверьте полный цикл входа: запустите клиент, убедитесь, что открывается страница провайдера, введите учётные данные тестового пользователя и дождитесь возврата в 1С с открытым сеансом. Проверьте также обратный сценарий — вход пользователя, которого нет в информационной базе: система должна корректно отказать во входе, а не зависать или показывать пустое окно.

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

Типичные ошибки и ограничения

Из ограничений стоит учитывать зависимость от доступности провайдера: если сервер аутентификации недоступен, пользователи с OIDC-входом не смогут войти в 1С. Поэтому рекомендуется оставить хотя бы одну административную учётную запись с парольной аутентификацией 1С — на случай аварии у провайдера или ошибок в его настройке.

Ещё одно ограничение — поведение при истечении токена. Сеанс 1С и срок жизни токена провайдера живут по своим правилам; при настройке политик на стороне провайдера согласуйте их с ожидаемой длительностью рабочих сессий пользователей, чтобы не получить массовые повторные входы в середине рабочего дня.

Когда OIDC оправдан, а когда проще обойтись без него

Если в организации несколько десятков пользователей и нет централизованной системы управления доступом, внедрение OIDC ради одной базы 1С, скорее всего, не окупится — проще использовать доменную аутентификацию. Напротив, если 1С — одна из многих систем, куда входят сотни сотрудников, единый вход через OIDC заметно снижает нагрузку на администраторов и службу поддержки.

Частые вопросы