Я в настоящее время пытаюсь разработать Authorization модель, которая имеет следующие компоненты:Модель авторизации: контекст роли?
привилегии - действие, которое может быть либо разрешено или запрещены к пользователю/группе
Роли - это совокупность привилегий; Роли могут быть связаны с пользователем или группой
Объекты безопасности - объект, к которому безопасность применяется
Владельцы объектов - владелец объекта безопасности
Статусы - это атрибут, который представляет собой состояние объект безопасности
Пользователи - стандартный потребитель услуги; может быть отказано или предоставлен доступ к вещам
Группы - это набор пользователей, имеющих общую общую информацию; роли могут быть назначены группам; привилегии могут быть назначены группам
Мои вопросы таковы: существует ли способ правильно смоделировать контекст роли с текущими компонентами, которые я представил выше?
Например, предположим, что у меня есть текущее утверждение авторизации:
Tim can see Mary's profile information because Tim is Mary's friend.
Я препарировать это утверждение в модели компонентов:
User: Tim
Security Object: profile information
Object Owner: Mary
Privilege: view
Role: friend
Group: N/A?
Status: N/A
Одно дело, что это рассечение не атрибут является то, что Tim является другом of Mary
Есть ли компонент, который я могу добавить к этой модели, что wi ll захватить этот контекст («от Мэри»), или есть способ, которым я могу повторно представить заявление о привилегиях, используя мои ранее существовавшие компоненты модели auth? Какова наилучшая практика?
это интересный подход, который я не учел. Спасибо, что поделились этим со мной. В связи с этой моделью я нашел статью о другой модели, которая также может удовлетворить мои требования. Это называется ReBAC (Управление доступом на основе отношений) http://pages.cpsc.ucalgary.ca/~pwlfong/Pub/codaspy2011.pdf Теперь это просто вопрос для моих целей, если ABAC или ReBAC будут работать лучше для моего приложения. Еще раз спасибо. – Mackers