The design of authority system is almost a necessary module for every system. Recently, I have some experience in the design of authority system. I have encountered some pits and have some thoughts, so I want to write down and share with you.

The purpose of this article is to help you understand some basic concepts in permission design and provide common permission system design ideas.

First, we present an example that allows the reader to think about how to meet this requirement if they were designing their own permission system.

Requirement Description:

In a university, there are many people. The students are about to take their final exams. For a final exam paper, there are the following permission management requirements:

  • Teachers of the course will be able to look at the test papers throughout the course
  • During the exam, the proctor of the course can look at the paper
  • During the exam, students in the course can view and write their own papers
  • After the exam, the teacher of the course can write the exam paper
  • After the examination, the academic director of that grade can view the papers for all the courses in that grade
  • During the whole process, the cleaning aunt cannot view/write the examination paper
  • During the whole process, the principal can view any paper

Note: The examination process is divided into before, during and after the examination. One person may have more than one role.

UML diagrams:

Authentication and Authorization

The system permission control can be divided into two parts: authentication and authorization. The two are relatively separate concepts, and separating them can help us better understand the design of permission systems.

Certification Authentication

The so-called certification is to determine whether you are who you are. Colloquially speaking, it is the common “login” step in our system. There are many methods and techniques for this authentication, such as form authentication, HTTP Basic authentication, Cookie-based remember-Me, OAuth2, even fingerprint authentication, etc.

The technical details of various authentication methods will not be discussed in detail in this article, which is not the focus of this article. All the reader needs to know is that the first stage of permission control is authentication, and if authentication passes, the user is logged into the system. As for the follow-up of the various business authority control, does not belong to the certification tube.

Authorization Authorization

Authentication doesn’t care about business permission control, so who does? That’s authorization. This is the focus of this article.

First of all, we need to consider a question: what is the big goal of the permission design of our system? I think it’s a balance between “flexible” and “manageable”. In other words, our permission design should be flexible to respond to changes, including changes in users and business permission requirements. But at the same time, it should be easy to manage so that our permissions are clear enough not to clutter up.

Therefore, based on the above objectives, I believe that the design of permission system should have the following three principles:

Just enough

What is emphasized here is that the permission system should be as simple as possible under the premise of meeting the requirements, and should not be over-designed. For example, for my personal blog site, I only need to have my own user, there is no need to do very complicated permission control.

Moderate granularity

By “granularity” I mean the granularity of permissions. If the granularity of a permission is too coarse, multiple service scenarios will use the same permission, resulting in poor flexibility. If the granularity of permissions is too fine, it will make permissions become more difficult to manage.

Service operations are recommended. One service operation corresponds to one right. The industry also has tools such as DDD (Domain-driven design) to help better compartmentalize the business.

For example, in the above case, although both teachers and students have the operation of “writing into the test paper”, we can actually divide it into “answering questions” and “scoring” by understanding the business.

Is there a one-to-one mapping between apis and business operations? Most business scenarios should be, but there are exceptions. For example, to send wechat circle of friends, you need at people, upload pictures, have really saved their content to send these three operations constitute “send circle of friends” this business, which corresponds to three businesses.

In my practice, it is recommended to use a single permission to access all three apis. Or three permissions, each corresponding to the corresponding API, but with the concept of a “permission group,” add three of them to a permission group, and then actually assign permissions to that permission group. It is not recommended to just control three apis with three permissions.

Use white lists whenever possible

This is one of the well-known safety principles. When we implement the permission system, we should try to use whitelist, not blacklist. For example, only users with XX rights can use XX services. Not: people without XX permission can conduct XX services.

The dominant permission design model

Permission design is not an easy task, but almost all systems need permission design. In fact, there are already some dominant permission design models in the industry. Here are just a few common ones.

ACL

Access control lists (ACLs) are used for simple permission control. Especially in network traffic control that piece is used a lot, rarely used in business systems.

RBAC

Role-based Access Control: Permissions are associated with roles. Users can obtain the permissions of these roles by assigning appropriate roles. It is also the most mainstream authority design model in the industry. RBAC does not do a good job of checking permissions related to “data state”, such as the requirement that “the paper is before the exam, only the teacher can view it”. You need to kill the character yourself and then write the logic check in the code.

ABAC

Attribute-based Access Control (ABAC) is a solution in the industry to solve the above problems. Write a dynamic DSL to determine the state of the data, with some custom syntax for permission control.

ABAC is also sometimes called PBAC (Policy-based Access Control) or CBAC (Claims-Based Access Control). ABAC is typically used in platform-level systems. For example, AWS, Ali Cloud and other “cloud providers”, they have massive resources, roles, need very flexible rights management system.

ABAC is expensive to implement. Management is also complicated.

Example (Aliyun RAM) :

{
    "Version": "1"."Statement":
    [{
        "Effect": "Allow"."Action": ["oss:List*"."oss:Get*"]."Resource": ["acs:oss:*:*:samplebucket"."acs:oss:*:*:samplebucket/*"]."Condition":
        {
            "IpAddress":
            {
                "acs:SourceIp": "42.160.1.0"}}}}]Copy the code

Permission Design Evolution

In keeping with the principle mentioned above that enough is enough, the permissions system should not be over-designed. There are three types of permissions, ranging from simple to complex:

  • Only one administrator is required to manage all content, such as a personal blog site.
  • Only a few users and roles have stable permissions. Works on most systems.
  • There are many users and roles, and the permissions of roles change easily. Platform-level systems such as AWS.

Since the second is applicable to most projects that are developed on a daily basis, it is the second that will be discussed later. For the third, it is recommended to develop a customized permission system based on ABAC.

Distinguish between Access and Validation

Let’s clarify some of the concepts of these two terms:

  • Access: Whether OR not I can call the API, regardless of the data, can be intercepted at the gateway level.
  • Validation: I can Call the API, but I do not have permission for the API. I can write a Validator to validate the API.

Many friends do permission design for the first time, easy to confuse him two, the design of permission may look very confused.

Let’s analyze the case again. Take the business operation of “reading test papers” as an example, we can have an Access called READ_PAPER and assign it to students, teachers, invigilators, educational directors and principals. This means they can call the business API. When entering the Validation logic, we need to check the status of the test paper taken from the database, the corresponding class, the invigilator ID, and other information. Validation verifies that the data is accessible to the current role.

The next article will provide a more specific set of recommended permission designs from the perspective of the front and back end, the granularity of permissions, and the code level.

Next preview: “System authority design – recommended scheme”