Дизайн RBAC

Обсуждаем разработку фреймворка: дизайн компонентов, API, пакеты
Аватара пользователя
samdark
Администратор
Сообщения: 9201
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Дизайн RBAC

Сообщение samdark » 2019.10.06, 01:32

Поработал немного над RBAC. Проходит тесты: https://github.com/yiisoft/rbac

Есть несколько вопросов:

1. Полезна ли возможность назначать permission на пользователя напрямую, а не через роль?
2. Достаточно ли полон `ManagerInterface` для создания админки RBAC?

Аватара пользователя
SiZE
Сообщения: 2698
Зарегистрирован: 2011.09.21, 12:39
Откуда: Perm
Контактная информация:

Re: Дизайн RBAC

Сообщение SiZE » 2019.10.06, 08:39

1. RBAC гарантирует доступ на основе ролей. Добавление прямой связи усложняет функционал, да и сам он является специфическим. Большинству сайтов достаточно доступа на основе только ролей (админ, менеджер, пользователь).
в поиске работы

Wizard
Сообщения: 173
Зарегистрирован: 2018.02.05, 13:41
Контактная информация:

Re: Дизайн RBAC

Сообщение Wizard » 2019.10.06, 10:36

1. Очень полезна

yiiliveext
Сообщения: 529
Зарегистрирован: 2019.08.13, 01:49

Re: Дизайн RBAC

Сообщение yiiliveext » 2019.10.06, 11:53

1. Это уже не совсем RBAC будет. Плюс все это реализуется и через роли. Так что это лишнее.
2. С виду-то вроде все, но без практики вряд ли получится точно определить. А hasPermission() в интерфейсе не нужен?
3. Я смотрю, вы так и оставили роль в виде разрешения. То есть hasPermission($userId, 'Admin') === true если пользователю назначена роль Admin?

В текущем варианте у вас реализована возможность добавлять разрешение пользователю. Так что код в интерфейсе

Код: Выделить всё

/**
     * Assigns a role to a user.
     *
     * @param Item $role
     * @param string $userId the user ID
     *
     * @return Assignment the role assignment information.
     * @throws \Exception if the role has already been assigned to the user
     *
     */
    public function assign(Item $role, string $userId): Assignment;
все же лучше будет заменить на

Код: Выделить всё

/**
     * Assigns a role or a permission to a user.
     *
     * @param Item $item
     * @param string $userId the user ID
     *
     * @return Assignment the role assignment information.
     * @throws \Exception if the role has already been assigned to the user
     *
     */
    public function assign(Item $item, string $userId): Assignment;

Аватара пользователя
samdark
Администратор
Сообщения: 9201
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Дизайн RBAC

Сообщение samdark » 2019.10.06, 17:13

По поводу пункта 1. Так работает в Yii 2 и на данный момент. Я подумываю о том, чтобы такую возможность отобрать.

Аватара пользователя
samdark
Администратор
Сообщения: 9201
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Дизайн RBAC

Сообщение samdark » 2019.10.06, 17:15

yiiliveext,

hasPermission() в интерфейсе есть. AccessCheckerInterface, от него наследуется интерфейс менеджера.

yiiliveext
Сообщения: 529
Зарегистрирован: 2019.08.13, 01:49

Re: Дизайн RBAC

Сообщение yiiliveext » 2019.10.06, 20:03

samdark писал(а):
2019.10.06, 17:13
По поводу пункта 1. Так работает в Yii 2 и на данный момент. Я подумываю о том, чтобы такую возможность отобрать.
Как-то даже в голову не приходило использовать такую возможность.
samdark писал(а):
2019.10.06, 17:15
hasPermission() в интерфейсе есть. AccessCheckerInterface, от него наследуется интерфейс менеджера.
Да, провтыкал.

Хотелось все же услышать мотивацию по использованию роли в качестве глобального разрешения. Ведь роль в RBAC по своей сути разрешением не является. Кроме того, это способствует написанию плохого кода.

Аватара пользователя
samdark
Администратор
Сообщения: 9201
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Дизайн RBAC

Сообщение samdark » 2019.10.07, 00:57

Wizard, для чего?

Аватара пользователя
samdark
Администратор
Сообщения: 9201
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Дизайн RBAC

Сообщение samdark » 2019.10.07, 00:58

Хотелось все же услышать мотивацию по использованию роли в качестве глобального разрешения. Ведь роль в RBAC по своей сути разрешением не является. Кроме того, это способствует написанию плохого кода.
Так работает в Yii 2. Это пока единственная мотивация.

