Главная > Документация пользователя > Примеры решений

Атрибутный доступ к данным¶

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

доступ только к области ответственности специалиста, например, данным по деятельности собственной и нижестоящих оргструктур или по региону и его субъектам и т.д.;
разделение доступа к данным по времени (периоду), к которому они относятся, например, доступ только к данным созданным соответствующим периоду работы сотрудника или только к историческим данным (данным за прошедшие периоды).

Для реализации атрибутного доступа через внутренний провайдер AW с типом user_permissions, в Системе встроена модель данных user_permissions, в которой технический администратор Системы может создать и поддерживать любую необходимую для стыковки с данными структуру атрибутов пользователя. Для реализации атрибутного доступа через внешний провайдер модель данных user_permissions не используется, все необходимые атрибуты пользователя Система получает от провайдера.

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

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

Атрибутный доступ только накладывает дополнительные ограничения. Независимо от его применения, у пользователя должны быть обеспечены права для работы с соответствующим разделом Системы и права на просмотр для соответствующего объекта системы (виджета или информационной панели).

Настройка атрибутного доступа включает этапы:

для внутреннего провайдера AW:
для внешнего провайдера:
для внешнего и внутреннего провайдера AW (разрешена и локальная аутентификация):

Настройка схемы доступов¶

Раздел Схемы доступов находится в блоке Администрирование, доступен пользователям, наделенным административными правами через встроенную системную группу Администратор.

Схема доступов представляет собой список атрибутов доступа. Атрибуты доступа передаются внешними провайдерами в Систему при авторизации пользователя и используются для атрибутного доступа к данным модели. Атрибуты доступа также могут быть указаны в модели user_permissions при использовании внутреннего провайдера AW.

В Системе есть встроенные атрибуты доступа:

login - логин;
email - e-mail;
state - статус;
user_roles - роль.

По ним сопоставляется учетная запись пользователя и обновляются его данные. Встроенные атрибуты не подлежат удалению и у таких атрибутов нельзя отредактировать наименование.

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

структурную принадлежность (департамент, подразделение, ведомство и т.д.);
территориальную привязку (регион, город и т.д.);
принадлежность к определенным ролям (руководитель, бухгалтер, ответственный за, и т.д.);
дополнительные атрибуты, делающие информацию более понятной и наглядной (ФИО пользователя, название организационной единицы, название территории).

Настройка модели user_permissions¶

В системе изначально встроена модель данных user_permissions, доступная только пользователю с учетной записью tech_admin (технический администратор), а также тем пользователям, кому администратор Системы выдал разрешения на ее изменение.

Для того чтобы войти в режим редактирования модели user_permissions, перейдите в раздел Модели и дважды нажмите левой кнопки мыши на модель. В открывшейся форме просмотра модели нажмите кнопку Редактировать.

Эта модель по умолчанию пустая - не содержит источников данных и связей, администратор должен настроить ее структуру данных так, чтобы она содержала:

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

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

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

После завершения настройки модели user_permissions, ее данные должны быть загружены. Как минимум, должна быть выполнена разовая загрузка данных вручную. При необходимости регулярной поддержки актуальности данных должно быть настроено расписание обновления модели в Планировщике.

Настройка провайдера¶

Раздел Провайдеры находится в блоке Администрирование, доступен пользователям, наделенным административными правами через встроенную системную группу Администратор. Предназначен для настройки взаимодействия Системы с провайдерами пользователей.

В системе имеется внутренний провайдер AW с типом user_permissions, который используется по умолчанию. Система не позволяет добавить дополнительный провайдер с типом AW (user_permissions), так как внутренний провайдер должен быть уникальным. Поэтому настройка провайдера AW доступна только с помощью редактирования встроенной записи внутреннего провайдера.

При настройке заполните данные на вкладке Маппинг схемы. Таблица соответствия в первом столбце будет содержать все атрибуты схемы доступов, а во втором столбце укажите соответствующие атрибуты, используемые в модели user_permissions. Нажмите на кнопку Сохранить.

