27 Permission Model How the Five Major Permission Models Grant Resource Permissions

27 Permission Model How the Five Major Permission Models Grant Resource Permissions #

Hello, I’m Kong Lingfei. Before I start explaining how to develop services, let me first introduce an important background knowledge: permission models.

In your development career, you may encounter a terrifying situation: Zhang San accidentally deletes Li Si’s resources. You may also come across a popular news story while browsing the news: a certain programmer deleting the database and running away. These operations are terrifying and make headlines because they often lead to significant losses.

So, how can we avoid these risks? The answer is to have good control over resource permissions, which is an unavoidable topic in project development. Tencent Cloud requires all cloud products to be integrated with the Cloud Access Management (CAM) service (Alibaba Cloud has similar requirements). The reason for doing this is because ensuring the security of resources is a very, very important task.

It can be said that ensuring the security of application resources has become an essential capability for an application. As a developer, you must also know how to ensure the security of your application’s resources. So how can we ensure the security of resources? I believe you need to master at least the following two points:

Permission Models: You need to be familiar with mature permission models in the industry and the scenarios in which these models are applicable. Only with a broad knowledge and vision, can we avoid reinventing the wheel and design excellent resource authorization solutions.
Implementation: After selecting or designing an excellent resource authorization solution, you need to write code to implement that solution. The IAM application in this course is a project that implements a resource authorization scheme. You can learn how to implement a resource authorization system by studying the IAM application.

Whether it’s the first point or the second point, you need to have a basic understanding of permission models. So in this lesson, I will introduce the excellent permission models in the industry and the scenarios in which these models are applicable, so that you can design better resource authorization systems in the future.

Before we dive into common authorization models in the industry, let’s first take a look at the terms that appear in these models. I have summarized the common terminology in the table below:

术语	英文	解释
用户	Subject	执行授权操作的实体，可以是具体的个人或者系统
操作	Action	针对资源所执行的具体操作，如读取、写入、修改等
资源	Object	需要进行授权访问的实体，可以是文件、数据库、API等
角色	Role	代表一组权限的集合，可以对用户进行授权，简化权限分配和管理
权限	Permission	指定用户在某个操作下对特定资源的授权使用权
授权策略	Policy	定义角色或用户具有的权限集合，用于授权决策
访问控制列表	ACL	一种用于授权访问资源的列表，包含用户和允许的操作类型
访问令牌	Token	确保用户在执行授权操作时具有足够的权限，通常使用加密的方式进行验证

To help you understand better, in this lesson, I will use “用户” (User), “操作” (Action), and “资源” (Resource) to replace “Subject,” “Action,” and “Object,” respectively.

Introduction to Permission Models #

Next, I will provide detailed explanations of some common permission models, so that in the future, you can choose the appropriate permission model based on your requirements when designing a permission system.

Different permission models have different characteristics and can meet different needs. The following are five common permission models:

Access Control List (ACL).
Discretionary Access Control (DAC).
Mandatory Access Control (MAC).
Role-Based Access Control (RBAC).
Attribute-Based Access Control (ABAC).

Now let’s briefly introduce these five permission models. ACL is a simple permission model; DAC is based on ACL and delegates permissions to subjects with the corresponding permissions. However, because of the delegation feature in DAC, it results in a dispersed control of permissions. In order to compensate for this drawback of DAC, the MAC permission model was introduced.

Both DAC and MAC are permission models based on ACL. ACL and its derivative permission models can be considered as permission models of the past era, where neither the flexibility nor functionality can meet the needs of modern applications. Therefore, RBAC, which is the most widely used permission model to date, was born.

However, as organizations and applications grow, the number of roles required also increases, making it difficult to manage and leading to role explosion and separation of duties (SoD) failure. Finally, a new and more dynamic form of access control was introduced, called attribute-based access control, or ABAC. ABAC is considered by some to be the future of permission system design. Tencent Cloud’s CAM, AWS’s IAM, and Alibaba Cloud’s RAM all provide permission access services of the ABAC type.

Next, I will provide detailed explanations of the basic concepts of these permission models.

Simple Permission Model: Access Control List (ACL) #