raketa
Сообщения: 131
Зарегистрирован: 2011.07.28, 17:29

Re: Дизайн RBAC

Сообщение raketa » 2019.10.07, 08:17

1. Для чего убирать? Какая цель преследуется?
Пример есть роль, которая содержит сотни разрешений, нужна вторая роль, которая содержит те-же разрешения за исключением 1 или 2х. фактически бизнес задача это временно или постоянно запретить/разрешить несколько разрешений для конкретного юзера, сделать это можно назначив разрешение напрямую юзеру.
Да можно создать еще одну роль, можно попытаться разбить существующую роль на более мелкие это фактически придется разбить роль до уровня разрешений и тд и тп, но это не удобно в особенности для менеджеров. Лучше когда менеджер видит список ролей, который понятный и как можно более короткий. Либо объединять роли в группы, но тогда можно как в Yii1 к ролям и разрешениям еще и задачи добавить ..

yiiliveext
Сообщения: 529
Зарегистрирован: 2019.08.13, 01:49

Re: Дизайн RBAC

Сообщение yiiliveext » 2019.10.07, 10:12

raketa писал(а):
2019.10.07, 08:17
Пример есть роль, которая содержит сотни разрешений, нужна вторая роль, которая содержит те-же разрешения за исключением 1 или 2х. фактически бизнес задача это временно или постоянно запретить/разрешить несколько разрешений для конкретного юзера, сделать это можно назначив разрешение напрямую юзеру.
Да можно создать еще одну роль, можно попытаться разбить существующую роль на более мелкие это фактически придется разбить роль до уровня разрешений и тд и тп, но это не удобно в особенности для менеджеров. Лучше когда менеджер видит список ролей, который понятный и как можно более короткий. Либо объединять роли в группы, но тогда можно как в Yii1 к ролям и разрешениям еще и задачи добавить ..
Абсолютно надуманный пример. Вот, например, у вас есть роль Кладовщик, в которой есть разрешения для работы со складскими документами, и вам понадобилась роль Кладовщик-стажер, который может все, что Кладовщик, кроме проведения документа Перемещение. Вы сейчас предлагаете стажеру назначить роль Кладовщик и отозвать у этого пользователя разрешение на проведение документа Перемещение? Так это невозможно. Я после вашего поста настолько офигел из-за возможность творить такую дичь, что даже полез смотреть rbac в yii2. Оказалось все нормально, отозвать можно только то разрешение, которое было непосредственно назначено пользователю.
А решается этот вопрос в рамках RBAC двумя способами.
Первый - вам нужно добавить стажера временно, тогда вы просто клонируете в админке роль (нужно просто добавить функционал клонирования, если его нет) и забираете у нее разрешение на проведение документа Перемещение.
Второй - если вам нужно добавить на постоянно, добавляете роль Кладовщик-стажер роли Кладовщик и удаляете у нее все разрешения кроме разрешения на Перемещение.
Все это занимает буквально одну минуту.
raketa писал(а):
2019.10.07, 08:17
Для чего убирать? Какая цель преследуется?
Роли и разрешения - это разные уровни абстракции. Бизнес работает с ролями, которые являются абстракциями в терминах бизнес-процессов. Кладовщик, Продавец, Бухгалтер - это все абстракции в терминах бизнес-процессов. Администратор системы работает с абстракцией Разрешение - это абстракция в терминах реализации функционала необходимого для формирование ролей.

Аватара пользователя
yiijeka
Сообщения: 3070
Зарегистрирован: 2012.01.28, 09:14
Откуда: Беларусь
Контактная информация:

Re: Дизайн RBAC

Сообщение yiijeka » 2019.10.07, 10:28

Полезна ли возможность назначать permission на пользователя напрямую, а не через роль?
Иногда полезна, если проект мелкий и роли вообще не используются. Что такое роли у некоторых "менеджеров" вызывают непонимание, им проще сделать интерфейс с десятком разрешений в виде списка чекбоксов, где "менеджер" будет разрешать, что можно делать пользователю. Убрав возможность назначать permission на пользователя, код реализации вышеописанной ситуации усложнится напорядок.

Да, это не соответствует спецификации RBAC, но не припомню, чтобы это вызывало критичных вещей при работе с такой схемой.

