Mastering Casbin: Build Secure RBAC in Go with Gin and Gorm

What is Casbin

Casbin is a powerful, efficient open‑source access‑control framework that supports multiple models. It handles only authorization.

Features include:

Custom request format, default {subject, object, action} Core concepts: model and policy

Multi‑level role inheritance for subjects and resources

Built‑in super‑user (e.g., root or administrator) that bypasses explicit policies

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

How Casbin Works

Casbin abstracts the access‑control model into four components—Policy, Effect, Request, Matcher (PERM). Policies define rules, matchers compare requests to policies, and effects determine whether the result is allow or deny.

Policy: defines permission rules

Effect: combines multiple policies

Request: the access request

Matcher: decides if a request satisfies a policy

Core Concepts

Model

The model is described in a .conf file that must contain at least four sections: [request_definition], [policy_definition], [policy_effect], [matchers]. When using RBAC, a [role_definition] section is also required. Comments start with #.

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

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

# Role definition
[role_definition]
g = _, _

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

[matchers]
m = r.sub == p.sub && ParamsMatch(r.obj,p.obj) && r.act == p.act

request_definition

defines

sub, obj, act

policy_definition

defines rules such as

p, alice, data1, read

role_definition

defines role inheritance with

g, _, _

policy_effect

decides the final effect, e.g.,

e = some(where (p.eft == allow))

matchers

are expressions that match requests to policies

Policy

Policy maps subjects, objects, and actions. Policies can be stored in CSV files or loaded via adapters (MySQL, PostgreSQL, SQLite, MongoDB, Redis, Cassandra, etc.). Example:

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

Practical Implementation

Create Project

Initialize a Go module named casbin_test with the following directory layout:

├─configs      # configuration files
├─global       # global variables
├─internal
│  ├─dao       # data access
│  ├─middleware# middleware
│  ├─model     # model layer
│  ├─router    # routing
│  │   └─api
│  │        └─v1
│  └─service   # business logic
├─pkg
│  ├─app
│  ├─errcode
│  └─setting

Install dependencies:

go get -u github.com/gin-gonic/gin
go get github.com/casbin/casbin
go get github.com/casbin/gorm-adapter
go get github.com/go-sql-driver/mysql
go get github.com/jinzhu/gorm

Create the MySQL database casbin_test and the casbin_rule table as shown.

Code Development

Key files include: configs/rbac_model.conf – model definition internal/model/casbin.go – Gorm model and CRUD methods internal/dao/casbin.go – DAO functions internal/service/service.go – service layer for creating and listing policies internal/router/api/v1/casbin.go – HTTP handlers with Swagger annotations internal/middleware/casbin_handler.go – middleware that enforces policies using

e.Enforce(sub, obj, act)

internal/router/router.go

– router setup with Casbin middleware

Verification

After launching the service, test the protected endpoint, add the path to the policy list, and observe that the request is allowed only after the policy is present.