casbin

An authorization library that supports access control models like ACL, RBAC, ABAC in Golang: https://discord.gg/S5UjpzGZjN

17,484

1,623

17,484

View on GitHub View on NPM

Top Related Projects

spicedb

4,924

Open Source, Google Zanzibar-inspired permissions database to enable fine-grained authorization for customer applications

Open Source (Go) implementation of "Zanzibar: Google's Consistent, Global Authorization System". Ships gRPC, REST APIs, newSQL, and an easy and granular permission language. Supports ACL, RBAC, and other access models.

opa

9,505

Open Policy Agent (OPA) is an open source, general-purpose policy engine.

opal

4,143

Policy and data administration, distribution, and real-time updates on top of Policy Agents (OPA, Cedar, ...)

Quick Overview

Casbin is an authorization library that supports access control models like ACL, RBAC, ABAC for various programming languages. It provides a unified interface to define and enforce access control policies, allowing developers to easily implement complex authorization logic in their applications.

Pros

Supports multiple access control models and can be easily extended
Language-agnostic with implementations in various programming languages
Provides a simple and expressive policy language (PERM)
High performance with support for policy caching and efficient rule matching

Cons

Learning curve for understanding and implementing complex policies
Limited built-in support for dynamic policy updates in some language implementations
May require additional setup for integrating with certain frameworks or databases
Documentation can be inconsistent across different language implementations

Code Examples

Basic RBAC model:

e, _ := casbin.NewEnforcer("path/to/model.conf", "path/to/policy.csv")
sub := "alice"  // the user that wants to access a resource
obj := "data1"  // the resource that is going to be accessed
act := "read"   // the operation that the user wants to perform on the resource

if allowed, _ := e.Enforce(sub, obj, act); allowed {
    // permit alice to read data1
} else {
    // deny the request, show an error
}

Adding a policy rule dynamically:

e, _ := casbin.NewEnforcer("path/to/model.conf", "path/to/policy.csv")
added, _ := e.AddPolicy("bob", "data2", "write")
if added {
    fmt.Println("Policy added successfully")
}

Checking permissions for a user:

e, _ := casbin.NewEnforcer("path/to/model.conf", "path/to/policy.csv")
permissions := e.GetPermissionsForUser("alice")
for _, perm := range permissions {
    fmt.Printf("User alice has permission: %v\n", perm)
}

Getting Started

To use Casbin in your Go project:

Install Casbin:
```
go get github.com/casbin/casbin/v2
```
Create a model file (e.g., model.conf) and a policy file (e.g., policy.csv).

Use Casbin in your code:

import "github.com/casbin/casbin/v2"

func main() {
    e, _ := casbin.NewEnforcer("path/to/model.conf", "path/to/policy.csv")
    sub, obj, act := "alice", "data1", "read"
    if allowed, _ := e.Enforce(sub, obj, act); allowed {
        // Alice is allowed to read data1
    } else {
        // Deny the request
    }
}

Competitor Comparisons

spicedb

4,924

Open Source, Google Zanzibar-inspired permissions database to enable fine-grained authorization for customer applications

Pros of SpiceDB

Built-in support for distributed systems and high scalability
Offers a gRPC API for efficient communication
Provides a more expressive relationship-based authorization model

Cons of SpiceDB

Steeper learning curve due to its complex relationship model
Less flexible in terms of policy definition compared to Casbin
Requires more setup and infrastructure for deployment

Code Comparison

SpiceDB schema definition:

definition user {}

definition document {
    relation viewer: user
    relation editor: user
    permission view = viewer + editor
    permission edit = editor
}

Casbin policy definition:

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

Key Differences

SpiceDB uses a relationship-based model, while Casbin uses a more traditional RBAC/ABAC approach
SpiceDB is designed for large-scale distributed systems, whereas Casbin is more versatile and can be used in various environments
Casbin offers more flexibility in policy definition, while SpiceDB provides a more structured approach to modeling complex relationships

Use Cases

SpiceDB: Ideal for large-scale applications with complex authorization requirements and distributed architectures
Casbin: Suitable for a wide range of applications, from small projects to enterprise systems, with flexible policy needs

Both projects have their strengths, and the choice between them depends on the specific requirements of your application, including scale, complexity, and deployment environment.

keto

4,774

Pros of Keto

Built-in gRPC and REST APIs for easier integration
Designed for cloud-native environments with Kubernetes support
Offers fine-grained permission management with relation tuples

Cons of Keto

