RBAC с дополнительным уровнем - PullRequest
Новая
       25

RBAC с дополнительным уровнем

4 голосов
/ 28 февраля 2012

Я пытаюсь создать базу данных для RBAC с изюминкой (или, может быть, это только я, кто думает, что это изюминка?).Как я понимаю, RBAC использует роли и разрешения для предоставления / запрета доступа к определенным объектам в моей системе.Все хорошо и понятно, когда у меня есть только один экземпляр моего сайта и я просто создаю роль 'Main admin', 'Secondary admin', 'User' и т. Д.

Однако что, если у меня есть аккаунты?внутри системы?Итак, у меня есть одна система, в которой есть учетные записи «London», «Tokyo» и «Moscow».Теперь у меня будет «Главный администратор» для каждой из учетных записей, а также «Пользователи» в каждой учетной записи - конечно, московские парни не должны иметь возможности войти в учетную запись в Лондоне.Как мне это сделать?Создать дополнительную таблицу, которая будет привязывать назначения к учетным записям пользователей?Или мне добавить accountid в таблицу назначений?Или, возможно, мне следует создать несколько ролей, таких как «moscow_main_admin», «london_main_admin» и т. Д. Каков наилучший подход для такого типа ситуаций?

Также я считаю, что у меня будут пользователи, которые являются «Главным администратором» для Лондонаучетная запись и «Вторичный администратор» для учетной записи Токио.

Я планирую использовать Yii со встроенным в RBAC ... если это что-то изменит.

Как с этим справиться?

Заранее спасибо!

Ответы [ 3 ]

1 голос
/ 04 марта 2012

Вы можете сохранить роли и правила администратора, так как вы уже использовали их.И добавьте новую роль для каждого города: «Москва», «Лондон» и т. Д. .... В контроллере вызовите checkAccess в ваших методах действия, как в следующем примере.

public function actionEditArticle($town)
{
 if(!Yii::app()->user->checkAccess($town)
  Yii::app()->end();

 // ... more code
}

Более продвинутый метод - расширить CController в каталоге компонентов и переопределить метод runAction($action). 

public function runAction($action)
{
    if (isset($_GET['town']) {
        if(!Yii::app()->user->checkAccess($_GET['town']) Yii::app()->end();
    }
    parent::runAction($action);
}
0 голосов
/ 11 августа 2015

Лучше всего подходит для ваших требований является создание группы и групповой иерархии. Назначьте роль группе, которая будет косвенно назначать всем ее дочерним группам. Таким образом, вы можете назначить общую роль для родительской группы и отдельную роль для отдельной группы. Итак, в вашем случае Лондон, Токио и Москва - это группы.

Я реализовал это решение с помощью средства контроля доступа безопасности Visual Guard, которое реализовало и охватило большинство проблем безопасности приложения.

Я использовал Visual guard для контроля доступа для мультитенантных приложений и приложений saas, в которых я широко использовал группы.

Нажмите здесь , чтобы узнать больше.

0 голосов
/ 18 апреля 2015

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

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

Второй способ (если он может представлять интерес) - это то, с чем я экспериментировал, пытаясь «расширить» RBAC по академическим причинам.

Что я сделал, так это разрешил определение двух или более «именованных» уровней для каждой роли. Поэтому, учитывая роль программиста, моя реализация позволяет добавлять уровни к роли, такие как:

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

  1. "Старший" = уровень 500
  2. "Средний" = уровень 200
  3. "Младший" = уровень 0

Поэтому, когда кто-то назначает разрешения для экземпляра объекта, такого как документ спецификации, он может быть назначен следующим образом:

«Некоторый документ» -> Программист (уровень 300) -> может редактировать «Какой-то документ» -> Программист (уровень 0) -> умеет читать «Какой-то документ» -> Программист (уровень 500) -> может удалить

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

Это позволяет мне иметь 3 разных уровня разрешений, только создав одну роль. В традиционной системе мне пришлось бы создать три разные роли (4 с наследованием), такие как:

В неиерархической реализации:

  1. Старший программист
  2. Средний программист
  3. младший программист

В иерархической реализации:

  1. Программист
  2. Старший программист (расширяет Программист)
  3. Средний программист (расширяет Программист)
  4. младший программист (расширяет программист)

Очевидно, что уровни должны быть правильно определены как под-роли. Определение уровня «Аналитик» будет недопустимым, поскольку это две разные роли, а не подтип.

...