A miscellany of permission design

The purpose of this article is not to promote a framework, but simply to comb through some of the ideas and explorations in recent projects regarding permissions. We mainly want to solve problems.

  1. What are permissions, and are the permissions understood by programmers the same as the permissions understood by customers?
  2. The division principle of permissions and the combination principle of permissions.
  3. Are roles a necessary relationship between users and permissions? What role does the character fulfill?
  4. How to make a reasonable table design.
  5. Security framework.

1. What are permissions

In many and developers, with the customer, in the process of communication we mentioned many times, but the permissions specific meaning everyone don’t understand the meaning of the clear, so it is easy to cause the information asymmetry, some people just put the permissions as a page is accessible, but some people understand into something else. So we’re going to define exactly what permissions are.

It is very important for the meaning of permission whether it is a noun attribute or a verb attribute, or whether it includes both noun and verb attributes. If it’s a noun attribute, it should have a specific referent; If it is a verb, it should have an action representation.

  • Noun attributes of permissions: API interface, page, function point.
  • Verb attributes of permissions: operable and unoperable.

Now, permissions are noun and verb attributes, which must mean two things. That is, the object and operation of control.

  1. For example, permission A indicates that page A is accessible.
  2. For example, permission B indicates that page B is accessible and page B is unavailable
  3. For example, permission C indicates that interface C cannot be called.
  4. For example, permission D indicates that page D and interface D are accessible.

To further clarify, permissions can represent the set of operations on a single controlled object, or they can represent the set of operations on multiple controlled objects. The choice between the two is up to the designer.

Content of permissions

The meaning of permissions is summed up in one sentence: What (elements) do how (operations)

2. Permission division principle

After we understand the specific meaning of permissions, the next question is how to use permissions, how to combine operation elements in the system, which I refer to an article on the Internet to explain. The partitioning principle can follow the “least privilege principle” and “data abstraction principle”.

  • Principle of least privilege
  1. As a counter example, I combine all the elements and operations in the system into one permission. A user with this permission has all the functions of the system. In fact, this is definitely not possible. The user must have some content in a system that he is not allowed to operate.
  2. Based on this, we split the permissions again, by business module, but this is not actually possible. For example, the financial module in the system, assuming that the module contains the reimbursement page and declaration page, if divided according to the module, then there must be users with two mutually exclusive functions.
  3. According to 1 and 2, we need to divide the permissions according to the minimum. But this is also open to debate, because different systems, the smallest division of authority for the functionality provided can be divided from a different perspective.
  • Data abstraction principle
  1. The “least privilege division” determines, to some extent, what you control, whereas the data abstraction principle determines what you do.
  2. It’s hard to understand what data abstraction means when taken literally. Most often we pay lip service to CRUD, which is really a form of data abstraction that we can understand as permission to operate on elements.
  3. CRUD, however, is not the whole of data abstraction. It is basically ok to add, delete, and review a single entity, but it is not enough to build a relationship. For example, to appoint or remove a manager to manage a department, it changes the manager’s jurisdiction from the business surface. However, from the perspective of the underlying code construction, it adds a new relationship between the manager and the department, so according to the demand, we need to add an additional kind of permission right “appointment and removal permission”, and this type of expansion needs to be divided according to the actual business situation of the system.

“Minimum privilege” and “data abstraction” respectively determine the objects and operations to be controlled in the permissions, but there is a missing Angle, which is very common at the present stage of the separation of permissions.

  • Server side permissions
  1. The server separated from the front and back ends is essentially a service provider providing interfaces or RPC services and other resource services.
  2. Object of the authentication mechanism that the server can provide: Interface services (apis or other forms of services) do not contain front-end pages or function points in the page.
  3. Control and authentication of page elements on the front-end or mobile end is essentially not controlled by the server.
  4. The server can control the service permissions independently.
  5. The service object of the server is the front-end, mobile terminal, and third-party client, and the service is interface service.

In front and back side have separate cases, just for the front interface of a service provider, but have no right to interfere in the front page, the server for the front end, is only authentication service interfaces can provide, but the structure of the page, column menu of the page or pages within the function point of the composition of all by the front alone.

  • Front-end or mobile permissions
  1. Front-end authentication includes the accessibility of the page and whether a certain function button on the page can be operated.
  2. The service object of the front end and mobile end is the user, and the service provided is the visual page.

After the responsibility division of the service object of the front and back end is clear, we will not mix the problem of attribution of permissions, in the past, the front and back end did not separate the case, the page itself is the integration of the server, there is no problem in this respect. Although the delineation of the services provided by each end is clear, there are new problems with the separation of permissions between the front and back ends.

  1. Because the authentication objects of the server and the front-end are different, the server can only authenticate the API interface. Therefore, whether to bind the DATABASE table and surface between the API interface and the front-end page or even the function points of the page?
  2. If the binding relationship between the table and the table is carried out, then the maintenance of the whole permission system, whether it can bear the scope.
  3. If there is no binding relationship between tables, how does the server verify that the API interface invoked by the page is within the user’s permission when the front-end page operates functions?