Steeper learning curve due to complex concepts
Less flexible policy model compared to Casbin's PERM model
Requires additional components (e.g., Ory Hydra) for full IAM solution

Code Comparison

Keto (using Go SDK):

import "github.com/ory/keto-client-go"

client, _ := keto.NewSDK(&keto.Configuration{
    EndpointURL: "http://localhost:4466",
})

allowed, _ := client.PermissionApi.CheckPermission(context.Background()).
    Namespace("files").Subject("alice").Action("view").Resource("secret.txt").Execute()

Casbin:

import "github.com/casbin/casbin/v2"

e, _ := casbin.NewEnforcer("model.conf", "policy.csv")

allowed, _ := e.Enforce("alice", "secret.txt", "view")

Both Keto and Casbin provide powerful authorization solutions, but they differ in approach and complexity. Keto is more suited for cloud-native environments and offers fine-grained control, while Casbin provides a simpler and more flexible policy model that can be easily adapted to various scenarios.

opa

9,505

Open Policy Agent (OPA) is an open source, general-purpose policy engine.

Pros of OPA

More expressive policy language (Rego) for complex rules
Built-in query and decision-making capabilities
Wider ecosystem and integrations with various platforms

Cons of OPA

Steeper learning curve due to Rego language complexity
Potentially higher resource usage for large-scale deployments
Less straightforward for simple access control scenarios

Code Comparison

Casbin policy example:

