Проблема, которую я вижу при назначении роли в зависимости от того, что пользователь делает / имеет, заключается в том, что он жестко кодирует правила в вашем коде. Неявное правило в вашем примере:
deny user access when user has property/behavior X
Чтобы убедиться, что это жестко запрограммировано, спросите себя, что произойдет, если вы захотите изменить его. Предположим, что вы обнаружили подозрительное поведение слишком строгим и хотите допустить еще немного, тогда вам придется зайти в файл file.php и изменить его.
Я думаю, что вам лучше всего взглянуть на утверждение в правилах:
http://framework.zend.com/manual/en/zend.acl.advanced.html
В зависимости от ваших конкретных потребностей это может быть хорошим решением.
изменить: ответить на комментарий ->
Я ценю то, что вы делаете. Я думаю, что это указывает на то, почему RBAC будет заменен более мощными средствами управления доступом, такими как управление доступом на основе атрибутов. Это позволит правилам основываться на атрибутах пользователей и контролируемых объектов / ресурсов.
В идеале вы хотите, чтобы контроль доступа имел как можно больше логики принятия решения. Когда вы неявно назначаете роли пользователям, некоторые из решений будут приниматься вне контроля доступа (например, какой пользователь будет администратором, в основном определяется тем, кто владеет сайтом). Но вы хотите минимизировать принятие решений вне acl, потому что это добавляет уровень доступа, который не контролируется acl. Таким образом, решение о том, кто будет играть определенную роль, часто подразумевается и за пределами ACL. Но все же это контроль доступа, определяемый некоторой логикой, и лучше всего хранить в программе столько же логики, которая отвечает за обработку этого домена.
Надеюсь, что этот бессмысленный разговор имеет смысл: -)