This article is divided into two parts. The first part talks about some basic concepts in the field of permission system design and the use of basic models. The second part talks about some exploration and practice of our Jingdong Northeast Star commercial operating system in complex permission control scenarios, still maintaining I write articles in a no-nonsense style, so let’s get started.
1. Basic concepts
1. Unauthorized access
The purpose of the design of the permission system is to constrain the system users' operations on the system within a legal range. The system user is not necessarily a human, it may be another system. If the operation is not within the legal range , behavior ofultra-authorized access will occur, ultra-authorized access will cause very serious security issues, ranked second among the top ten security risks of web applications by OWASP. Ureroute access is mainly divided into horizontal unauthorized access and Vertical overrideTwo types.
-
Vertical override Vertical override is an illegal increase in authority. For example, there is a system where the page used by ordinary users is xxx.com/user[1] , the page used by the administrator is xxx.com/manager[2], but the backend system does not control permissions. After logging in, we can jump directly to the administrator's page with the token of an ordinary user to do some things. Indescribable things can be simply described with a picture as follows:
That is, the user uses some illegal means to increase his operability range.
-
Horizontal override Horizontal override is mainly caused by the server not judging the ownership of the data. For example, now we log in to a system and enter to view the user ID as 1's detailed information page, the URL of this page is like this: xxx.com/user/1[3], then I made a mistake and changed the last 1 to 2. At this time, because the back-end system did not To determine whether I can view the user with id 2, the data is returned to me.
That is, unauthorized access caused by vulnerabilities in data access design.
From the perspective of server-side design, we can easily see that Vertical override refers to accessing APIs that should not be accessed. Andhorizontal override means accessing data that should not be accessed, which is very important.
2. Authentication
Authentication means that when performing an operation, theauthority system needs to be judged first Whether the user has the authority to perform this operation will also include verification of the ownership of the requested data in some complex scenarios.
2. Classic design model
Before talking about the model, we must first understand the true meaning of permission control: judgingthe requesterisWhether there is a certain operation for requesting data under certain conditions (API) capabilities.
注意黑体的四个词，1、请求者，2、某些条件，3、请求数据，4、操作（API）
Let’s explain them one by one.The requester is generally a user, or it may be a system, or a piece of code. ;Some conditions may be environmental conditions. For example, a certain API only allows access to the IP address 10.122.131.1, or it can only be accessed at night. Access, or this type can only be accessed within the week; Request data is the data required for this request, such as viewing the user with id 1 Specific information; Authentication (api) That is, what is done to this data, whether it is viewing or modifying, note that modification actually also includes deletion.
1、RBAC（Role Based Access Control）
Chinese translation isRole-based access control. This should be the most commonly used permission management and control model in today's IT systems. Use a diagram to illustrate A brief description is as follows:
The picture above is a related scenario of order operations in a simple business scenario.
Role is the aggregation ofoperations (API),RBACBy binding a role to the user, the user is equipped with the ability to perform certain operations. This is the simplest RBAC model, also known as RBAC0 academically, and the corresponding YesRBAC1, RBAC2, RBAC3, RBAC1 introduced role inheritance relationship, role inheritance is easy to understand, that is, role B inherits role A, then when the user binds role B, he will also have the operational capabilities of role A; RBAC2 introduces the role mutual exclusion relationship. For example, if the user binds role A, he cannot bind the role. B, this is because in the real world, if you are an athlete, you cannot be a referee; RBAC3 is a combination of < a i=22>RBAC1 and RBAC2's capabilities, and also have the functions of role mutual exclusion and role inheritance.
In some permission systems, in order to facilitate users, permission groups or < a i=3>The entity model of user group, Permission group is an aggregation of a type of API, such as user operation permissions Groups can include operations for adding, deleting, checking, and modifying user data. When using permission groups, roles are not bound to the API, but to the permission group;User Group is to group a certain type of users. This group is bound to a role instead of a user to a role. In this way, as long as the user joins this group, he or she will have certain operating permissions. In the real world, this Groups may also be entities such as company departments.
We can see that inRBAC, no matter how the entity changes, the role (Role) The essence is actually the aggregation of a series of API operations , through the user and Direct or indirect binding of roles gives users the ability to perform certain operations, which is also the essence of RBAC.
2、ABAC（Attribute Based Access Control）
ABAC translated meansAttribute-based permission access control. This model is commonly used in today’s cloud systems, such as AWS , Alibaba Cloud, Tencent Cloud, JD Cloud, etc., they all use ABAC to control IaaS and PaaS resources. K8s has also used this model for permission control.
As we said above, the capabilities of RBAC can be described in this sentence: a user has some ability to operate on data by binding to a role. To put it simply, a user has some ability to operate on data. However, in complex permission control scenarios, RBAC seems to be somewhat inadequate, such as:
-
Users cannot access the system at night, but can during the day
-
Users can only modify orders on the internal network, but only view them on the external network.
-
Users have operation permissions for orders created before 2021-03-19
-
Users can only check orders in Shenzhen, but not abroad.
-
Users can access all data within the company, but can only access public data externally. We can easily find that RBAC only describes Whatuserscan dooperate, but the operation Conditions, and operationdata, the model itself does not have these restrictions, this is also because It is caused by the lack of its model capabilities, but this is precisely the strength of ABAC. The idea of ABAC is based onusers and those who will visit dynamically calculate whether the user has permission to perform operate. Let’s first briefly introduce some terms in the NIST ABAC design guidelines:environmental factors, and variousData attributes
-
subject refers to the user of the system, which can be a user or other non-person entity (NPE)
-
object generally refers to the accessed data
-
operation/action refers to operation behavior, generally corresponding to the API in the system
-
policy Access policy, which stipulates what a user can do with which data under what conditions. It is one of the core entities of the ABAC system
-
pdp pdp is policy decision point, strategic point. In fact, I understand that this thing is just a display form of policy
-
pep pep is policy enforcement point, which is simply to authenticate based on policy
-
acm acm is access control mechanism, permission control mechanism, generally speaking it is the permission system itself
-
attribute It generally refers to various attributes, which can be subject or object
-
condition Various additional restrictions In the NIST article, the following figure describes the relationship between the above terms:
It is easy to find that ABAC is only limited by the number of attributes that can be used to calculate. This can also easily cause many people to misunderstand and mistakenly believe that ABAC can control any type of permissions. In fact, the permission system is only good at controlling vertical Ultra vires, even if ABAC has a certain ability to control horizontal ultra vires, do not imagine that it can be used to control all horizontal ultra vires.
这一点放在其他方面的系统设计中也是被证明的，那就是从来没有哪个方案亦或者是架构设计能成为无所不能的银弹。
Other models include LBAC, IBAC, NGAC, etc., which will not be introduced here. Readers can learn about them by themselves.
This article only explains the basic concepts. The next article will compare it with existing ABAC systems in the industry and talk about the practice of Jingdong Norstar commercial operating system in ABAC.
Reference article:
1. ABAC - solution to access control in complex scenarios[4]
2. Amazon Cloud AWS permission policy document[5]
3. Alibaba Cloud RAM permission policy document[6]
4. Some guiding thoughts from NIST on ABAC design[7]
5. AWS senior engineer explains ABAC[8]
6. Some guiding thoughts from NIST on NGAC[9]
7. An implementation case of NGAC[10]
8. xacml (IBM’s implementation of ABAC) document [11]