Дизайн RBAC

[samdark]

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

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

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

[SiZE]

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

[BalykhinAS]

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

[yiiliveext]

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]

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

[samdark]

yiiliveext,

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

[yiiliveext]

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

Как-то даже в голову не приходило использовать такую возможность.

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

Да, провтыкал.

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

[samdark]

Wizard, для чего?

[samdark]

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

Так работает в Yii 2. Это пока единственная мотивация.

[raketa]

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

[yiiliveext]

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

Абсолютно надуманный пример. Вот, например, у вас есть роль Кладовщик, в которой есть разрешения для работы со складскими документами, и вам понадобилась роль Кладовщик-стажер, который может все, что Кладовщик, кроме проведения документа Перемещение. Вы сейчас предлагаете стажеру назначить роль Кладовщик и отозвать у этого пользователя разрешение на проведение документа Перемещение? Так это невозможно. Я после вашего поста настолько офигел из-за возможность творить такую дичь, что даже полез смотреть rbac в yii2. Оказалось все нормально, отозвать можно только то разрешение, которое было непосредственно назначено пользователю.
А решается этот вопрос в рамках RBAC двумя способами.
Первый - вам нужно добавить стажера временно, тогда вы просто клонируете в админке роль (нужно просто добавить функционал клонирования, если его нет) и забираете у нее разрешение на проведение документа Перемещение.
Второй - если вам нужно добавить на постоянно, добавляете роль Кладовщик-стажер роли Кладовщик и удаляете у нее все разрешения кроме разрешения на Перемещение.
Все это занимает буквально одну минуту.

Для чего убирать? Какая цель преследуется?

Роли и разрешения - это разные уровни абстракции. Бизнес работает с ролями, которые являются абстракциями в терминах бизнес-процессов. Кладовщик, Продавец, Бухгалтер - это все абстракции в терминах бизнес-процессов. Администратор системы работает с абстракцией Разрешение - это абстракция в терминах реализации функционала необходимого для формирование ролей.

[yiijeka]

Полезна ли возможность назначать permission на пользователя напрямую, а не через роль?

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

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

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

[yiiliveext]

Так работает в Yii 2. Это пока единственная мотивация.

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

[yiiliveext]

Полезна ли возможность назначать permission на пользователя напрямую, а не через роль?

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

Назначение разрешений напрямую пользователям - это ACL. Возможно есть смысл сделать его полноценную реализацию для приведенных вами целей.

[yiijeka]

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

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

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

[yiijeka]

Так работает в Yii 2. Это пока единственная мотивация.

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

Полностью согласен.

[yiiliveext]

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

Это уже другой пример, реализация ACL (с группами) полезна для организации альтернативной системы контроля доступа, более понятной обычным пользователям, как в первом примере.
В вашем примере с парочкой разрешений реализуется в рамках RBAC назначением скрытой роли.

[yiijeka]

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

[yiiliveext]

Получится для каждого пользователя своя скрытая роль. Реализация чуть сложнее, чем просто назначить разрешение на пользователя.

Та ладно:)
Вместо

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

$auth->assign($permission, $userId);

будет

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

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

[raketa]

Абсолютно надуманный пример. Вот, например, у вас есть роль Кладовщик, в которой есть разрешения для работы со складскими документами, и вам понадобилась роль Кладовщик-стажер, который может все, что Кладовщик, кроме проведения документа Перемещение. Вы сейчас предлагаете стажеру назначить роль Кладовщик и отозвать у этого пользователя разрешение на проведение документа Перемещение? Так это невозможно. Я после вашего поста настолько офигел из-за возможность творить такую дичь, что даже полез смотреть rbac в yii2. Оказалось все нормально, отозвать можно только то разрешение, которое было непосредственно назначено пользователю.
А решается этот вопрос в рамках RBAC двумя способами.
Первый - вам нужно добавить стажера временно, тогда вы просто клонируете в админке роль (нужно просто добавить функционал клонирования, если его нет) и забираете у нее разрешение на проведение документа Перемещение.
Второй - если вам нужно добавить на постоянно, добавляете роль Кладовщик-стажер роли Кладовщик и удаляете у нее все разрешения кроме разрешения на Перемещение.
Все это занимает буквально одну минуту.

Зачем офигевать и лезть смотреть в rbac в yii2, конечно в стандартном rbac этого нет, но если бы был запрет давать разрешение напрямую пользователю, сделать свою релизацию было сложнее.
Понятно что в идеале создавать "КладовщикСтажер", или "КладовщикСтажерСтажера", "КладовщикПоВсемКромеОООРомашка" и тд и тп, но есть ситуации когда проще не плодить такие роли, это не в теория это практика. Будет столько ролей что будет сложно сделать правильный выбор между "КладовщикСтажер" и например "КладовщикСтаршийСтажер"

Роли и разрешения - это разные уровни абстракции. Бизнес работает с ролями, которые являются абстракциями в терминах бизнес-процессов. Кладовщик, Продавец, Бухгалтер - это все абстракции в терминах бизнес-процессов. Администратор системы работает с абстракцией Разрешение - это абстракция в терминах реализации функционала необходимого для формирование ролей.

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

В вашем примере с парочкой разрешений реализуется в рамках RBAC назначением скрытой роли.

Вот об этом и речь, сделать чтобы потом это обойти скрытыми ролями.
Вопрос был поставлен вот так "Полезна ли возможность назначать permission на пользователя напрямую, а не через роль?"
Так для чего это полезно только для абстракций?
Если ставить вопрос "Правильно ли в теории давать возможность назначать permission на пользователя напрямую, а не через роль?" конечно же не правильно и спору нет.
Другое дело что $user->can('роль') это зло, потому что роль сама по себе это не разрешение на действие.