иерархическая система контроля доступа на основе ролей

Question

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

• Можно просмотреть список
• Можно просмотреть детали
• Может просматривать страницу сведений, но не может видеть поле адреса электронной почты / номера телефона
• можете редактировать полный документ
• может редактировать только номер телефона, но не может установить его на ноль в качестве нового значения.
• может полностью удалить запись
• может распечатать страницу, только если еще не стажер

Надеюсь, у вас есть идея. Существует около 100+ ресурсов, каждый из которых имеет от 20 до 90 подобных взаимосвязанных правил.

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

• использовать простой класс для каждой роли

• использовать перевернутую цепочку команд и добавить ссылку для ролей, текущая роль которых унаследована от

• текущий класс роли обрабатывает разрешения, уникальные только для текущего класса. и затем продолжает весь путь вверх (в реальной жизни вниз), чтобы вычислить полный график разрешений.

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

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

CountryManagerPermnissionsSpec()
{
    immediate_subordinates = ["RegionalManager", "ManagerHR"];
    accessible_resources = [
        "Finance": ["LIST", "DETAIL", "TRANSACTION_HISTORY", "REPORTS"] 

   ]

}

// class to limit the permissions when user is still under training 
TraineeUserPermissionsSpec()
{
     blocked_activites = ["delete", "bulk delete", "direct client message"];


}

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

new acl
acl->addRole(ContryManager)
acl->addRole(Trainee)

can_see_data = UserCanViewDataSpec(user, acl)

Теперь мой вопрос: это приводит нас к множеству крошечных, но проверяемых классов, что для нас не проблема, но является ли это правильным подходом к решению такой проблемы? Есть ли лучшая альтернатива?

Не думаю, что это имеет значение, но на всякий случай в php собирается текущая система.