Как ограничить вход в базу 1С только через JWT и устранить ошибку запрета соединений?

← На главную

Начиная с версии платформы «1С:Предприятие 8.3.26», разработчикам и администраторам стал доступен механизм тонкого управления элементами интерактивной формы аутентификации через файл публикации веб-сервера default.vrd. Нередко возникает задача полностью отключить стандартный диалог ввода логина и пароля, оставив доступ к информационной базе исключительно по токенам доступа JWT (JSON Web Token). Однако при такой настройке можно столкнуться с ситуацией, когда веб-клиент или тонкий клиент выдает ошибку о том, что для базы «запрещены любые соединения». Разберем по шагам, как устроена аутентификация по токенам, почему возникает подобное поведение платформы и как правильно организовать работу.

Архитектура настройки аутентификации в файле default.vrd

Проанализируем структуру секции <authentication> в конфигурационном файле публикации default.vrd. Важно понимать разграничение между отображением интерактивной формы входа и фоновой валидацией токенов доступа:

Элемент <logonView> отвечает исключительно за визуальные элементы интерактивной формы аутентификации, которая открывается пользователю в браузере или тонком клиенте.
В атрибуте type тега <method> поддерживаются только интерактивные способы входа:
1. standard — стандартная аутентификация системы «1С:Предприятие» (логин и пароль);
2. email — аутентификация по ссылке/коду через электронную почту;
3. openID — вход через провайдер OpenID;
4. openidconnect — вход через OpenID Connect;
5. qr — аутентификация с помощью QR-кода.
Входа по JWT как отдельного визуального метода в блоке <logonView> не существует, поскольку передача токена происходит в фоновом режиме (через параметры командной строки, URL-параметры или HTTP-заголовки) без участия интерактивной формы выбора учетной записи.

Рассмотрим пример конфигурации default.vrd, в которой скрывается стандартная форма логина и пароля:


<authentication>
    <logonView>
        <method type="standard" visible="false"/>
    </logonView>
    <accessTokenAuthentication>
        <issuers>
            <issuer name="https://auth.company.local"
                    authenticationClaimName="sub"
                    authenticationUserPropertyName="name"
                    keyInformation="MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz..."/>
        </issuers>
    </accessTokenAuthentication>
</authentication>

Механизм отката (Fallback) и причина ошибки «Запрещены любые соединения»

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

Клиент обращается к публикации и передает JWT-токен (например, в параметре AccessToken строки URL или заголовке Authorization: Bearer).
Платформа успешно проверяет валидность структуры токена, срок его жизни (клейм exp) и цифровую подпись с использованием ключа из keyInformation.
Далее платформа извлекает значение клейма, указанного в параметре authenticationClaimName (например, sub или email), и ищет соответствующего пользователя в информационной базе по свойству, указанному в authenticationUserPropertyName (name, OSUser или email).
Критический момент: если значение клейма не совпадает со свойством пользователя ИБ (например, из-за опечатки, лишнего пробела, несовпадения регистра или другого формата логина), платформа считает попытку бесшовной аутентификации неудачной.
Вместо вывода явного диагностического сообщения о том, что пользователь по токену не найден, платформа инициирует стандартную процедуру отката (fallback) — переключение на стандартное окно интерактивного ввода логина и пароля.
Так как в файле default.vrd для метода standard установлено значение visible="false" (а другие интерактивные методы не настроены), платформа обнаруживает, что ни один интерактивный способ входа не разрешен, и возвращает общее критическое предупреждение: «Запрещены любые соединения с базой 1С».

Пошаговый чек-лист для проверки и решения проблемы

Разберем практические шаги, которые необходимо выполнить для устранения ошибки и корректной настройки входа по JWT:

Проверяем флаг у пользователя информационной базы:
Откроем информационную базу в режиме «Конфигуратор», перейдем в меню Администрирование -> Пользователи. В свойствах пользователя убедимся, что установлен флаг «Аутентификация токеном доступа» (или проверим программную установку свойства ПользовательИнформационнойБазы.АутентификацияТокеномДоступа = Истина).
Сверяем сопоставляемые поля:
Проанализируем состав payload токена и настройки в default.vrd. Если в параметре authenticationUserPropertyName указано значение name, то значение клейма sub должно символ в символ (включая регистр и специальные символы) совпадать с системным реквизитом «Имя» (а не «Полное имя»!) пользователя ИБ.
Анализируем Журнал регистрации:
Из соображений безопасности платформа не сообщает клиенту точную причину отказа. Откроем Журнал регистрации в рабочей базе и установим отбор по событию Сеанс.Аутентификация или Сеанс.Ошибка аутентификации. В тексте события будет указана точная причина: Токен доступа: не найден пользователь, Срок действия токена истек либо Неверная подпись токена.
Временная диагностика через стандартную форму:
Для локализации проблемы временно включим стандартную форму входа, установив <method type="standard" visible="true"/>. Если при переходе по ссылке с токеном открывается форма ввода логина и пароля вместо автоматического входа — сопоставление пользователя или проверка токена гарантированно терпит неудачу.

Способы передачи токена доступа клиентам 1С

Рассмотрим, как правильно передавать полученный JWT-токен в зависимости от используемого типа клиента:

Для веб-клиента: передаем токен в URL публикации в качестве GET-параметра:
https://server.domain.ru/base_name/?AccessToken=eyJhbGciOiJSUzI1NiIsInR5cCI6...
Для тонкого клиента: используем параметр командной строки запуска:
1cv8c.exe ENTERPRISE /IBConnectionString "ws='https://server.domain.ru/base_name';" /AccessToken "eyJhbGciOiJSUzI1Ni..."
Для HTTP- и Web-сервисов: передаем токен в заголовке HTTP-запроса:
Authorization: Bearer eyJhbGciOiJSUzI1Ni...

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