ACL (Access Control List) is used to determine whether a user can perform specific operations on a resource. For example, the ACL policy that allows Colin to create an article is:

Subject: Colin
Action: Create
Object: Article

In the ACL permission model, permission management is centered around the resource object, and ACL is relatively simple compared to other models.

Permission Model Based on ACL and Delegated Permissions: Discretionary Access Control (DAC) #

DAC (Discretionary Access Control) is an expanded model of ACL that provides greater flexibility. With this model, besides determining whether a subject can perform an action on an object, the subject can also grant the same permission of the object and action to other subjects. For example, Colin can create an article:

Subject: Colin
Action: Create
Object: Article

Because Colin has the permission to create articles, Colin can also grant James the permission to create articles:

Subject: James
Action: Create
Object: Article

The classic ACL model focuses on permission sets of the same subject, lacking flexibility. To enhance flexibility, the DAC model delegates permissions, allowing subjects with permissions to autonomously grant permissions to other subjects.

ACL-Based Permission Model with Higher Security: Mandatory Access Control (MAC) #

MAC (Mandatory Access Control) is an expanded model of ACL that provides higher security. In the MAC permission model, both the subject and object have security attributes. When granting authorization, both of the following conditions must be met for authorization to be granted:

The subject can perform the action on the object.
The object can be operated on by the subject.

For example, we have set up the MAC policy “Colin and James can create articles”:

Subject: Colin
Action: Create
Object: Article

Subject: James
Action: Create
Object: Article

We also have another MAC policy “Articles can be created by Colin”:

Subject: Article
Action: Create
Object: Colin

In the above policies, Colin can create articles, but James cannot create articles because the second policy is not satisfied.

Here, you need to note that in ACL and its extended models, the subject can be a user, group, or group.

ACL, DAC, and MAC are outdated access control models that cannot meet the modern application’s needs for access control. This led to the emergence of new access control models: RBAC and ABAC.

The most popular access control model: Role-Based Access Control (RBAC) #

RBAC (Role-Based Access Control) introduces the concept of roles and associates permissions with roles. Users gain all the permissions associated with the roles they play. The following diagram illustrates this concept:

As shown in the diagram, each user is associated with one or more roles, each role is associated with one or more permissions, and each permission contains one or more operations, which represent a set of operations on resources. By decoupling users and permissions, RBAC enables flexible permission management. For example, it can fulfill the following two permission scenarios:

First, granting permissions to a user can be done in bulk by assigning a role. For example, if a new colleague joins the company and needs permissions to create, destroy, restart, and log in to virtual machines, these permissions can be abstracted into an operations role. When another new colleague joins, you can simply grant these permissions in bulk by assigning the operations role, instead of granting each permission to the user individually.

Second, modifying a user’s permissions can be done in bulk. For example, if there are many users who belong to the operations role, any changes to the permissions of the operations role will be applied to all the users associated with it, without having to modify each user’s permissions individually.

RBAC is further divided into RBAC0, RBAC1, RBAC2, and RBAC3. RBAC0 is the core model of RBAC, RBAC1 is a role hierarchy model based on RBAC, RBAC2 adds a constraint model to RBAC, and RBAC3 is equivalent to RBAC1 + RBAC2.

Let me provide a detailed description of these four RBAC models.

RBAC0: The basic model that includes the four core elements - users, roles, permissions (objects-operations), and sessions. Users can have a many-to-many relationship with roles, and permissions can also have a many-to-many relationship with roles.

RBAC1: Includes RBAC0 and adds role inheritance. Role inheritance means that a role can inherit from other roles, allowing the role to have additional permissions in addition to the permissions associated with other roles.

RBAC2: Includes RBAC0 and adds constraints. It has the following core features:

Mutual Exclusion Constraint: This includes mutual exclusion of users, roles, and permissions. The same user cannot have mutually exclusive roles, two mutually exclusive roles cannot have the same set of permissions, and mutually exclusive permissions cannot be assigned to the same role. In a session, the same role cannot have mutually exclusive permissions.
Cardinality Constraint: Limits the number of users assigned to a role, indicating how many users can have this role. For example, if a role is specifically created for the company CEO, the number of users with this role will be limited.
Prerequisite Role: To gain higher permissions, one must first have lower-level permissions. For example, one must have the deputy general manager’s permission to have the general manager’s permission.
Static Separation of Duty: Users cannot be assigned conflicting roles simultaneously.
Dynamic Separation of Duty: In a user session, conflicting roles cannot be activated simultaneously.