Так же имеется возможность настроить авторизацию через внешний сервис аутентификации. Чтобы настроить взаимодействие, необходимо произвести настройки для обоих участников взаимодействия: провайдера (поставщика учетных записей) и Системы (поставщика сервиса).

Настройка правил доступа к пользовательской модели¶

Раздел Правила доступа находится в блоке Модели, в редактировании конкретной модели по кнопке Настройки.

Настройка правил доступа может выполняться пользователем, создавшим модель или имеющим права на администрирование данной модели. Объектом доступа являются строки данных. Настройка правил определяет условия, которым должны отвечать доступные пользователю строки (например, территориальная привязка пользователей соответствует территориальной привязке данных модели).

Интерфейс настройки правил доступа содержит список созданных правил, а также предоставляет возможности:

создания нового правила;
изменения существующего правила;
удаления одного или нескольких существующих правил.

Создание правила доступа к строкам¶

Чтобы добавить новое правило, нажмите на кнопку Добавить. Будет выведен интерфейс добавления правила доступа.

Группа условий может включать в себя два вида ограничений:

ограничения по пользователям (необязательно) - дает ограничения на пользователей, т.е. определяет группу пользователей (кого ограничиваем), к которым будут применены условия по полю модели (как ограничиваем);
ограничения по данным (обязательно) - дает ограничения на данные, т.е. определяет поля модели ограничивающие видимость данных.

Условия в блоке Ограничения по пользователям строятся из следующих компонентов:

выбор атрибута пользователя - выпадающий список атрибутов учетной записи пользователя;

Атрибут Роль (user_roles) применяется в настройке атрибутного доступа к пользовательской модели для ограничения пользователей внешнего провайдера с помощью задания условий по значениям, указанным в маппинге атрибутов пользователя для атрибута доступа user_roles внешнего провайдера.

выбор оператора сравнения - выпадающий список операторов сравнения. Набор операторов зависит от типа атрибута;
значение для сравнения - поле ввода значения атрибута для сравнения;

Условия в блоке Ограничения по данным (по полю модели) строятся из следующих компонентов:

выбор поля модели - выпадающий список полей данной модели;
выбор типа строки - доступно только при выборе поля с типом Строка:
- Строка - любое строковое значение без преобразования;
- Массив json - для преобразования строкового значения в тип Массив. В качестве значения ожидается одномерный json массив строк, например, ["1", "2", "3"]. Данный тип преобразования наиболее производительный;
- Массив с разделителем ; - для преобразования строкового значения в тип Массив. В качестве значения ожидается массив значений указанных через разделитель ;, например, 1;2;3;
выбор оператора сравнения - выпадающий список операторов сравнения. Набор операторов зависит от типа поля модели;
выбор вида сравнения:
- Атрибут - для сравнения значений поля модели со значением соответствующего атрибута пользователя;
- Значение - для сравнения с введенным значением;
значение для сравнения - поле ввода значения или выбора атрибута для сравнения;

В составе одного правила может быть введено одно или несколько условий в одной группе либо несколько условий в разных группах, при этом:

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

Пример правила

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

Применение изменений правил по отношению к пользователям происходит сразу после их сохранения. Вход и выход пользователей в Систему (перелогинивание) для этого не требуются.

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

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

Исходная задача: необходимо ограничить доступ к данным по территориальной принадлежности. Есть источник и Модель А, содержащая данные из источника, извлекаемые SQL-запросом. В самих данных есть столбец, содержащий названия региона России, к которому относятся значения в строке .

Необходимо обеспечить доступ:

пользователям центрального аппарата - к данным по всем регионам;
пользователям регионов - к данным только своего собственного региона.

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

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

Источником данных о пользователях и их территориальной привязке является Excel-файл. Данные сохранены в источнике в виде структуры таблиц.

