Laminas Permissions: ACL vs RBAC for Resource-Specific Constraints

Direct Answer

For a strict deny-by-default posture in a multi-tenant Laminas application, Laminas\Permissions\Acl provides stronger guarantees against fail-open scenarios because it evaluates explicit deny rules per resource-privilege pair, and deny entries take precedence over allows. Laminas\Permissions\Rbac inherits all parent permissions by default; a child role cannot "override" an inherited allow with a deny unless you explicitly add a deny rule for that resource, which is easy to miss when role hierarchies deepen.

Why ACL Minimizes Fail-Open Risk

• Resource-centric model: Every tenant resource (e.g., tenant:123:document:456) gets its own allow/deny entries. Missing an entry means access is denied by default.
• Explicit deny precedence: An explicit deny($role, $resource, $privilege) always wins over any allow, even from parent roles.
• Auditability: The permission matrix is a flat list of (role, resource, privilege, type) tuples—straightforward to scan for gaps per tenant.

RBAC Inheritance Behavior vs ACL

RBAC (Laminas\Permissions\Rbac)

• Child roles inherit all parent permissions (allows). There is no built-in "deny" concept—only presence or absence of a permission.
• To block a child from a parent's allowed resource, you must not grant that permission to the child and ensure the child does not inherit it via another path. If the parent has document:read, the child gets it automatically.
• Workaround: Model "deny" as a separate permission (e.g., document:read:deny) and check both in your authorization logic, but this is a convention, not framework behavior.

ACL (Laminas\Permissions\Acl)

• Supports both allow() and deny() at any level (role, resource, privilege).
• A child role can explicitly deny() a privilege that a parent allow()s—the deny wins.
• Inheritance is additive for allows; denies are evaluated after allows and take precedence.

Practical Verification Steps

1. Define a test hierarchy: parentRole allows tenant:A:report:view; childRole extends parent.
2. In ACL: add $acl->deny('childRole', 'tenant:A:report', 'view'); assert isAllowed('childRole', 'tenant:A:report', 'view') === false.
3. In RBAC: grant tenant:A:report:view to parent; do not grant to child; assert $rbac->isGranted('childRole', 'tenant:A:report:view') === false (only works if child has no other path to that permission).
4. Run your full tenant-resource matrix through both implementations and compare deny-by-default coverage.

Assumptions & Uncertainty

• Assumes Laminas 3.x (current). In 2.x, ACL deny precedence behaved differently—verify your version.
• Assumes resources are modeled per-tenant (e.g., tenant:123:resource). If you use generic resource IDs with runtime tenant checks, both components need extra filtering logic.
• RBAC can work for deny-by-default if you treat "no permission granted" as deny and never use wildcard permissions—but this requires discipline across all role definitions.

One Diagnostic Detail Needed

What Laminas version are you on (2.x vs 3.x), and are your resources scoped per-tenant in the ACL/RBAC store or filtered at runtime? The version changes deny-precedence semantics; the scoping strategy determines whether ACL's resource-centric advantage applies directly.