RBAC3: The full-fledged RBAC that combines RBAC0, RBAC1, and RBAC2.

Moreover, RBAC can easily simulate the effects of DAC and MAC.

Here’s an example to help you understand RBAC. Let’s say we have permissions for “write article” and “manage article”:

    Permission:
        - Name: write_article
          - Effect: "allow"
          - Action: ["Create", "Update", "Read"]
          - Object: ["Article"]
        - Name: manage_article
          - Effect: "allow"
          - Action: ["Delete", "Read"]
          - Object: ["Article"]

Meanwhile, we also have three roles: Writer, Manager, and CEO. The Writer role has the write_article permission, the Manager role has the manage_article permission, and the CEO role has all permissions:

Role:
    - Name: Writer
      Permissions:
        - write_article
    - Name: Manager
      Permissions:
        - manage_article
    - Name: CEO
      Permissions:
        - write_article
        - manage_article

Next, we grant the Writer role to the user Colin:

Subject: Colin
Roles:
    - Writer

Now Colin has all the permissions of the Writer role, which includes the write_article permission, allowing Colin to create articles.

Next, we grant the Writer and Manager roles to the user James:

Subject: James
Roles:
    - Writer
    - Manager

Now James has all the permissions of both the Writer and Manager roles, which includes the write_article and manage_article permissions. These permissions allow James to create and delete articles.

The most powerful permission model: Attribute-Based Access Control (ABAC) #

ABAC (Attribute-Based Access Control) specifies which attributes of users can perform which operations on resources with certain attributes under certain conditions. Compared to RBAC, ABAC provides a finer-grained control over permissions, mainly defining the following four types of attributes:

User attributes, such as gender, age, and occupation.
Resource attributes, such as creation time and location.
Action attributes, such as create and update.
Contextual attributes, such as source IP and current time.

Here is an ABAC policy:

Subject:
    Name: Colin
    Department: Product
    Role: Writer
Action:
    - create
    - update
Resource:
    Type: Article
    Tag:
        - technology
        - software
    Mode:
        - draft
Contextual:
    IP: 10.0.0.10

The above policy means that Colin, as a Writer in the Product department, can create and update draft articles with the tags “technology” and “software”, provided the source IP is 10.0.0.10.

A side note: ABAC is sometimes referred to as PBAC (Policy-Based Access Control) or CBAC (Claims-Based Access Control).

Here, I will help you understand the ABAC permission model using a real-world ABAC authorization policy. Here is a Tencent Cloud CAM policy, which is also an ABAC authorization model:

{
  "version": "2.0",
  "statement": [
    {
      "effect": "allow",
      "action": [
        "cos:List*",
        "cos:Get*",
        "cos:Head*",
        "cos:OptionsObject"
      ],
      "resource": "qcs::cos:ap-shanghai:uid/1250000000:Bucket1-1250000000/dir1/*",
      "condition": {
        "ip_equal": {
          "qcs:ip": [
            "10.217.182.3/24",
            "111.21.33.72/24"
          ]
        }
      }
    }
  ]
}

The above authorization policy states that users can only make calls to cloud APIs (cos:List*, cos:Get*, cos:Head*, cos:OptionsObject) on files within the dir1 directory under the 1250000000 user, if they are in the IP range of 10.217.182.3/24 or 111.21.33.72/24.

In this case, the ABAC defines the following four types of attributes:

User attributes: The user is 1250000000.
Resource attributes: The files in the dir1 directory.
Action attributes: Read operations (cos:List*, cos:Get*, cos:Head*, cos:OptionsObject are all read APIs).
Contextual attributes: The IP range of 10.217.182.3/24 or 111.21.33.72/24.

In the previous section, I introduced the relevant knowledge about permission models. But if you are asked to implement a permission system, you may not know where to start.

Here, I list some excellent open source projects on GitHub that you can learn from. You can study how these projects implement a permission model and develop a permission system that meets your business needs based on these projects.

