JVMS have been writing to ZGC for a while, but the article has been lost. Unfortunately, JVMS have been suspended for a while and will continue later.

This article is divided into two, after some permission to some basic concepts in the field of system design, and the use of basic model, the next tell us jingdong Polaris business operating system in the complex access control scenario above some exploration and practice, still maintained the style of writing articles I donate said, we just start.

1. Basic Concepts

1. Unauthorized access

The purpose of the permission system is to restrict the operation of system users to a legal range. The user of the system is not necessarily a person, but may also be another system. If the operation is not within the legal range, the unauthorized access will occur, and the unauthorized access will cause very serious security problems. It is ranked second among the top ten Security risks of Web applications by OWASP. Unauthorized access can be divided into horizontal unauthorized access and vertical unauthorized access.

  • Vertical unauthorized

Vertical overreach is an illegal promotion of permissions. For example, there is a system where the common user uses xxx.com/user and the administrator uses xxx.com/manager, but the background system does not control permissions. After logging in, we can jump directly to the administrator’s page with an ordinary user’s token to do some indescribable things, which can be simply described as follows:

That is, the user increases his scope of action by some illegal means

  • The level of unauthorized

Horizontal overreach is mainly caused by the server’s failure to judge the ownership of data. For example, now we log in to a system and enter the page for viewing the details of user ID 1. The url of the page looks like this: xxx.com/user/1, and THEN I screwed up and changed the last 1 to 2, at which point the backend system didn’t decide whether I could view the user with ID 2, so it returned the data to me.

That is, unauthorized access caused by a vulnerability based on data access design.

From a server-side design perspective, it’s easy to see that vertical overreach means access to an API that shouldn’t be accessed, and horizontal overreach means access to data that shouldn’t be accessed, which is important.

2, authentication

Authentication means that when performing an operation, the permission system needs to check whether the user has the permission to perform the operation. In some complicated scenarios, the authentication includes verifying the attribution of the requested data.

Two, classical design model

Before we get to the model, we need to understand what permission control really means: determining whether a requester has the ability to perform certain operations (apis) on the requested data under certain conditions.

Notice the four words in bold: 1 requester, 2 certain conditions, 3 request data, 4 operation (API)Copy the code

Let’s explain it one by one. The requester is usually a user, it could be a system, or it could be a piece of code; Some conditions, perhaps environmental conditions, such as an API that only allows access to the IP address 10.122.131.1, or only at night, or only during the week; Request data is the data required by this request, such as viewing the specific information of the user whose ID is 1. The authentication (API) is what you do to this data, whether you view it or modify it, and notice that modifying it also includes deleting it.

1. RBAC (Role Based Access Control)

Role-based access control, which should be the most widely used permission control model in IT systems today, is simply described in a diagram as follows:

The figure above shows the order operation scenario in a simple business scenario

Roles are the aggregation of operations (apis). RBAC enables users to perform certain operations by binding a role to them. This is the simplest RBAC model, also known as RBAC0 academically, corresponding to RBAC1, RBAC2 and RBAC3. Role inheritance is easy to understand. That is, role B inherits role A. When users are bound to role B, they have the operation ability of role A. RBAC2 introduces the relationship of mutual exclusion of roles. For example, if A user is bound to role A, he cannot be bound to role B. This is because of the business scenario in the real world where an athlete cannot be A referee. RBAC3 combines the capabilities of RBAC1 and RBAC2, and has the functions of role mutual exclusion and role inheritance.

In some permissions system, in order to facilitate the use of the user, also spawned privilege group or entity model of user groups, privilege group is a kind of API polymerization, such as user permissions set operation can include add and check operation instead of user data, access group, characters and API to bind, but go and permissions set binding; A user group is a group of users that is unbound from roles rather than users and roles. In this way, once a user joins a group, he/she has certain operation rights. In the real world, the group may also belong to a company department.

We can see that in RBAC, no matter how the entity changes, the essence of Role is actually the aggregation of a series of API operations. Through the direct or indirect binding between users and roles, users are equipped with certain operation capabilities, which is also the essence of RBAC.

2. Attribute Based Access Control (ABAC)

ABAC translates to attribute-based access control. This model is widely used in today’s cloud systems, such as AWS, Ali Cloud, Tencent Cloud, jingdong Cloud, etc. They all use ABAC to control IaaS and PaaS resources, and K8s has also used this model for access control.

As we mentioned above, the capabilities of RBAC can be described in this sentence: a user has some ability to manipulate data by binding to a role, which simply means that a user has some ability to manipulate data. However, RBAC is inadequate in complex permission control scenarios, such as:

  • Users can’t access the system at night, but they can during the day
  • Users can modify orders only on the Intranet and view orders only on the Internet
  • The user has operation rights for orders created before 2021-03-19
  • Users can only view orders in Shenzhen, but not abroad
  • Users can access all data inside the company, but only public data outside

It is easy to find that RBAC only describes what the user can do, but the operation conditions and operation data are not restricted by the model itself, which is also due to the lack of model capability, but this is exactly the strength of ABAC. The idea of ABAC is to dynamically calculate whether a user has permission to operate based on the user, the attributes of the data to be accessed, and various environmental factors. Let’s start with a brief introduction to some terms in the NIST ABAC design Guidelines:

  • Subject refers to the user of the system, which can be a user or other non-person entity (NPE).
  • Object refers to data that is accessed
  • Operation/Action refers to the operation behavior, which generally corresponds to the API in the system
  • Policy An access policy that specifies what a user can do with which data and under what conditions is one of the core entities of an ABAC system
  • PDP is a policy decision point, and I understand that this is just a presentation of a policy
  • Pep A PEP is a policy enforcement point that authenticates policies
  • Acm The ACM is an access control mechanism
  • Attribute refers to various attributes, which can be of a subject or an object
  • Condition Various additional restrictions

In the NIST article, the following diagram depicts the relationship between the terms above:

It is easy to find that ABAC is only limited by the number of attributes that can be used to calculate, which makes it easy for many people to misunderstand that ABAC can control all types of permissions. In fact, the permission system is only good at controlling vertical overreach. Even though ABAC has certain ability to control horizontal overreach, Nor do you imagine that you can use it to control all horizontal overreach.

This is also proven in other aspects of system design, which is that no solution or architectural design can ever be a silver bullet.Copy the code

Other models include LBAC, IBAC, NGAC, etc., which are not introduced here. Readers can learn about them by themselves

This paper only explains the basic concepts, and the next part will compare with the existing ABAC system in the industry and talk about the practice of JINGdong Polaris commercial operating system in ABAC.

Reference article:

1. ABAC – Access control solution in complex Scenarios

2. Amazon Cloud AWS permission policy document

3. Aliyun RAM permission policy document

4. Some guiding thoughts of NIST on ABAC design

5. AWS senior engineer explains ABAC

6. Some guiding thoughts of NIST on NGAC

7. An implementation case of NGAC

Xacml (IBM’s implementation of ABAC) documentation