Как настроить синхронизацию пользователей информационной базы и их паролей через РИБ в 1С?

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

При настройке распределенной информационной базы (РИБ) разработчики и администраторы часто сталкиваются с ситуацией, когда данные справочника Пользователи успешно переносятся между узлами, однако сами учетные записи платформы (пользователи в Конфигураторе), их пароли и назначенные роли в подчиненных базах не появляются. Выясним причину такого поведения платформы и подробно разберем практические способы решения этой задачи.

Почему пользователи информационной базы не передаются через стандартный РИБ

Проанализируем архитектуру хранения данных в платформе 1С:Предприятие. В системе разделены две сущности:

  1. Прикладной справочник Пользователи (или аналогичный объект метаданных), данные которого хранятся в стандартных таблицах базы данных и регистрируются на узлах планов обмена.
  2. Системный объект ПользовательИнформационнойБазы, который хранится в системной области платформы. Этот объект не является элементом прикладных метаданных, для него нельзя напрямую включить авторегистрацию изменений в плане обмена.

Поскольку механизм РИБ отслеживает изменения исключительно тех объектов конфигурации, которые включены в состав плана обмена, системные учетные записи не попадают в стандартный пакет выгрузки обмена.

Способ 1. Синхронизация учетных записей через служебный регистр сведений

Рассмотрим техническую реализацию передачи пользователей и паролей через штатный канал РИБ с использованием промежуточного регистра сведений. Это решение позволяет передавать данные без необходимости ввода паролей вручную в каждом узле.

Для сохранения паролей не требуется передавать их в открытом виде. Платформа 1С предоставляет свойство СохраняемоеЗначениеПароля объекта ПользовательИнформационнойБазы. Данное свойство доступно как для чтения, так и для записи и содержит хешированное представление пароля. При записи этого значения в приемнике признак ПарольУстановлен включается автоматически.

Разберем по шагам создание механизма:

  1. Создадим непериодический регистр сведений СинхронизацияПользователейИБ и включим его в состав плана обмена РИБ. В качестве измерений укажем ИдентификаторПользователяИБ (тип УникальныйИдентификатор или строка), а в ресурсах сохраним Имя, ПолноеИмя, СохраняемоеЗначениеПароля, АутентификацияСтандартная, АутентификацияОС, ПользовательОС.
  2. При создании или изменении пользователя в центральном узле заполняем запись в регистре сведений.
  3. В обработчике записи регистра сведений на стороне подчиненного узла (или в обработчике ПриПолученииДанныхОтГлавного) выполняем обновление системной учетной записи.

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


// Получаем идентификатор учетной записи
Идентификатор = ЗаписьРегистра.ИдентификаторПользователяИБ;
ПользовательИБ = ПользователиИнформационнойБазы.НайтиПоУникальномуИдентификатору(Новый УникальныйИдентификатор(Идентификатор));

Если ПользовательИБ = Неопределено Тогда
    ПользовательИБ = ПользователиИнформационнойБазы.СоздатьПользователя();
    ПользовательИБ.УникальныйИдентификатор = Новый УникальныйИдентификатор(Идентификатор);
КонецЕсли;

ПользовательИБ.Имя = ЗаписьРегистра.Имя;
ПользовательИБ.ПолноеИмя = ЗаписьРегистра.ПолноеИмя;
ПользовательИБ.АутентификацияСтандартная = ЗаписьРегистра.АутентификацияСтандартная;
ПользовательИБ.СохраняемоеЗначениеПароля = ЗаписьРегистра.СохраняемоеЗначениеПароля;
ПользовательИБ.АутентификацияОС = ЗаписьРегистра.АутентификацияОС;
ПользовательИБ.ПользовательОС = ЗаписьРегистра.ПользовательОС;

// Записываем системного пользователя
ПользовательИБ.Записать();

Важный момент: фоновое или регламентное задание, под которым выполняется чтение сообщения обмена РИБ в подчиненном узле, должно выполняться от имени пользователя с административными правами (роль Администрирование), иначе платформа вызовет исключение при вызове метода Записать().

Специфика типовых конфигураций на базе БСП

Если разработка ведется в типовой конфигурации на базе Библиотеки Стандартных Подсистем (БСП), обратим внимание на следующие правила:

  1. Связь сущностей: Элемент справочника Пользователи связывается с учетной записью платформы через реквизит ИдентификаторПользователяИБ. При создании пользователя платформы в подчиненной базе обязательно сохраняйте исходный УникальныйИдентификатор, чтобы ссылка между прикладным объектом и пользователем ИБ не нарушилась.
  2. Назначение ролей: В конфигурациях на БСП роли не следует назначать напрямую коллекции ПользовательИБ.Роли. Система управления доступом БСП рассчитывает состав ролей динамически на основании справочников ГруппыДоступа и ПрофилиГруппДоступа. Если назначить роли напрямую в обход БСП, при очередном обновлении прав библиотека автоматически перетрет эти роли. Достаточно передавать по РИБ элементы групп доступа, а сопоставление прав БСП выполнит самостоятельно.

Способ 2. Централизация авторизации без передачи паролей

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

  1. Доменная авторизация: Настроим свойство АутентификацияОС и заполним поле ПользовательОС. В таком сценарии управление учетными данными делегируется Active Directory, а в подчиненные узлы достаточно передать только доменные имена сотрудников.
  2. Аутентификация по протоколу OpenID: Центральная информационная база настраивается в качестве OpenID-провайдера. В периферийных узлах у пользователей включается свойство АутентификацияOpenID. При входе в подчиненную базу запрос на аутентификацию перенаправляется в центральный узел, что полностью снимает задачу миграции паролей между базами.
← На главную