[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

OPA policy example:

package authz

default allow = false

allow {
    input.method == "GET"
    input.path == ["users", user_id]
    input.user.id == user_id
}

Casbin focuses on a more structured, role-based access control model, while OPA offers a more flexible, general-purpose policy language. Casbin's syntax is simpler and more intuitive for basic access control, whereas OPA's Rego language provides greater expressiveness for complex scenarios. OPA excels in distributed systems and cloud-native environments, while Casbin is often preferred for simpler, application-level access control.

opal

4,143

Policy and data administration, distribution, and real-time updates on top of Policy Agents (OPA, Cedar, ...)

Pros of OPAL

Real-time policy updates and distribution
Built-in support for policy data sources like Git and databases
Designed for scalability and high-performance environments

Cons of OPAL

More complex setup and configuration compared to Casbin
Requires additional infrastructure components (e.g., PubSub system)
Less mature project with potentially fewer community resources

Code Comparison

OPAL (Policy Definition):

{
  "policies": [
    {
      "id": "allow_read",
      "effect": "allow",
      "actions": ["read"],
      "resources": ["document:*"],
      "subjects": ["role:user"]
    }
  ]
}

Casbin (Policy Definition):

p, role:user, document:*, read

OPAL focuses on a JSON-based policy format, while Casbin uses a more compact, line-based format. OPAL's approach may be more verbose but can offer better structure for complex policies. Casbin's format is simpler and easier to read for basic use cases.

Both projects aim to provide flexible authorization solutions, but OPAL is geared towards distributed systems with real-time updates, while Casbin offers a lightweight, embeddable approach suitable for various application types.

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

Casbin

News: still worry about how to write the correct Casbin policy? Casbin online editor is coming to help! Try it at: https://casbin.org/editor/

Casbin is a powerful and efficient open-source access control library for Golang projects. It provides support for enforcing authorization based on various access control models.

^{Sponsored by}

Build auth with fraud prevention, faster.
Try Stytch for API-first authentication, user & org management, multi-tenant SSO, MFA, device fingerprinting, and more.

All the languages supported by Casbin:


Casbin	jCasbin	node-Casbin	PHP-Casbin
production-ready	production-ready	production-ready	production-ready


PyCasbin	Casbin.NET	Casbin-CPP	Casbin-RS
production-ready	production-ready	production-ready	production-ready

Supported models
How it works?
Features
Installation
Documentation
Online editor
Tutorials
Get started
Policy management
Policy persistence
Policy consistence between multiple nodes
Role manager
Benchmarks
Examples
Middlewares
Our adopters

Supported models

ACL (Access Control List)
ACL with superuser
ACL without users: especially useful for systems that don't have authentication or user log-ins.
ACL without resources: some scenarios may target for a type of resources instead of an individual resource by using permissions like write-article, read-log. It doesn't control the access to a specific article or log.
RBAC (Role-Based Access Control)
RBAC with resource roles: both users and resources can have roles (or groups) at the same time.
RBAC with domains/tenants: users can have different role sets for different domains/tenants.
ABAC (Attribute-Based Access Control): syntax sugar like resource.Owner can be used to get the attribute for a resource.
RESTful: supports paths like /res/*, /res/:id and HTTP methods like GET, POST, PUT, DELETE.
Deny-override: both allow and deny authorizations are supported, deny overrides the allow.
Priority: the policy rules can be prioritized like firewall rules.

How it works?

In Casbin, an access control model is abstracted into a CONF file based on the PERM metamodel (Policy, Effect, Request, Matchers). So switching or upgrading the authorization mechanism for a project is just as simple as modifying a configuration. You can customize your own access control model by combining the available models. For example, you can get RBAC roles and ABAC attributes together inside one model and share one set of policy rules.

The most basic and simplest model in Casbin is ACL. ACL's model CONF is:

# 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

An example policy for ACL model is like:

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

It means:

alice can read data1
bob can write data2

We also support multi-line mode by appending '\' in the end:

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

Further more, if you are using ABAC, you can try operator in like following in Casbin golang edition (jCasbin and Node-Casbin are not supported yet):

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

But you SHOULD make sure that the length of the array is MORE than 1, otherwise there will cause it to panic.

For more operators, you may take a look at govaluate

Features

What Casbin does:

enforce the policy in the classic {subject, object, action} form or a customized form as you defined, both allow and deny authorizations are supported.
handle the storage of the access control model and its policy.
manage the role-user mappings and role-role mappings (aka role hierarchy in RBAC).
support built-in superuser like root or administrator. A superuser can do anything without explicit permissions.
multiple built-in operators to support the rule matching. For example, keyMatch can map a resource key /foo/bar to the pattern /foo*.

What Casbin does NOT do:

authentication (aka verify username and password when a user logs in)
manage the list of users or roles. I believe it's more convenient for the project itself to manage these entities. Users usually have their passwords, and Casbin is not designed as a password container. However, Casbin stores the user-role mapping for the RBAC scenario.

Installation

go get github.com/casbin/casbin/v2

Documentation

https://casbin.org/docs/overview

Online editor

You can also use the online editor (https://casbin.org/editor/) to write your Casbin model and policy in your web browser. It provides functionality such as syntax highlighting and code completion, just like an IDE for a programming language.

Tutorials

https://casbin.org/docs/tutorials

Get started

New a Casbin enforcer with a model file and a policy file:

e, _ := casbin.NewEnforcer("path/to/model.conf", "path/to/policy.csv")

Note: you can also initialize an enforcer with policy in DB instead of file, see Policy-persistence section for details.

Add an enforcement hook into your code right before the access happens:

sub := "alice" // the user that wants to access a resource.
obj := "data1" // the resource that is going to be accessed.
act := "read" // the operation that the user performs on the resource.

if res, _ := e.Enforce(sub, obj, act); res {
    // permit alice to read data1
} else {
    // deny the request, show an error
}

Besides the static policy file, Casbin also provides API for permission management at run-time. For example, You can get all the roles assigned to a user as below:
```
roles, _ := e.GetImplicitRolesForUser(sub)
```

See Policy management APIs for more usage.

Policy management

Casbin provides two sets of APIs to manage permissions:

Management API: the primitive API that provides full support for Casbin policy management.
RBAC API: a more friendly API for RBAC. This API is a subset of Management API. The RBAC users could use this API to simplify the code.

We also provide a web-based UI for model management and policy management:

model editor

policy editor

Policy persistence

https://casbin.org/docs/adapters

Policy consistence between multiple nodes

https://casbin.org/docs/watchers

Role manager

https://casbin.org/docs/role-managers

Benchmarks

https://casbin.org/docs/benchmark

Examples

Model	Model file	Policy file
ACL	basic_model.conf	basic_policy.csv
ACL with superuser	basic_model_with_root.conf	basic_policy.csv
ACL without users	basic_model_without_users.conf	basic_policy_without_users.csv
ACL without resources	basic_model_without_resources.conf	basic_policy_without_resources.csv
RBAC	rbac_model.conf	rbac_policy.csv
RBAC with resource roles	rbac_model_with_resource_roles.conf	rbac_policy_with_resource_roles.csv
RBAC with domains/tenants	rbac_model_with_domains.conf	rbac_policy_with_domains.csv
ABAC	abac_model.conf	N/A
RESTful	keymatch_model.conf	keymatch_policy.csv
Deny-override	rbac_model_with_deny.conf	rbac_policy_with_deny.csv
Priority	priority_model.conf	priority_policy.csv