Управление доступом на основе ролей с ограничениями разрешений через определенные атрибуты

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

Эта проблема

Некоторые разрешения имеют некоторые ограничения. Например:

Пользователь может редактировать все сообщения, принадлежащие его сайту, но не другие сообщения.

Поэтому разрешение «редактировать сообщение» должно иметь это ограничение.

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

Модель пользователя может иметь такой атрибут, как «сайт», но не все пользователи, принадлежащие одному сайту, должны иметь указанное выше ограничение. Некоторые из них должны иметь возможность редактировать все сообщения.

Вопрос

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

Любая помощь приветствуется :)


person NedRise    schedule 04.04.2016    source источник


Ответы (1)


Я ответил следующее на предыдущий аналогичный вопрос

Вы хотите использовать решение, которое независимо от типа защищаемого приложения. Это цель XACML, расширяемого языка разметки управления доступом.

XACML обеспечивает управление доступом на основе атрибутов и политик (ABAC и PBAC). Это дает вам возможность писать чрезвычайно выразительные политики авторизации и управлять ими централизованно в одном репозитории. Затем центральный механизм авторизации (называемый Policy Decision Point или PDP) будет предоставлять решения вашим различным приложениям.

Минимальный набор атрибутов, который вам понадобится, обычно включает атрибуты о пользователе (Subject), ресурсе и действии. XACML также позволяет добавлять атрибуты среды. Это означает, что вы можете написать следующий тип политики:

Врачи могут просматривать медицинские записи пациентов, которым они назначены.

  • Врачи описывает пользователя/субъект
  • представление описывает действие
  • медицинские записи описывает целевой ресурс
  • пациентов также описывает целевой ресурс. Это метаданные о ресурсе
  • они назначены — интересный случай. Это атрибут, который определяет отношения между врачом и пациентом. В ABAC это реализовано как doctor.id==patient.assignedDoctorId. Это одно из ключевых преимуществ использования XACML.

Преимущества XACML включают в себя: - возможность внедрить логику авторизации, как упоминалось Беллом - возможность обновлять логику авторизации, не проходя жизненный цикл разработки/развертывания - возможность реализации мелкозернистой авторизации одинаковым образом для многих различных приложений - возможность иметь видимость и аудит логики авторизации

ХТН

person David Brossard    schedule 05.04.2016
comment
Спасибо за быстрый ответ. Я буду смотреть в него. Фреймворк для реализации будет laravel, который вполне может подойти в отношении политик, которые можно использовать. Хотя мне потребуется некоторое время, чтобы глубже понять ABAC. Кроме того, я рассмотрю XACML, который может стать хорошим началом для понимания этого :) - person NedRise; 06.04.2016
comment
Я думаю, что в laravel есть все, что вам нужно. Он не использует XACML, но имеет аналогичные возможности. - person David Brossard; 06.04.2016