Как реализовать систему разрешений, которая зависит от значений, которые пользователь пытается сохранить?

Контекст представляет собой систему управления образованием, построенную на Zend Framework. Мы реализуем RESTful MVC для обработки практически всех взаимодействий данных с клиентами. Отношения между ресурсами отображаются в базе данных с помощью внешних ключей и т. д.

Пример: учитель создает отчет по конкретному ученику.

В настоящее время у нас есть система разрешений на основе ролей, которую можно адаптировать к уровню отдельной роли (используя, например, teacher_5 в качестве имени роли). Поэтому мы можем легко ограничить доступ к уже существующему отчету (путем создания разрешений в модели отчета, которая позволяет редактировать/устанавливать разрешения на отчет только для роли наставника, создавшего его, скажем). Проблема возникает при создании. Чтобы добавить отчет, пользователь может разместить в /reports, например, следующие данные:

{ achievement: "4", performance: "5", student_id: "10" }

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

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

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

if ($acl->isAllowed($resource, $role, $action, $field, $value))

где $resource будет моделью отчета, $role будет учителем teacher_5, $action будет "сообщением", $field будет student_id, а $value будет 10. Класс acl, по сути, будет обрабатывать вызов самого $resource.

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