Summary of how to use the access control (authorization) library Casbin
Casbin uses a PERM (Policy, Effect, Request, Matcher) based access control model. The model definition is described in the conf file, but it is necessary to describe at least four sections, Policy Definition, Policy Effect, Request Definition, and Matcher, which correspond to PERM.
Access Control List (ACL)
We will explain how to define a Casbin model using the ACL model definition used in file systems. (Reference: Syntax for Models)
Request Definition
[request_definition]
r = sub, obj, act
[request_definition] defines the model that is the input of the access judgment request (access request). Like the ACL model definition, in most cases, three things are used: sub (access executor), ʻobj (access target), and ʻact (access method).
Policy Definition
[policy_definition]
p = sub, obj, act
[policy_definition] defines the policy description format. If you write a policy that "file1 (obj)can beread (act)byuser1 (sub)in this model definition, it will be p, user1, file1, read.
Matcher
[matchers]
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act
[machers] defines a conditional expression that searches for a policy that matches the access judgment request. Access judgment request r and policy p Refer to the model defined in each [request_definition] with . and describe the conditional expression.
In the ACL model definition, it is determined that all of the access judgment requests sub ʻobj ʻact match the matching policy.
Policy Effect
[policy_effect]
e = some(where (p.eft == allow))
[policy_effect] defines how to make a judgment when multiple policies match the access judgment request.
In the ACL model definition, if any of the policies that match the conditional expression of Matcher has ʻeft set to ʻallow (some), the permission is judged.
This ʻeft is an element defined in Policy Definition when defining an access denial policy (blacklist). If ʻeft is not defined in the Policy Definition as in the ACL model definition, p.eft is assumed to have ʻallow set (default value is ʻallow). See Deny-override in Supported Models for an example of using the access denial policy.
Role Based Access Control (RBAC)
To support RBAC, the following two points should be changed from the ACL model definition. (Reference: RBAC)
Role Definition
[role_definition]
g = _, _
[role_definition] (optional section) defines the role description format. (It is easy to understand if you think of it as a role version of [policy_definition].)
If you describe the role1 assignment to ʻuser1 in this model definition, it will be g, user1, role1`.
Matchers
[matchers]
m = g(r.sub, p.sub) && r.obj == p.obj && r.act == p.act
[matchers] refers to Role Definition as a function and corresponds to the combination of the access executor r.sub (user) of the access judgment request and the access executor p.sub (role) of the policy. Determine if the policy exists.
Introduce an implementation example that reads the model definition of rbac_model.conf and determines roles, policies, and access requests. ..
/*Load model definition*/
Enforcer se = new Enforcer(ClassLoader.getSystemResource("rbac_model.conf").getFile());
//Use SyncedEnforcer class for multithreading
// Enforcer se = new SyncedEnforcer(ClassLoader.getSystemResource("rbac_model.conf").getFile());
/*Role assignment*/
se.addNamedGroupingPolicy("g", "user1", "role1");
//Default role (group) name"g"There is also a method for assigning to
//se.addGroupingPolicy("user1", "role1");
//se.addRoleForUser("user1", "role1");
se.addNamedPolicy("p", "role1", "data1", "read");
//Default policy name"p"There is also a method for adding policies to
se.addPolicy("role1", "data1", "read");
/*Access request judgment*/
if (se.enforce("user1", "data1", "read")) {
System.out.println("user1 can read data1.");
}
if (se.enforce("role1", "data1", "read")) {
System.out.println("role1 can read data1.");
}
/*Get user role*/
List<String> roleList = se.getRolesForUser("user1");
System.out.println("user1 has " + roleList + " roles.");
Execution result
user1 can read data1.
role1 can read data1.
user1 has [role1] roles.