Управление доступом - действительно ли RBAC стоит реализовать в иерархической системе управления пользователями?

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

Обратите внимание, что термин "роль" в RBAC - это то, что может ограничить реализацию. Я имею в виду, что традиционная система RBAC имеет такие правила, как:

allow (a) role (to do an) action (on an) object

В псевдокоде у вас может быть такой метод:

myRbac.allow(Member, View, Post)

Однако ничто не мешает вам абстрагироваться от ролей. Обычно роль - это имя строки. С помощью этого строкового имени вы можете также называть свои группы и пользователей. В этом случае, если вы используете этот метод творчески, то он позволяет использовать гораздо больше, чем просто роли. Назовите это Object based или что-то другое, но по сути это одно и то же: вы позволяете чему-то делать действие над чем-то.

allow (an) object (to do an) action (on an) object

Если вы посмотрите на это с этой точки зрения, то ваша реализация, IMHO, будет достаточно простой, чтобы оправдать затраты на реализацию. Не позволяйте термину "роль" ограничивать простоту, которую может иметь реализация. И если вы можете сделать реализацию настолько простой, почему бы не пойти на это?

Похоже, вы знаете PHP. Если вы посмотрите на Zend Framework ACL, то увидите реализацию, основанную на роли. Возможно, это вдохновит вас.

редактирование: об иерархии: Не сложно реализовать иерархию для ролей (объектов или имен по расширению). Проверьте, есть ли правила для запрашиваемого объекта-объекта. Если в иерархии нет ни одного, пока не будет разрешено или запрещено. Если пользователь может иметь несколько ролей (например, роль участника и находится в группе Administrators (так же известной как роль AdministratorGroup)), вы должны выбрать, будет ли запрет отменять разрешение или наоборот. Я предпочитаю, чтобы разрешающий выигрывал, когда уровни параллельны (например, действие разрешено для роли A, но запрещено для роли B, у нашего пользователя есть и роли A и B, и роли A и B не связаны, не в иерархии).

Re: ваш пример иерархии. В Zend Framework ACL это может быть так:

$acl->addRole(new Zend_Acl_Role('Role1'))
    ->addRole(new Zend_Acl_Role('Group1', array('Role1'))
    ->addRole(new Zend_Acl_Role('Group2', array('Group1));
$acl->allow('Role1', 'someAction', 'someObject'); // permission 1
$acl->allow('Role1', 'otherAction', 'otherObject'); // permission 2
$acl->deny('Group2', 'someAction', 'someObject');

Честно говоря, прошло некоторое время с тех пор, как я создал свою собственную систему.

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

Мы реализуем довольно сложную RBAC в нашем продукте с полиархивными бизнес ролями и техническими ролями, которые ограничены по типу защищаемых ими ресурсов - http://blog.identitymanagement.com/downloads/. В Microsoft's есть новая основа программирования, основанная на претензиях, называемая Windows Identity Foundation - она обрабатывает большую часть водопроводных сетей для вас

Патрик Паркер