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

#

.

<code># 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</code>

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:

<code>p, alice, data1, read
p, bob, data2, write
p, data2_admin, data2, read
p, data2_admin, data2, write
g, alice, data2_admin</code>

Practical Implementation

Create Project

Initialize a Go module named

casbin_test

with the following directory layout:

<code>├─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</code>

Install dependencies:

<code>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</code>

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.