Проблема двух row-level ролей с политиками для одной и той же сущности

Вопросы и проблемы
#1

Есть пользователь, к нему прикреплено две row-level роли, в которых есть ограничения на, скажем, сущность aaa. Первая роль ограничивает просмотр так что доступны только свои записи, т.е. aaa.createdBy={currentUser.id}, вторая роль более “мягкая” и дает доступ ко всем экземплярам aaa, которые относятся к подразделению моего пользователя, например, aaa.division={currentUser.division}.

Вопрос: что увидит в гриде по сущности aaa мой пользователь? По нашему опыту ситуация нестабильная и в каких то ситуациях пользователь на увидит датасет, который соответствует первой row-level роли, а в каких то ситуациях второй row-level роли.

У кого какой опыт? Просьба поделиться. Видится что по хорошему нельзя в разных row-level ролях определять ограничения для одной и той же сущности, потому как в большинстве случаев они будут противоречивы. Если это так тогда наверное система должна как минимум предупреждать о нежелательных настройках, которые пользователь собирается произвести в row-level ролях.

#2

Вообще должны проверяться все row-level роли, и пользователь должен видеть записи, которые удовлетворяют обоим условиям одновременно.

Нужно больше информации о проблеме: версия Jmix, как создана роль (аннотированный интерейс или в рантайме в базе), как задано условие (JPQL или предикат).

В идеале, чтобы ускорить решение проблемы, хотелось бы демо-проект, на котором видна ошибка.

#4

Ну про аннотированные row-level роли я не слышал. У нас, обычные, не аннотированные. Пример сделаем. Версия JMIX 1.4.4.

#5

Эксперимент проведен на вашем демо-проекте

создано:

  • пользователь user1
  • роль уровня строк admin с одним условием на сущность ClassA
    image
  • роль уровня строк user_RLR с одним условием на сущность ClassA
    image
  • обе роли привязаны к user1
    image
  • в базе есть два объекта ClassA
    image
  • пользователь видит только одну запись, хотя по роли админа (более мягкой) он должен видеть обе
    image
#6

Т.е. в текущем варианте права на сущность определяются по принципу конъюнкции всех условий.
Хотя в логике ролевой модели доступа как раз-таки должен работать принцип дизъюнкции.

Потому как пользователю даются минимальные права доступа, а потом добавлением различных ролей исполнителя доступ должен расширяться.
Изначально имею доступ только к своим объектам. Добавили роль руководителя - вижу свои объекты и объекты подчиненных. И т.д.
А сейчас добавление роли руководителя вынуждает удалять базовую минимальную роль.

#7

Добрый день!

Ресурсные (resource) роли и роли уровня строк (row-level roles) работают по разному. Из документации:

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

Т.е. ресурсная роль - это разрешение, а row-level роль - это ограничение. И каждая новая row-level роль, назначенная на пользователя, ещё больше ограничивает набор строк БД, которые данный пользователь видит.

#8

Так в этом-то и дело.

Роли уровня строк - ограничительные. Вопросов нет.
Вопрос как они ограничивают доступ в случае совместного ограничения.

Если ограничение на сущность распространяется на несколько ролей, то ОГРАНИЧЕНИЕ должно возникать если все эти роли запрещают доступ к экземпляру сущности.
А сейчас доступ РАЗРЕШАЕТСЯ если все роли разрешают доступ!!!

Обычная ситуация: сотрудник организации работает в двух отделах. В каждом отделе разрешено работать только с документами своего отдела и не разрешено с документами второго. Есть две роли уровня строк, которые разрешают видеть только документы своего отдела. Если мы назначим эти две роли нашему сотруднику - он не увидит ничего!!! Для такого сотрудника нужно делать свою индивидуальную роль с видимостью двух отделов.
А если таких отделов у меня пятнадцать и сотрудников вовлеченных в работу нескольких отделов пару сотен? Сколько ролей я должен буду сделать? Для каждого сотрудника свою? Это в корне неверная логика.

Еще раз

  • Определение ограничения ролью уровня строк должно производиться по правилу:
    • если запрещено всеми - то нельзя
    • если хотя бы один не запрещает - то видим.
#9

Ограничения, если мы говорим, например, про кусочки JPQL запросов суммируются по AND. Т.е. в вашей конкретной задаче если у сотрудника две row-level роли для документоа отдела А и Б, то для такого сотрудника сформируется запрос

select документ where (документ в отделе А) **И** (документ в отделе Б)

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

Логика тут не неверная, она подчиняется чёткому правилу сбора всех ограничений по условию И. Вопрос в том, что для вашей задачи в вашем конкретном подходе к использованию ролей она не подходит.

Сработает, например, вариант, если вы сделаете не множество ролей для каждого отдела, а сделаете одну роу-левел роль “Пользователь должен видеть документы СВОИХ отделов”, дальше вы где-то в модели данных для каждого пользователя задаёте список его отделов, а в запросе к роу-левел роли у вас будет выражение, которое сделает что-то типа

select документ where документ.отдел в списке отделов текущего пользователя
#10

Я так и делал