При попытке настроить авторизацию пользователей в 1С:Предприятие через OpenID Connect с использованием Microsoft Azure Active Directory (теперь известного как Entra ID), многие пользователи сталкиваются с загадочной ошибкой после успешной аутентификации в Azure. Эта ошибка, проявляющаяся в виде сообщения с трассировкой стека vrsbase.dll, может сбить с толку из-за отсутствия явных указаний на причину. В этой статье мы подробно разберем, как исправить эту распространенную проблему, рассмотрим альтернативные методы сопоставления пользователей и узнаем, как работать с данными провайдера для управления правами.
Первоначальная проблема, с которой мы часто сталкиваемся, заключается в том, что после успешной аутентификации в Microsoft Azure, при попытке вернуться в базу 1С через браузер или тонкий клиент, система выдает ошибку, подобную следующей:
{"#exception":"{ vrsbase.dll:0x000000000006F38D ... unknown:0x0000000000000000 "}}
Одной из наиболее частых причин этой ошибки является некорректно заданный параметр scope (область действия) в файле публикации 1С — default.vrd. Согласно многим инструкциям для Microsoft Azure, иногда указывается только "scope": "openid". Однако на практике этого может быть недостаточно, особенно если 1С ожидает дополнительные сведения о пользователе, такие как его адрес электронной почты для сопоставления.
Суть проблемы:
1С пытается сопоставить пользователя, прошедшего аутентификацию в Azure, с существующим пользователем информационной базы. Если в токене OpenID Connect отсутствует необходимая информация (например, адрес электронной почты), которую 1С использует для сопоставления, система не может найти соответствующего пользователя и выдает ошибку. Стандартная область "openid" гарантирует только базовую информацию об идентификации. Для получения адреса электронной почты требуется дополнительная область "email".
Шаги по устранению проблемы:
default.vrd, который находится в корневой папке публикации вашей информационной базы 1С.<openidconnect>, которая определяет параметры подключения к OpenID Connect провайдеру."scope"."openid" на "openid email".Вот как может выглядеть измененная часть файла default.vrd:
<openidconnect>
<name>AzureOpenID</name>
<title>Войти через Microsoft Azure</title>
<authenticationClaimName>email</authenticationClaimName>
<discovery>https://login.microsoftonline.com/<tenant_id>/v2.0/.well-known/openid-configuration</discovery>
<scope>openid email</scope> <!-- Ключевое изменение здесь -->
<client_id>ВАШ_CLIENT_ID_ИЗ_AZURE</client_id>
<client_secret>ВАШ_CLIENT_SECRET_ИЗ_AZURE</client_secret>
<redirect_uri>https://your_1c_app.com/authform.html</redirect_uri>
</openidconnect>
После сохранения изменений и перезапуска веб-сервера (если требуется), авторизация должна пройти успешно, и пользователи будут сопоставлены по их адресам электронной почты.
В некоторых случаях, или для более гибкой настройки, мы можем использовать другое утверждение (claim) для сопоставления пользователей, например, preferred_username. Это утверждение часто рекомендуется Microsoft для отображения имени вошедшего пользователя, поскольку upn (имя участника-пользователя) не всегда является постоянным идентификатором и может быть скрыт при использовании альтернативных идентификаторов входа. Для такого подхода нам потребуется выполнить дополнительные настройки как в Microsoft Azure, так и в файле default.vrd.
Предполагаем, что ваше приложение 1С уже зарегистрировано в портале Azure в разделе Azure Active Directory > App registrations. Если нет, создайте новую регистрацию, указав имя и поддерживаемые типы учетных записей. Обязательно добавьте Redirect URI в формате <URL вашего приложения 1С>/authform.html. Получите Application (client) ID и сгенерируйте Client Secret.
Перейдем в раздел Authentication для нашего зарегистрированного приложения в Azure Portal. В секции Implicit grant and hybrid flows необходимо отметить оба пункта:
Это гарантирует, что при аутентификации будут выдаваться необходимые ID-токены.
Перейдем в раздел Token configuration. Нажмем Add optional claim. Выберем тип токена ID и добавим утверждение preferred_username. Это позволит нам получать это утверждение в ID-токене, который 1С будет использовать для сопоставления.
Чтобы избежать запроса разрешения для нашего приложения у каждого пользователя при первом входе, нам следует предоставить административное согласие. Перейдем в раздел Enterprise Application > Permissions и нажмеем кнопку Grant admin consent for ....
После настройки приложения в Azure, нам необходимо обновить файл default.vrd в 1С, чтобы он ожидал утверждение preferred_username для сопоставления.
default.vrd.<openidconnect> изменим параметр "authenticationClaimName" на "preferred_username"."scope" содержит "openid email profile". Добавление "profile" гарантирует получение preferred_username, а "email" полезен для дополнительной информации.Пример секции <openidconnect> с использованием preferred_username:
<openidconnect>
<name>AzureOpenID</name>
<title>Войти через Microsoft Azure</title>
<authenticationClaimName>preferred_username</authenticationClaimName> <!-- Используем preferred_username -->
<discovery>https://login.microsoftonline.com/<tenant_id>/v2.0/.well-known/openid-configuration</discovery>
<scope>openid email profile</scope> <!-- Расширяем scope -->
<client_id>ВАШ_CLIENT_ID_ИЗ_AZURE</client_id>
<client_secret>ВАШ_CLIENT_SECRET_ИЗ_AZURE</client_secret>
<redirect_uri>https://your_1c_app.com/authform.html</redirect_uri>
</openidconnect>
Важно помнить, что имя пользователя в 1С, с которым будет сопоставляться значение из preferred_username, должно быть в полном формате, обычно включающем домен, например: ivanov@yourcompany.com. Убедимся, что пользователи в 1С созданы с соответствующими именами.
Возникает естественный вопрос: можно ли после успешной авторизации через OpenID Connect программно получить доступ к дополнительным данным, пришедшим от провайдера (например, группы пользователя из Azure AD), чтобы на их основе динамически настроить права доступа или установить значения по умолчанию в 1С? К сожалению, платформа 1С:Предприятие в текущей реализации (по состоянию на версии до 8.3.22 для данного функционала) предоставляет провайдер OpenID Connect исключительно как аутентификатор. Это означает, что после аутентификации контекст параметров payload ответа провайдера напрямую недоступен во встроенном языке 1С.
Ограничение:
Невозможно получить программно payload ответа провайдера непосредственно после аутентификации пользователя в 1С. Это означает, что такие данные, как группы доступа пользователя, напрямую не могут быть использованы для мгновенного назначения прав при входе.
Обходной путь: Использование Microsoft Graph API для управления правами
Несмотря на это ограничение, мы можем реализовать гибкое управление правами доступа пользователей в 1С на основе данных из Microsoft Azure Active Directory (Entra ID) с помощью Microsoft Graph API. Подход заключается в следующем:
Создание регламентного задания в 1С: Мы настраиваем регламентное задание в 1С, которое будет периодически выполняться (например, раз в час или раз в сутки). Это задание будет отвечать за синхронизацию данных о группах пользователей из Azure AD с правами доступа в 1С.
Использование Microsoft Graph API: В рамках регламентного задания 1С будет выполнять HTTP-запросы к Microsoft Graph API. Microsoft Graph API предоставляет унифицированный интерфейс для доступа к данным и функционалу различных сервисов Microsoft, включая Active Directory.
Получение групп пользователя:
Один из ключевых запросов, который мы можем использовать, это user: getMemberGroups. Этот запрос позволяет получить список групп, членом которых является определенный пользователь в Azure AD.
Пример вызова API (для понимания концепции):
GET /users/{id}/getMemberGroups
Content-type: application/json
{
"securityEnabledOnly": true
}
В этом примере {id} — это идентификатор пользователя в Azure AD (например, object ID или userPrincipalName). Параметр "securityEnabledOnly": true позволяет получить только группы безопасности.
Важно: Для выполнения таких запросов нам потребуется зарегистрировать отдельное приложение в Azure AD с соответствующими разрешениями для Microsoft Graph API (например, Group.Read.All или User.Read.All) и получить токен доступа для этого приложения. Все это будет выполняться на стороне 1С в регламентном задании.
Сопоставление и установка прав в 1С: Получив список групп пользователя из Azure AD, регламентное задание сможет анализировать эти группы и на их основе назначать или корректировать роли и права доступа для соответствующих пользователей в информационной базе 1С. Таким образом, мы можем, например, сказать: "Если пользователь состоит в группе 'Бухгалтеры_Azure', то назначить ему роль 'Бухгалтер' в 1С".
Этот подход обеспечивает высокую гибкость и позволяет реализовать сложную логику управления правами, не завися от прямой передачи данных через OpenID Connect в момент аутентификации.
Даже при следовании инструкциям, процесс настройки авторизации может столкнуться с трудностями. Вот несколько общих рекомендаций, которые помогут нам в отладке:
Инструменты вроде Fiddler позволяют перехватывать и анализировать HTTP/HTTPS-трафик между вашим клиентом (браузером или тонким клиентом 1С) и серверами Azure AD/1С. Мы можем увидеть все запросы и ответы, включая токены, перенаправления, параметры scope, client_id и redirect_uri. Это крайне полезно для понимания, на каком этапе происходит сбой и какие данные передаются.
Если мы видим, что аутентификация в Azure прошла успешно, а затем происходит перенаправление обратно на 1С, но с ошибкой, Fiddler поможет нам увидеть, какой именно запрос вызывает проблему и какие параметры он содержит.
Для более глубокой диагностики на стороне 1С, мы можем настроить и использовать технологический журнал платформы. В нем могут быть записи, связанные с ошибками аутентификации OpenID Connect, которые помогут локализовать проблему. Для этого нам нужно создать XML-файл настройки технологического журнала, включающий события, связанные с веб-сервером и механизмом аутентификации.
Убедимся, что Redirect URI (URL-адрес для перенаправления), указанный при регистрации приложения в Microsoft Azure, абсолютно точно совпадает с redirect_uri в файле default.vrd. Даже небольшое несовпадение (например, слэш в конце или его отсутствие, HTTP вместо HTTPS) может привести к ошибкам.
Удостоверимся, что сертификат OpenID Provider (Microsoft Azure) признается клиентом (веб-сервером 1С) как валидный и что мы обращаемся по адресу, на который выдан этот сертификат. Проблемы с SSL-сертификатами могут вызывать ошибки соединения.
Проверим сетевую доступность сервера OpenID Provider (login.microsoftonline.com). Убедимся, что нет блокировок на уровне фаерволов или прокси-серверов.
Разница во времени между сервером 1С и сервером OpenID Connect провайдера может приводить к ошибкам при проверке срока действия токенов. Убедимся, что время на обоих серверах синхронизировано.
Если мы сталкиваемся с ошибкой, содержащей "exception":{"clsid":"bb72372d-4628-4b46-94c8-6d14e227866a", это часто указывает на проблемы, связанные с внутренней обработкой токена 1С, что может быть вызвано некорректным scope или отсутствием ожидаемых утверждений.
Для полного понимания процесса, давайте рассмотрим общий пример секции <openidconnect> в файле default.vrd, объединяя все изученные параметры и лучшие практики:
<?xml version="1.0" encoding="UTF-8"?>
<point xmlns="http://v8.1c.ru/8.3/xcf/oidc"
xmlns:v8="http://v8.1c.ru/8.1/data/core"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="v8:OpenIDConnectAuthPoint">
<name>AzureOpenID</name> <!-- Уникальное имя провайдера в 1С -->
<title>Войти через Microsoft Azure</title> <!-- Заголовок на кнопке входа -->
<!-- Имя утверждения (claim) из токена OpenID Connect, которое будет использоваться для сопоставления с именем пользователя 1С.
Часто используется 'email' или 'preferred_username'. -->
<authenticationClaimName>email</authenticationClaimName>
<!-- URL-адрес для протокола конфигурации OpenID Connect.
Для Azure обычно имеет вид https://login.microsoftonline.com/{tenant_id}/v2.0/.well-known/openid-configuration
или https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration
если используется multi-tenant приложение.
{tenant_id} - это ID вашего каталога (Directory ID/Tenant ID) -->
<discovery>https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration</discovery>
<!-- Список запрашиваемых областей, разделенных пробелами.
'openid' - обязательная область для OIDC.
'email' - запрашивает адрес электронной почты.
'profile' - запрашивает стандартные утверждения профиля (имя, фамилия, preferred_username и т.д.). -->
<scope>openid email profile</scope>
<!-- Идентификатор клиента, полученный при регистрации приложения в Azure (Application (client) ID). -->
<client_id>a1b2c3d4-e5f6-7890-1234-567890abcdef</client_id>
<!-- Секрет клиента, сгенерированный в Azure.
ВНИМАНИЕ: Это чувствительные данные. Храните их безопасно! -->
<client_secret>YourClientSecretValueHere</client_secret>
<!-- URL, на который пользователь будет перенаправлен после успешного входа в систему.
Должен точно совпадать с Redirect URI, указанным в приложении в Azure. -->
<redirect_uri>https://your.1c-app.com/authform.html</redirect_uri>
</point>
Пояснения к параметрам:
<name>: Уникальное имя провайдера в конфигурации 1С. Используется для внутреннего сопоставления.<title>: Текст, который пользователь увидит на кнопке входа на странице авторизации 1С.<authenticationClaimName>: Указывает, какое поле из ID-токена будет использоваться для сопоставления с именем пользователя в базе 1С. Чаще всего это email или preferred_username. Убедимся, что это утверждение присутствует в токене (проверяем настройками в Azure AD).<discovery>: URL-адрес конечной точки обнаружения OpenID Connect (.well-known/openid-configuration). Платформа 1С использует его для автоматического получения всех остальных URL-адресов (авторизации, токена, информации о пользователе) и информации о публичных ключах провайдера.<scope>: Определяет, какие разрешения запрашиваются у провайдера. openid является обязательным для OIDC. email запрашивает адрес электронной почты, а profile — базовую информацию профиля, включая preferred_username. Если мы используем email или preferred_username для сопоставления, то эти scope должны быть запрошены.<client_id>: Уникальный идентификатор вашего приложения, зарегистрированного в Azure AD.<client_secret>: Секрет клиента, используемый для аутентификации вашего приложения на сервере авторизации. Храните его в безопасности и не коммитьте в системы контроля версий без шифрования!<redirect_uri>: URL, на который провайдер OpenID Connect перенаправит пользователя после успешной аутентификации. Он должен точно совпадать с URI, зарегистрированным для вашего приложения в Azure AD, и быть доступен извне, если 1С опубликована в интернете.Для того чтобы аутентификация через OpenID Connect работала корректно, нам необходимо сопоставить пользователей, приходящих из Azure AD, с пользователями в информационной базе 1С. Рассмотрим шаги:
Перейдем в режим "Предприятие" под администратором. Откроем список пользователей (обычно через Администрирование > Пользователи и права > Пользователи).
Создадим нового пользователя или откроем существующего.
В карточке пользователя найдем секцию, отвечающую за аутентификацию. Установим флажок Аутентификация OpenID Connect.
В поле, которое появится (или уже есть), нам нужно будет указать значение, которое приходит от провайдера OpenID Connect и которое мы указали в authenticationClaimName в default.vrd. Например, если мы используем email, то здесь нужно будет ввести полный адрес электронной почты пользователя (ivanov@yourcompany.com). Если используем preferred_username, то также указываем его значение.
Важно: Убедимся, что имя пользователя в 1С также соответствует ожидаемому формату, если это требуется для других подсистем.
Начиная с версии 8.3.22 платформы "1С:Предприятие", для объекта встроенного языка ПользовательИнформационнойБазы появилось свойство КлючиСопоставленияПользователя. Это значительно расширяет возможности по сопоставлению пользователей, позволяя гибко настраивать соответствие пользователя различным ключам сопоставления для разных коммуникационных каналов (например, по почте, СНИЛС, номеру телефона). Если мы работаем с этой версией платформы, рекомендуем изучить эту функциональность для более продвинутых сценариев сопоставления.
Это свойство представляет собой коллекцию, в которую мы можем добавлять записи с различными типами ключей и их значениями, позволяя одному пользователю 1С быть сопоставленным по нескольким внешним идентификаторам.
Следуя этим подробным инструкциям, мы сможем успешно настроить авторизацию пользователей в 1С через OpenID Connect с Microsoft Azure, решить распространенные проблемы с ошибками и использовать гибкие методы сопоставления и управления правами доступа.