Фильтр CakePHP 3.x Результаты запроса на основе группы пользователей / организации / группы

Question

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

В моем приложении:

1. Есть х организаций
2. В каждой организации x членов

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

Примеры:

1. Список всех задач, с которыми связан текущий участник (Роль: Пользователь, ManyToMany с JoinTable)
2. Список всех задач, связанных с пользователями одной организации
3. При редактировании задачи перечислять только пользователей, которые являются членами одной организации

4. Абсолютно препятствовать любой глубине ассоциации возвращать результаты, не связанные с организацией пользователя

   class OrganizedBehavior extends Behavior {
       protected $_defaultConfig = [];
   
       public function beforeFind(Event $event, Query $query, ArrayObject $options) {
           $modelName = $event->getSubject()->getAlias();
           if(isset($options['oid'])) {
               $query->where([$modelName.'.oid' => $options['oid']]);
           }
           return $query;
       }
   }
   

Может ли это быть достигнуто с помощью:

1. Общее поведение?
2. Пользовательское промежуточное ПО?
3. Класс аутентификации / авторизации?
4. Что-нибудь лучше?

Answer 1

Этого можно добиться, осуществив внешнюю авторизацию и используя стороннюю платформу. На самом деле существует архитектурный подход, называемый управлением доступом на основе атрибутов ( abac ), который позволит вам сделать это. В ABAC:

• вы определяете политику, например A user with role='X' can do action='view' on object of type='Y' if user.organization==object.organization
• вы определяете атрибуты, которые будете использовать в политиках, например, Роль, отдел, место, организация.

Существует несколько стандартов и пакетов, которые можно использовать для определения собственных политик, таких как XACML, ALFA или OPA (REGO).

Общая архитектура выглядит следующим образом:

• Точка применения политики (PEP): именно здесь ваше приложение интегрируется со службой авторизации. Интеграция может быть PHP-кодом в вашем приложении, вызывающим PDP, или промежуточным программным обеспечением (как вы сказали) или шлюзом API ...
• Точка принятия решения о политике (PDP): здесь политики оцениваются по входящим запросам авторизации. В конечном итоге PDP возвращает решение (Permit / Deny) и, необязательно, дополнительные метаданные, которые PEP должен обработать.
• Информационный пункт политики (PIP): здесь PDP может получить недостающую информацию (например, оценку риска или отдел пользователя) для принятия решения.

Это решение не относится к PHP. Существует специфичная для PHP реализация, которую вы можете найти здесь . В качестве альтернативы рассмотрим AuthZForce (сервис авторизации с открытым исходным кодом) или Axiomatics (коммерческий). Оба могут защищать приложения PHP, а также другие языки.