Единственное сейчас, как по мне, вредна возможность проверять может ли пользователь "делать то или иное действие" в зависимости от его роли. Сейчас данная возможность способствует тому, что по проектам размазаны проверки разрешений и проверки ролей. Рано или поздно наступает момент, когда нужно удалить роль, создать вместо неё две роли и переназначить разрешения. Если по проекту используется $user->can('roleName'), то код проекта ломается - в некоторой степени в этом виноват фреймворк, сейчас он позволяет проверять роль, а не разрешение.

yiiliveext
Сообщения: 529
Зарегистрирован: 2019.08.13, 01:49

Re: Дизайн RBAC

Сообщение yiiliveext » 2019.10.07, 10:37

samdark писал(а):
2019.10.07, 00:58
Так работает в Yii 2. Это пока единственная мотивация.
И вот именно это мне и не нравится в yii2. Многие разработчики используют роли для авторизации, а это в корне неверно. Роль по сути своей, это группа и предназначена для группировки разрешений, организации наследования и организации иерархии, что, в свою очередь, сделано для упрощения назначения определенной группы разрешений пользователю. Единственные места в приложении, где должны использоваться роли - это RBAC-менеджер и место, где пользователям назначаются роли. Все остальные части приложения должны работать с разрешениями.

yiiliveext
Сообщения: 529
Зарегистрирован: 2019.08.13, 01:49

Re: Дизайн RBAC

Сообщение yiiliveext » 2019.10.07, 10:45

yiijeka писал(а):
2019.10.07, 10:28
Полезна ли возможность назначать permission на пользователя напрямую, а не через роль?
Иногда полезна, если проект мелкий и роли вообще не используются. Что такое роли у некоторых "менеджеров" вызывают непонимание, им проще сделать интерфейс с десятком разрешений в виде списка чекбоксов, где "менеджер" будет разрешать, что можно делать пользователю. Убрав возможность назначать permission на пользователя, код реализации вышеописанной ситуации усложнится напорядок.
Назначение разрешений напрямую пользователям - это ACL. Возможно есть смысл сделать его полноценную реализацию для приведенных вами целей.

Аватара пользователя
yiijeka
Сообщения: 3070
Зарегистрирован: 2012.01.28, 09:14
Откуда: Беларусь
Контактная информация:

Re: Дизайн RBAC

Сообщение yiijeka » 2019.10.07, 11:08

Есть проект, в котором подразумевается управление RBAC под бизнес требования посредством программиста, так как другие в этом ничего не понимают. Но есть парочку разрешений, которые понятны пользователям и они хотели бы ими управлять.

Т.е. мы делаем некий модуль, в нём делаем ACL, а потом в проекте используем RBAC и в некоторых местах ACL ... Сами что думаете?

Исходя из практической точки зрения, профита от удаления возможности "назначать permission на пользователя напрямую" нет.

Аватара пользователя
yiijeka
Сообщения: 3070
Зарегистрирован: 2012.01.28, 09:14
Откуда: Беларусь
Контактная информация:

Re: Дизайн RBAC

Сообщение yiijeka » 2019.10.07, 11:11

yiiliveext писал(а):
2019.10.07, 10:37
samdark писал(а):
2019.10.07, 00:58
Так работает в Yii 2. Это пока единственная мотивация.
И вот именно это мне и не нравится в yii2. Многие разработчики используют роли для авторизации, а это в корне неверно. Роль по сути своей, это группа и предназначена для группировки разрешений, организации наследования и организации иерархии, что, в свою очередь, сделано для упрощения назначения определенной группы разрешений пользователю. Единственные места в приложении, где должны использоваться роли - это RBAC-менеджер и место, где пользователям назначаются роли. Все остальные части приложения должны работать с разрешениями.
Полностью согласен.

yiiliveext
Сообщения: 529
Зарегистрирован: 2019.08.13, 01:49

Re: Дизайн RBAC

Сообщение yiiliveext » 2019.10.07, 11:14

yiijeka писал(а):
2019.10.07, 11:08
Есть проект, в котором подразумевается управление RBAC под бизнес требования посредством программиста, так как другие в этом ничего не понимают. Но есть парочку разрешений, которые понятны пользователям и они хотели бы ими управлять.
Т.е. мы делаем некий модуль, в нём делаем ACL, а потом в проекте используем RBAC и в некоторых местах ACL ... Сами что думаете?
Это уже другой пример, реализация ACL (с группами) полезна для организации альтернативной системы контроля доступа, более понятной обычным пользователям, как в первом примере.
В вашем примере с парочкой разрешений реализуется в рамках RBAC назначением скрытой роли.