In fact, the above problem requires a trade-off: increase the operation and maintenance cost, strictly control the relationship between front-end API interfaces, and pay more attention to interface service authentication on the server side. For example, the function point of the page and call belongs to the operation permission of a service module, and the interface triggered by the page also happens to be the operation permission of the service module. Then the authentication succeeds. Otherwise, the authentication fails. This is to focus on the front-end control for the user, weaken the interface level control.

3. Relationship between roles and rights

Through the description of 1,2, the definition of permission and the general rule of dividing a permission are basically determined. Users in the system ultimately use various function points through permissions, whether it is necessary to add an additional relationship between users and permissions. In our current permission design, we have added such a layer of relationship, which is the role.

  1. Reduce repeatability at the operational level. A role is actually a set of permissions, which is a higher-level abstraction of permissions. To facilitate operation and actual management, the complexity of permissions assigned to users is replaced by roles. In a system, it is common for the number of permissions to exceed the number of roles.
  2. A permission is A collection of control objects and operations. It does not have any state by itself, but it has A state on the user. For example, permission A allows the user to access page A, permission B allows the user to access page B, and permission D allows the user to access page B, but does not allow the user to access page A. Then the maintenance of this relationship will be more clear at the role level, that is to say, the role itself has the policy of permission set assembly, and there are different schemes to deal with mutually exclusive permissions. (There is no operation in a permission and there is no operation in a permission, which are two different angles and cannot be confused.)
  3. Because privileges may be mutually exclusive, roles may also be mutually exclusive in real services. Take a real case to explain the mutual exclusion: Zhang SAN is the person in charge of the software Department, but due to the particularity of the work, he is also subordinate to the ordinary employees of the business department. We set the person in charge to ask the personnel department to recruit for the department. In actual situation, Zhang SAN can recruit new employees for the software Department, but not for the business department. We apply this case to the system. Zhang SAN has two roles: the person in charge and the ordinary employee, but if the recruitment function is not controlled, it will result in Zhang SAN recruiting for the business department. So in order to solve the role of this kind of problem, the introduction of responsibility division scheme.
  4. Responsibilities are divided into static and dynamic. Static responsibility division is defined at the beginning of a role’s creation. Dynamic responsibility division is to control the existing roles of users during system operation. For example, some roles cannot coexist with users (mutually exclusive), roles or the number of roles assigned to users is limited (control amount), and only one role and one role can be activated for use at the same time (unique at any time).

With the introduction of roles, this is actually a fairly complete model of RBAC’s permission design.

4. Design ideas of data tables

According to conclusion 3, there is essentially a rudimentary form of table design. There are a few points worth noting here.

  • (1) Q: Is it necessary for the permission table to exist?
  • (1) Answer: This should be considered in combination with the actual use scenario of the system. If the object of permissions in the system is very single, such as only pages, or only API interfaces, in fact, the permission table is dispensable. Adding a permission table can actually cause more work to initialize project permissions. However, if there are multiple permission objects in the system, the existence of the permission table takes on a deeper meaning. In the case of multiple permission objects, the existence of permission table is to better and more abstract combination of “minimum privilege” and “responsibility division” operation objects. At the same time, once the operation object in the system is increased, only need to add an object table and a relational table to the permission table. This is easy to scale.
  • (2) Q: API interface and the page is actually has nothing to do, but there is a relationship in authentication activities, page if no binding and API connection, the server interface call while either blocking out all the specified interface (page not binding and API interface, the interface of the page calls can success), the server interface not intercept interface, It is not secure, but the binding of API interface and page function at the table structure level will incur a lot of work cost of operation and maintenance, how to better design.
  • (2) Answer: In how permissions division already mentioned this, in the table structure, we can add a business module table and operating table (can also increase the two types of data in the data dictionary tables), we can bind the business module and function o ‘clock on the page and operating table relationships, the API interface to bind the business module and code level operation, binding on the logical relationship, Decoupling the relationship between the table structure, then can solve this, to a certain extent, doing so will only be a problem, that is, when the user to access the page can call API interface will be more than the actual number can call interface, but front permissions management will hide the function point, thus solved the problem in the visualization of the degree.

5. Security framework

Since our design is based on RBAC permissions, the most common current Java frameworks are Shiro and Spring Security. Those two are in the eye of the beholder, and I’ve used both. Shiro alone is recommended for a better understanding of RBAC design. Spring Security is also a good framework, but it involves too many concepts for beginners to understand basic permission design. I only compare these two frameworks in the perspective of learning, not in other fields, nor to compare.

Article cited

Overview of authority Systems and the RBAC Model