How Casbin Simplifies Access Control with Flexible Models and Policies

Overview

Casbin is a powerful, high‑performance open‑source access‑control framework that supports a variety of access‑control models.

Supported Languages

Casbin (Go) – production ready

jCasbin (Java) – production ready

node‑Casbin (Node.js) – production ready

PHP‑Casbin – production ready

PyCasbin – production ready

Casbin4D – experimental

Casbin‑Net – work in progress

Casbin‑RS – work in progress

Key Features

What Casbin Does

Customizable request format (default {subject, object, action}).

Storage of access‑control models and policies.

Multi‑level role inheritance for both subjects and resources.

Support for super‑users (e.g., root or Administrator) that bypass policies.

Built‑in operators such as keyMatch for path‑based resource matching (e.g., /foo/bar matches /foo*).

What Casbin Does Not Do

Authentication – verifying usernames/passwords is outside Casbin’s scope; another component should handle it.

Managing user or role lists – Casbin expects the application to maintain these mappings, not to store passwords.

How It Works

Casbin abstracts an access‑control model using the PERM (Policy, Effect, Request, Matcher) metamodel. Switching or upgrading the authorization mechanism is as simple as editing a configuration file.

Example of the simplest ACL model ( model.conf) and its policy ( policy.csv).

# Request definition
[request_definition]
r = sub, obj, act

# Policy definition
[policy_definition]
p = sub, obj, act

# Policy effect
[policy_effect]
e = some(where (p.eft == allow))

# Matchers
[matchers]
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act

Corresponding policy entries:

p, alice, data1, read
p, bob, data2, write

This grants alice read access to data1 and bob write access to data2.

Long single‑line configurations can be split with a trailing backslash ( \).

# Matchers
[matchers]
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act

ABAC extensions (currently supported in Go and PHP) allow more complex matchers:

# Matchers
[matchers]
m = r.obj == p.obj && r.act == p.act || r.obj in ('data2', 'data3')

Quick Start

The three core concepts are Model, Policy, and Enforcer: Model – a CONF file describing request, policy, effect, and matcher definitions (the PERM metamodel). Policy – dynamic storage of policy rules, which can reside in .csv files or databases. Enforcer – evaluates whether a given subject can perform an action on an object.

Installation

composer require casbin/casbin

Configuration

Create model.conf and policy.csv files.

[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act

p, alice, data1, read
p, bob, data2, write

Instantiate an Enforcer with the model and policy files:

require_once './vendor/autoload.php';

use Casbin\Enforcer;

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

Perform an access check:

$sub = "alice"; // user
$obj = "data1"; // resource
$act = "read"; // operation

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