Как реализовать сквозную аутентификацию (SSO) при использовании веб-сервисов между базами 1С?

← На главную

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

Метод 1: Программная передача учетных данных через объекты WSПрокси

Самый прямой путь, который часто используется в практике, — это явное указание логина и пароля при инициализации соединения. Если мы заранее знаем учетные данные, под которыми должен выполняться запрос (например, выделенный технический пользователь для интеграции), мы можем прописать их непосредственно в коде 1С.

Рассмотрим пример кода, в котором выполняется подключение к внешнему SOAP-сервису. Для этого нам понадобятся объекты WSОпределения и WSПрокси. Обратите внимание, что учетные данные указываются как на этапе получения определений WSDL, так и в самом объекте прокси.


// Создаем определение веб-сервиса, указывая путь к WSDL и учетные данные
Определение = Новый WSОпределения(ПутьДоWsdl, ИмяПользователя, Пароль, , , ИспользованиеSSL);

// Инициализируем прокси-объект для вызова методов
Прокси = Новый WSПрокси(Определение, "http://www.example.com/integration", "ServiceName", "ServiceSoapPort");

// Дублируем параметры аутентификации для самого прокси-объекта
Прокси.Пользователь = ИмяПользователя;
Прокси.Пароль = Пароль;

// Вызываем целевую функцию веб-сервиса
Результат = Прокси.ВыполнитьОбменДанными(ПараметрыЗапроса);

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

Метод 2: Настройка параметров подключения в файле публикации (.vrd)

Если мы хотим, чтобы веб-сервис всегда запускался под конкретной учетной записью, независимо от того, кто вызывает его извне, мы можем "прибить" пользователя в настройках публикации информационной базы на веб-сервере (IIS или Apache).

Разберем, как это сделать. При публикации базы создается файл с расширением .vrd. В этом файле можно отредактировать строку соединения с информационной базой в атрибуте ib. Посмотрим на пример структуры такого файла:


<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       base="/BaseName"
       ib="Srvr='ServerName';Ref='BaseName';usr='ServiceUser';pwd='ComplexPassword';">
    <ws>
        <point name="DocumentExchange" alias="doc.1cws" />
    </ws>
</point>

В данном случае, когда внешняя система обращается к публикации по адресу /BaseName/ws/doc.1cws, платформа автоматически авторизует сеанс под пользователем ServiceUser. Для вызывающей стороны авторизация выглядит как "автоматическая", так как HTTP-заголовок Authorization может не передаваться вовсе. Однако помните, что это решение небезопасно для открытых сетей, так как любой, кто знает URL, получит доступ к сервису под указанными правами.

Метод 3: Использование OpenID Connect для Single Sign-On (SSO)

Для создания полноценной сквозной авторизации в современных версиях платформы (начиная с 8.3.18) рекомендуется использовать стандарт OpenID Connect (OIDC). Это позволяет одной информационной базе доверять аутентификации, пройденной в другой базе.

Выясним, как работает этот механизм в контексте веб-сервисов:

Одна из баз 1С настраивается как OpenID-провайдер.
База-приемник (где опубликован веб-сервис) настраивается на использование этого провайдера.
При обращении к веб-сервису вместо пароля используется access token или специальный навигационный токен.

Рассмотрим преимущество этого метода: пользователю достаточно один раз войти в систему. При вызове веб-сервиса клиентская база запрашивает временный токен у сервера авторизации и передает его в заголовке запроса. На стороне сервера 1С проверяет валидность токена и понимает, какой именно пользователь совершает действие.

Метод 4: Сквозная Windows-аутентификация (Kerberos/NTLM)

Если ваша инфраструктура построена на базе домена Active Directory, а веб-сервисы опубликованы на Internet Information Services (IIS), можно реализовать прозрачную авторизацию через ОС. В этом случае данные о текущем доменном пользователе будут автоматически передаваться веб-серверу.

Для реализации этого метода проанализируем следующие шаги:

В настройках публикации (vrd-файл) должен быть разрешен тип аутентификации <winauth/>.
В базе-приемнике у пользователя 1С должен быть указан соответствующий пользователь домена.
В коде вызова при использовании объекта HTTPСоединение или WSПрокси необходимо указать использование учетных данных операционной системы.

Пример настройки HTTPСоединение для использования системных учетных данных:


// Использование пустого имени пользователя и пароля при установленном флаге 
// использования аутентификации ОС позволяет пробросить текущую сессию Windows
Соединение = Новый HTTPСоединение("server.domain.com", , , , , , Новый ЗащищенноеСоединениеOpenSSL());
// В некоторых случаях требуется явная настройка прокси-сервера или параметров заголовков

Метод 5: Использование Bearer-токенов в REST-интерфейсах

Если вы используете не SOAP (веб-сервисы), а REST (HTTP-сервисы), стандартным способом является использование заголовка Authorization: Bearer <token>. Это наиболее гибкий метод, так как токены могут генерироваться сторонними системами (например, Keycloak).

Разберем алгоритм взаимодействия:

Клиентская база запрашивает токен у сервиса авторизации, используя свои секретные ключи.
Полученный токен добавляется в каждый HTTP-запрос к базе-серверу.
База-сервер в коде HTTP-сервиса может проверить этот токен (например, через JWT-библиотеки или обращением к провайдеру) и определить личность отправителя.

Посмотрим на пример добавления токена в заголовки запроса:


Запрос = Новый HTTPЗапрос("/hs/v1/get_data");
Запрос.Заголовки.Вставить("Authorization", "Bearer " + ПолученныйРанееТокен);
Ответ = Соединение.ВызватьHTTPМетод("GET", Запрос);

Подведение итогов и выбор решения

Проанализировав все способы, можно сделать следующие выводы. Если вам нужно быстрое решение внутри закрытого контура, использование выделенного "технического" пользователя в WSПрокси или vrd-файле является самым простым в реализации. Однако, если требуется соблюдение строгих политик безопасности и персонализация действий каждого пользователя в логах (Журнале регистрации), необходимо смотреть в сторону OpenID Connect или доменной аутентификации.

Важный момент: при использовании любых методов автоматической авторизации обязательно используйте защищенное соединение HTTPS. Передача токенов или (тем более) логинов и паролей в открытом виде по протоколу HTTP крайне опасна и может привести к компрометации всей системы.