Таблица (Лист)	Поле	Тип данных	Пример наполнения	Описание поля
Территориальная структура	ID_reg	целое число	2	Идентификатор единицы территориальной структуры
Территориальная структура	Название	строка	Нижегородская область	Название единицы территориальной структуры
Территориальная структура	Parent_ID_reg	целое число	1	Идентификатор родительской единицы территориальной структуры
Территориальная структура	Reg_path_num	строка	1;2;	Путь - последовательность идентификаторов единиц территориальной структуры, составляющих ветку от корневого до данного элемента
Пользователи	login	строка	TEST_Maslow	Логин (обеспечивает связку с системным справочником пользователей)
Пользователи	ФИО	строка	Маслов	ФИО (или иная дополнительная информация о пользователе)
Пользователи	ID_reg	целое число	4

Таблица Территориальная структура:

ID_reg	Название территории	Parent_ID_reg	Reg_path_num
1	Российская Федерация		1;
2	Нижегородская область	1	1;2;
3	Республика Татарстан	1	1;3;
4	Удмуртская Республика	1	1;4;
5	Ярославская область	1	1;5;

Иерархия регионов сохранена в поле REG_PATH_NUM, содержащем последовательность ID_REG для всей ветки территориальной структуры от корневого ID_REG = 1 (Российская Федерация) до ID_REG данного региона. В качестве разделителей в данной строке используются символы ; (точка с запятой). Данный разделитель также обязательно должен присутствовать в конце значения в REG_PATH_NUM (даже если это значение содержит только 1 элемент, например, 1;.

Таблица Пользователи:

login	ФИО	ID_reg
TEST_Ivanov	Иванов	1
TEST_Petrov	Петров	2
TEST_Stepanova	Степанова	3
TEST_Maslow	Маслов	4
TEST_Znamenskii	Знаменский	5

На основании этих данных администратором Системы создается структура модели user_permissions. В основе - данные таблицы Пользователи. Они дополнены данными таблицы Территориальная структура на основе связи по равенству поля ID_REG. В результате для каждого пользователя добавлено название его региона и значение REG_PATH_NUM.

Дополнение Модели А информацией об иерархии регионов. Таблица Территориальная структура используется также для дополнения данных Модели А информацией об иерархии регионов. Эту операцию может выполнить пользователь, создавший данную модель или имеющий права на ее редактирование. В примере добавлен тип связи таблиц INNER JOIN. Это ограничивает состав строк в модели данных только теми регионами, к которым привязаны пользователи.

Настройка схемы доступа. Администратор Системы или пользователь, наделенный административными правами через встроенную системную группу Администратор, производит настройку схемы доступов. В примере добавлен атрибут доступа REG_PATH_NUM.

Настройка маппинга атрибутов доступа схемы и провайдера. Администратор Системы или пользователь, наделенный административными правами через встроенную системную группу Администратор, производит настройку внутреннего провайдера. В примере в карточке редактирования внутреннего провайдера на вкладке Маппинг схемы добавлено соответствие атрибуту доступа по иерархии регионов REG_PATH_NUM к аналогичному полю модели user_permissions.

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

Результат:

Пользователь TEST_Ivanov отнесен к региону 1 (Российская Федерация). Значение его атрибута REG_PATH_NUM = 1;. Данный текст присутствует в значениях свойства REG_PATH_NUM всех регионов (всех строк данных Модели А). Поэтому пользователь получает доступ ко всем данным в виджетах.
Пользователь TEST_Petrov отнесен к региону 2 (Нижегородская область). Значение его атрибута REG_PATH_NUM = 1;2;. Данный текст присутствует в значениях свойства REG_PATH_NUM только для записи региона 2 (Нижегородская область). Поэтому пользователь получает только доступ к данным региона.

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

Заданные ограничения действуют для виджетов, построенных на данных Модели А для виджетов и информационных панелей в интерфейсе их просмотра, редактирования, просмотра по прямой ссылке.