Аватара пользователя
yiijeka
Сообщения: 3070
Зарегистрирован: 2012.01.28, 09:14
Откуда: Беларусь
Контактная информация:

Re: Дизайн RBAC

Сообщение yiijeka » 2019.10.07, 11:22

Получится для каждого пользователя своя скрытая роль. Реализация чуть сложнее, чем просто назначить разрешение на пользователя. На форуме добавится парочку новых тем "как назначить только одно разрешение на пользователя admin" :) Что же я не против - зато по спецификации Пользователь - Роль[] - Разрешение[].

yiiliveext
Сообщения: 529
Зарегистрирован: 2019.08.13, 01:49

Re: Дизайн RBAC

Сообщение yiiliveext » 2019.10.07, 11:52

yiijeka писал(а):
2019.10.07, 11:22
Получится для каждого пользователя своя скрытая роль. Реализация чуть сложнее, чем просто назначить разрешение на пользователя.
Та ладно:)
Вместо

Код: Выделить всё

$auth->assign($permission, $userId);
будет

Код: Выделить всё

$auth->addChild($auth->getRole('user' . $userId), $permission);

raketa
Сообщения: 131
Зарегистрирован: 2011.07.28, 17:29

Re: Дизайн RBAC

Сообщение raketa » 2019.10.07, 13:42

yiiliveext писал(а):
2019.10.07, 10:12
Абсолютно надуманный пример. Вот, например, у вас есть роль Кладовщик, в которой есть разрешения для работы со складскими документами, и вам понадобилась роль Кладовщик-стажер, который может все, что Кладовщик, кроме проведения документа Перемещение. Вы сейчас предлагаете стажеру назначить роль Кладовщик и отозвать у этого пользователя разрешение на проведение документа Перемещение? Так это невозможно. Я после вашего поста настолько офигел из-за возможность творить такую дичь, что даже полез смотреть rbac в yii2. Оказалось все нормально, отозвать можно только то разрешение, которое было непосредственно назначено пользователю.
А решается этот вопрос в рамках RBAC двумя способами.
Первый - вам нужно добавить стажера временно, тогда вы просто клонируете в админке роль (нужно просто добавить функционал клонирования, если его нет) и забираете у нее разрешение на проведение документа Перемещение.
Второй - если вам нужно добавить на постоянно, добавляете роль Кладовщик-стажер роли Кладовщик и удаляете у нее все разрешения кроме разрешения на Перемещение.
Все это занимает буквально одну минуту.
Зачем офигевать и лезть смотреть в rbac в yii2, конечно в стандартном rbac этого нет, но если бы был запрет давать разрешение напрямую пользователю, сделать свою релизацию было сложнее.
Понятно что в идеале создавать "КладовщикСтажер", или "КладовщикСтажерСтажера", "КладовщикПоВсемКромеОООРомашка" и тд и тп, но есть ситуации когда проще не плодить такие роли, это не в теория это практика. Будет столько ролей что будет сложно сделать правильный выбор между "КладовщикСтажер" и например "КладовщикСтаршийСтажер"
yiiliveext писал(а):
2019.10.07, 10:12
Роли и разрешения - это разные уровни абстракции. Бизнес работает с ролями, которые являются абстракциями в терминах бизнес-процессов. Кладовщик, Продавец, Бухгалтер - это все абстракции в терминах бизнес-процессов. Администратор системы работает с абстракцией Разрешение - это абстракция в терминах реализации функционала необходимого для формирование ролей.
Не спорю в теории это так, да давать разрешения только через роли. Но это вы так решили что бизнес работает с ролями, бизнес может работать и с разрешениями, кроме сложности контроля минусов в этом нет.
yiiliveext писал(а):
2019.10.07, 11:14
В вашем примере с парочкой разрешений реализуется в рамках RBAC назначением скрытой роли.
Вот об этом и речь, сделать чтобы потом это обойти скрытыми ролями.
Вопрос был поставлен вот так "Полезна ли возможность назначать permission на пользователя напрямую, а не через роль?"
Так для чего это полезно только для абстракций?
Если ставить вопрос "Правильно ли в теории давать возможность назначать permission на пользователя напрямую, а не через роль?" конечно же не правильно и спору нет.
Другое дело что $user->can('роль') это зло, потому что роль сама по себе это не разрешение на действие.

Ответить