PHP-Casbin Authorization Models for PHP Applications

What PHP-Casbin Handles in PHP Authorization

PHP-Casbin solves the authorization decision problem for PHP projects. Authentication may establish who a user is, but the application still needs to decide whether that subject may perform an action against an object. PHP-Casbin provides that decision layer through an Enforcer and a configurable access control model. It supports ACL, ACL with a superuser, ACL without users, ACL without resources, RBAC, RBAC with resource roles, RBAC with domains or tenants, ABAC, RESTful rules, deny-override, and prioritized policies.

The target audience is PHP developers who need authorization rules separated from application control flow. This is useful when the same application must support different permission structures, such as direct user permissions, role hierarchies, tenant-specific roles, or rules based on resource attributes. The README also identifies Laravel-authz as a separate authorization library for Laravel projects. Laravel developers should account for that integration layer rather than assuming the core package supplies framework-specific behavior.

The library does not authenticate users, verify usernames or passwords, or manage user identity. The README explicitly places those responsibilities outside PHP-Casbin. The application remains responsible for identifying the subject and for placing the enforcement hook immediately before access occurs.

The PERM Model, Policy Files, and Enforcement Flow

The central design is the PERM metamodel: Policy, Effect, Request, and Matchers. The request definition describes the values supplied for an authorization check, the policy definition describes the stored rule fields, the policy effect explains how matches become allow or deny decisions, and the matcher defines the comparison logic. Keeping these parts in a CONF file means changing the authorization mechanism can involve changing model configuration rather than rewriting every authorization branch in PHP.

For a basic ACL model, the request and policy both use subject, object, and action. The matcher requires equality across all three fields. A policy such as `p, alice, data1, read` therefore permits alice to read data1, while `p, bob, data2, write` permits bob to write data2. The policy file supplies the rules, while the model file supplies the interpretation.

The enforcement path is direct. Application code creates an Enforcer with a model file and policy file, then calls `enforce($sub, $obj, $act)`. The method returns a boolean decision. The README places this call immediately before access, which keeps authorization close to the protected operation. For RBAC, the role manager handles user-role and role-role mappings. For ABAC, matchers can access attributes such as `resource.Owner`. Other documented operators include `keyMatch`, which maps a resource key to a pattern.

This architecture is useful because policy semantics are data and configuration rather than a single hard-coded condition. It also creates a configuration responsibility. A syntactically valid policy file is not enough if its fields and matcher semantics do not represent the intended permission system.

Installing PHP-Casbin and Running the First ACL Check

The README directs users to add the package to the Composer-managed `composer.json`. The documented installation command is:

composer require casbin/casbin

After Composer installs the dependency, load the project autoloader and create an Enforcer from a model file and policy file. The following is the README's starting point, with the paths replaced by local paths:

require_once './vendor/autoload.php';

use Casbin\Enforcer;

$e = new Enforcer("path/to/model.conf", "path/to/policy.csv");

The Enforcer needs both files before the first real authorization decision. The model file defines the request, policy, effect, and matcher sections. The policy file contains rules in the fields expected by that model.

For a first ACL check, define the subject, object, and action as application values, then enforce them before granting access:

$sub = "alice";
$obj = "data1";
$act = "read";

if ($e->enforce($sub, $obj, $act) === true) {
    // permit alice to read data1
} else {
    // deny the request, show an error
}

With the ACL policy containing `p, alice, data1, read`, the documented behavior permits that read. The reader should also observe the deny branch for a subject or action that does not match. This example is an authorization check, not a login flow, because PHP-Casbin does not authenticate the subject.

RBAC, ABAC, REST Paths, and Policy Effects

PHP-Casbin's model set is broader than direct ACL matching. RBAC adds role-based decisions, and the README documents role-user mappings and role-role mappings. RBAC with resource roles allows both users and resources to have roles, while RBAC with domains or tenants gives users different role sets in different domains. Those variants matter for applications where a single global role list would be too broad.

ABAC changes the source of decision data. A matcher can use an attribute such as `resource.Owner`, allowing a request to depend on a property of the resource rather than only a literal policy subject. The repository includes separate example files for ABAC models and policies, including rule-based examples. ABAC behavior is represented through model configuration and policy files rather than a separate top-level application service.

RESTful models can match paths such as `/res/*` and `/res/:id` together with methods such as `GET`, `POST`, `PUT`, and `DELETE`. This is appropriate when the application exposes route-based permissions, but it requires correct matching rules for the actual path format. The deny-override effect supports both allow and deny authorizations, with deny taking precedence. Priority rules are also supported, so ordering can matter when policy rules overlap. These choices are explicit model decisions, not automatic defaults that the application can ignore.

Operational Boundaries, Maintenance, and Licensing

The first boundary is scope. PHP-Casbin enforces access control decisions, but it does not authenticate users, verify passwords, or manage users. A deployment that needs login, identity lifecycle, or user records must combine it with another component. A second boundary is policy correctness. The README does not document a rollback procedure, policy validation report, or automatic migration for changed policy semantics. Those are application and deployment concerns.

A third boundary is that the README presents the package as a PHP library, not as a complete web application or storage service. It handles the access control model and policy storage through the Enforcer, but the README does not establish which database adapter a particular production application should use. Integrators must account for their own persistence and deployment requirements rather than treating the package as a complete authorization platform.

The repository is not archived. Its last push was on 2026-10-03, and recent releases include `v4.6.0` on 2026-10-03, `v4.5.0` on 2026-09-06, and `v4.4.0` on 2026-08-12. Those dates indicate recent repository activity, but the README does not promise a particular compatibility policy or long-term support window. Upgrading still requires checking release changes and testing authorization decisions.

The project uses the Apache-2.0 license. That permits use and modification under the license's terms, subject to its conditions. This review does not provide legal advice, and adopters should review the license text and their own compliance obligations.

When a Different Authorization Approach Fits Better

PHP-Casbin is a policy-driven library, so it differs from approaches that encode every permission as application-specific conditionals. Its central mechanism is the model file plus policy file and the `enforce` call. This makes multiple access control models available through configuration, including role hierarchies, attributes, and REST patterns.

A framework-specific authorization layer may fit better when the application needs Laravel integration rather than direct library calls. The README explicitly points to `laravel-authz` for Laravel, which indicates that framework wiring is available through a related project. A hard-coded permission table or middleware chain can be simpler for a small application with a fixed set of rules, although it would require the application to define and maintain its own model semantics.

PHP-Casbin is not the right choice when authentication alone is the requirement, when user management is the primary task, or when the team cannot maintain configuration files and policy content. It is also a poor fit if authorization decisions must be explained through an existing database permission schema but the team is unwilling to translate that schema into the PERM model. The project solves policy evaluation, not every surrounding security responsibility.

Editorial conclusion

PHP-Casbin fits PHP applications that need configurable authorization decisions across ACL, RBAC, ABAC, or related models, especially teams already using Composer and policy files. It does not fit projects that need authentication or user management without another system. Verify first that the required model syntax, policy storage arrangement, matching behavior, and application integration match the project configuration before adoption.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. php-casbin/php-casbin on GitHub
3. Project website
4. README
5. Releases