# `Casbin` R&D Casbin is a powerful and efficient open-source access control library. It provides support for enforcing authorization based on various access control models. ## What is `Access Control` ? Access control is a method of guaranteeing that users are who they say they are and that they have the appropriate access to company data. Comprises of two segments - `Authentication` - Verify User's claim, or to check if they are who they claim - `Authorization` - Verify that a particular user should have the right to make a transaction on a resource ## How does casbin work ? Casbin works based on a configuration, which is written based on the `PERM(Policy, Effect, Request, Matchers)` model. ### Request Defines the structure of the request, typically the subject (user), object (resorce) and the action (read,write,edit...) ### Policy Defines the structure of the access strategy, which is why request looks simliar to policy. ### Matcher Matches the incoming request with policy ### Effect When request matches policy the effect is provided by this segment, whether to allow or deny the request ## Sample Configuration ```shell= # 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 ``` ## Sample Policy Defination ```shell= p, alice, data1, read // means alice can read data1 p, bob, data2, write // means bob can write data2 ``` ## Casbin Supported Access Control Models ```shell= 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. ``` ## Our focus - General ACL (to understand casbin) - A subject can do a certain action on an object - RBAC (Role Based Access Control) - ACL + A subject can be part of group/role and that role can do actions on an object - ABAC (Attribute Based Access Control) ## General ACL [*Repository* : Casbin-ACL, main.func : **testSimpleACL**](https://github.com/nafeem-evatix/casbin-acl/blob/94bda4e0e2e309b2a45865f1126fdf31c76a7609/cmd/main/main.go#L51) Idea : Lets imagine we have an object `data1`, we can manipulate this data1 by crud operations, we want to experiment which user can do which operation. ## RBAC [*Repository* : Casbin-ACL, main.func : **testRBAC**](https://github.com/nafeem-evatix/casbin-acl/blob/94bda4e0e2e309b2a45865f1126fdf31c76a7609/cmd/main/main.go#L28) Same Idea continued,updated configuration, added logic for role assigning and then added policy for that role ## Project Work Flow (check repo for implementation) - Define Policy Configuration - Get *gorm.DB object - Create Adapter with *gorm.DB - Get Enforcer with Adapter - Assign user a role using Enforcer - Add policy using Enforcer - Save policy - Use Enforcer to check a policy, whether to allow or deny - We can also remove policy using Enforcer