Casbin #

Casbin is an access control framework written in Go. It is powerful and supports various access models such as ACL, RBAC, and ABAC. Many excellent permission management systems are built based on Casbin. Casbin’s core functionality is built around access control and does not handle identity verification. If your boss asks you to implement a permission management system in the future, Casbin is definitely an open source project that you should study.

keto #

keto is a cloud-native access control service that provides authorization through a REST API. It supports RBAC, ABAC, ACL, AWS IAM policies, Kubernetes Roles, and other permission models. It can solve problems like:

Can certain users modify this blog post?
Can a service print this document?
Can members of the ACME organization modify data in their tenants?
Can a request from IP 10.0.0.2 execute a job from 4:00 PM to 5:00 PM on Monday?

go-admin #

go-admin is a front-end and back-end separated permission management system scaffold based on Gin + Vue + Element UI. Its access control model adopts Casbin’s RBAC access control model. It is powerful and includes the following features:

Basic user management functionality
JWT authentication
Code generator
RBAC permission control
Form builder
…

This project also supports RESTful API design specifications, Swagger documentation, and the GORM library. go-admin is not only an excellent permission management system but also a powerful and fully-featured Go open source project. You can refer to its construction ideas when doing project development. go-admin management system comes with a front-end, as shown in the image below.

go-admin screenshot

LyricTian/gin-admin #

gin-admin is similar to go-admin. It is a permission management scaffold implemented based on Gin + Gorm + Casbin + Wire and comes with a front-end. It is also worth referring to when researching permission management systems.

gin-admin extensively utilizes commonly used technologies in Go backend development, such as Gin, GORM, JWT authentication, RESTful API, Logrus logging package, Swagger documentation, and more. Therefore, when you are doing Go backend service development, you can learn the construction methods of this project.

gin-vue-admin #

gin-vue-admin is a full-stack, front-end and back-end separated, backend management system developed based on Gin and Vue. It integrates JWT authentication, dynamic routing, dynamic menus, Casbin authentication, form generator, code generator, and other features. gin-vue-admin integrates RBAC permission management model. The interface is shown in the image below.

gin-vue-admin screenshot

Recommendation #

After introducing so many excellent open source projects, I want to give you some recommendations. If you want to study how ACL, RBAC, ABAC, and other permission models are implemented, I highly recommend studying the Casbin project. Casbin currently has nearly ten thousand GitHub stars and is in active development. Many projects use Casbin, such as go-admin, gin-admin, gin-vue-admin, and more.

keto is similar to Casbin and provides authorization capabilities through Go packages. keto is also an excellent permission-related project. After studying Casbin, if you want to study other authorization-related projects, I recommend reading the source code of keto.

go-admin, gin-vue-admin, and gin-admin are all Go projects based on Casbin. Among them, gin-vue-admin is a backend management system framework that includes an RBAC permission management module. go-admin and gin-admin are both RBAC permission management scaffolds. So, if you are looking for a relatively complete RBAC authorization system (with front-end and back-end), I recommend studying go-admin first. If you have the energy, you can also study gin-admin and gin-vue-admin.

Summary #

In this lesson, I introduced 5 common permission models. Among them, ACL is the simplest, ABAC is the most complex but also the most powerful and flexible. RBAC is somewhere in between. For some cloud computing providers, such as Tencent Cloud, Alibaba Cloud, and AWS, they face complex authorization scenarios and therefore adopt the ABAC model.

If your resource authorization requirements are not complex, you can consider RBAC. If you need a resource authorization system that can meet complex scenarios, it is recommended to choose ABAC. The design ideas of ABAC can be referred to Tencent Cloud’s CAM, Alibaba Cloud’s RAM, and AWS’s IAM.

In addition, if you want to have a deep understanding of how permission models are implemented, I recommend you to read the source code of Casbin.

Practice Questions #

Think about which permission model to choose to build an authorization middleware system for a company, in order to meet the different needs of different business scenarios.
Think about how to integrate the authorization process into a unified access layer, such as an API gateway.

Feel free to leave a message in the comment section to discuss and exchange ideas. See you in the next lecture.