Some of the ideas and thinking of design rights

Author: Cross
my.oschina.net/cloudcross/blog/1920706

Positioning of this article, a framework is not propaganda, it is just sort out what some of the aspects of the process of exploring some ideas about permissions and recent projects. We mainly want to solve some problems.

  • What are the rights, privileges and rights of programmers understand customer understanding is not the same.
  • The principle of division of authority, authority in the end is a combination of what principles.
  • Role is necessary for the relationship between the user and permissions? To undertake a role in the end what role.
  • How reasonable table design.
  • Security framework.

1. What is the authority

Many are not clear with the developers Ye Hao, Ye Hao with customers, the communication process we mentioned permission many times, but the specific rights of each person's understanding of the meaning of meaning, this can easily lead to information asymmetry, some people just the authority understood as a page is accessible, but some people have interpreted as something else. So we want to really define what authority Yes.

Property rights in the end is a noun or a verb attribute, or a noun, verb property are included, which is important for the meaning of authority. If the attribute is a noun, then it should be a specific referents; if it is a verb, it should have a behavior expressed.

  • Term property rights: api interface page, function points.
  • Verbs property rights: operational, non-operational.

So we are now, in fact, authority is a noun, a verb attribute, it must be expressed two meanings. I.e. the control target of the operation.

For example: A permission represents access page A's.
For example: B represents a permission to access the page B, and the function can not be used within a page b
example: Permissions C C represents the interface can not be invoked.
For example: D represents permission to access the page D, and D interfaces accessible.

So further illustration, ** permission to represent a collection of individual control objects may also represent a collection of a plurality of control objects. ** This is a trade-off between the two designers have decided.
Here Insert Picture Description
Sentence summary permission meaning: what (number of elements) were how (number of operations)

2. The principle of classification authority

After we learned about the meaning of authority, the next problem is to use, how to use our authority, how the operating elements of the system are a combination, I learn from this online article to explain. It can be divided in accordance with the principle of "least privilege" and "data abstract principles."

Principle of Least Privilege

1, let me give a counter-example, I put all the system elements and operations are combined into a permission. A user has the privilege quite have all the functions of the system, in fact, it certainly does not work, the user must have the content he was not allowed to operate in a single system, even if it is an element of a super administrator there may be inoperable , then it is not feasible to maximize authority, because they do not meet the common sense.

2. Accordingly, we put the rights then a split, split by business module, but which in fact is not acceptable. For example, on the system's financial module, the module contains assume reimbursed page and page declaration, if the splits on the module, then there must be simultaneous users contains two mutually exclusive functions.

3, according to 1 and 2, we need to be minimized in accordance with the division of authority. But this is questionable, because of the different systems, the smallest division of authority to the functionality provided, the division angles are different.

Principle of data abstraction

1, "least privilege divide" has determined that the object of control from a certain extent, and the data is determined abstract principle is operating.

2, data abstraction from the literal meaning, in fact, difficult to understand in the end what it meant. Usually we say that most of the verbal additions and deletions to check CRUD is changed, which is actually kind of data abstraction, we can understand the meaning of the operating license to the elements.

3, but the CRUD not all data abstraction, additions and deletions to change search for a single entity, is basically no problem, but on building relationships, in fact, is not enough , for example, appointment of a manager under the jurisdiction of a department, from the surface of business For it modify the jurisdiction of the manager. But the code from the ground up on it, it belongs among managers and department added a relation, so based on the needs we need to add a extra class license "dismissal permit", this type of expansion is required in accordance with the actual system business conditions divided.

"Least privilege" and "Abstract Data", respectively, and determines the target operating authority control, but there is an angle worse, it is very common at this stage the front and rear end of the separation problem of division of authority.

End of service permissions

  1. The front and rear ends of the server separation, but in essence provides an interface resources and services of other service providers or services rpc.

  2. Authentication mechanism of the server object is to provide permissions: Service Interface (API services or other forms) not including the end point of pages or page function.

  3. And authentication control page elements or the distal end of movement is substantially controlled not by the server.

  4. The server can service individual rights of control.

  5. Server provides services to front-end, mobile terminal, a third-party client, the service provider is the interface service.

The case has been separated from the rear end of the front end to the front end service provider in terms of just the interface, but no right to interfere shows the front page, the server to the front end, it can provide an interface only authentication services only, but column configuration menu or function points within pages constituting a page, the page is completed by a separate distal end.

Or distal end movement authority

  1. Whether the authentication of the front page that contains accessible, and a function button on the page can be operated.

  2. And moving the distal end of service for the users, the service is provided by visual page.

Here Insert Picture Description

After the division of responsibilities before and after the end of the service object clearly, we will not issue permission of mixed ownership, in the case of the past did not separate the front and rear ends, the page itself is one of the service side, there is no problem in this regard. Although it distinguishes the case of services provided at each end of the essence, but before and after the end of the separation of the division of authority still has new problems.

1, because of inconsistent authentication server and the front end of the object, the server can authenticate to the api interface, whether api connector and the front page and the page binding function points relational database tables and table level.

2, if the relationship is bound between the table and the table, then the amount of maintenance the entire system of privileges, whether in the affordable range of energy.

3, if not binding relationship between the table and the table, the front page at the time of operational functions, how the server authentication page called api whether the user interfaces within the operational purview?

In fact, the above problem is the need for a trade-off, or increase the cost of operation and maintenance strictly control the relationship between the front-end calls api interface, interface service authentication emphasis on the service side. Either to api connector and the front page and then provide the logic function points to determine the continuity of a process, such as: page calls and function point part of the operating license of a service module, and the page trigger interface also happens to be the service module operating license, authorization by, or authentication failure. This is focused on the front end part of the user's control, weakening the interface level control.

3. The relationship between the roles and permissions

通过1,2的描述,基本确定了权限的定义和划分一个权限的通用法则。用户在系统中最终是通过权限来使用各种功能点,是否有必要在用户和权限中间再额外的附加一个关系。在我们现在的权限设计中,是增加了这样一层关系的,就是角色。

1、**减少操作层面的重复性。**角色其实就是一组权限的集合,是权限集合的更高级抽象,为了便于运维和实际管理,通过角色的赋予,替代了权限赋予用户的繁琐性,在一套系统中,普遍情况都是权限的数量多于角色的数量。

2、**权限是控制对象和操作集合,它本身不存在任何状态,但是在赋予在用户身上则拥有了状态。**比如权限A中允许用户访问页面A,权限B允许用户访问页面B,权限D运行用户访问B页面,但是不允许访问A页面。那么这层关系的维护在角色层面的话,会更加清晰,也就是说本身角色具有权限集合组装的策略问题,对于互斥的权限有不同的方案处理。(权限中没有某个操作和权限中禁止某个操作,是两个不同的角度,不能混为一谈)

3、**因为权限的可能存在互斥性,在实际业务中也会引发角色的互斥性。**举一个现实中的案例来解释互斥性:张三是软件部的负责人但因为工作的特殊性也同样隶属于业务部的普通员工,我们设定负责人是可以要求人事部门给本部门进行招聘的,在实际的情况中,张三能给软件部招聘新员工,但是不能给业务部招聘员工。我们把这个案例运用在系统中,张三则是拥有负责人和普通员工两个角色,但是招聘的功能如果不加以控制,则会发生张三给业务部招人的结果。于是为了解决角色的这类问题,引入了职责划分的方案。

4、**职责划分分为:静态、动态。**所谓静态职责划分则是在角色创建之初就已经确定了角色的职责内容。动态职责划分是系统运行过程中对用户已有的角色进行控制,例如:某些角色不能共存在用户身上(互斥)、角色或角色的分配数量限定(控制用量)、角色与角色同时只能激活一个进行使用(时刻唯一)。

引入角色的概念后,实际上这已经是一个比较完整的RBAC的权限设计的模型了。
Here Insert Picture Description

4.数据表的设计思路

根据3的结论,实质上已经有了一个基础的表设计的雏形。在这里就有一些值得注意的点。

问:权限表是否有必要存在?

答:这个要结合系统的实际使用场景进行考虑,如果系统中的权限的对象很单一,比如只有页面,或者只有api接口的话,其实权限表可有可无。增加权限表反而会导致初始化项目权限的工作量增加。但是若系统中的权限对象是多个,那么权限表的存在就有了更深层次的意义。在权限对象是多个的情况,权限表的存在就是为了更好更抽象的组合“最小特权”及“责任划分”的操作对象。同时,一旦系统中的操作对象增加了,只需要给权限表增加一个对象表和关系表就可以了。这样易于扩展。

问:api接口和页面实际上是没有关系的,但是在鉴权活动是有关系的,页面若和api没有一点绑定联系的话,服务端接口调用的时候则要么拦截掉所有指定的接口(页面和api接口没绑定的话,则页面的接口调用都不能成功),服务端接口完全不拦截接口,也会不安全,但是api接口和页面功能在表结构层面的绑定会产生运维的大量工作成本,如何更好的设计?

答:在权限如何划分中已经提过了这一点,在表结构中,我们可以增加一张业务模块表和操作表(也可以在数据字典表中增加这两类数据),我们可以在页面和功能点钟 绑定业务模块和操作表关系,在api接口的代码层面去绑定业务模块和操作,在逻辑上绑定关系,解耦表结构之间的关系,那么可以在一定程度上解决这一点,这样做只会出现一种问题,那就是用户访问页面的时候可调用的api接口会比实际可调用的接口数要多,但是前端权限管理会隐藏功能点,这样就在可视化的程度上解决了这个问题。

5.安全框架

Since we are based RBAC permissions under design, existing java framework is the most common shiro and Spring Security. This is the two eyes of the beholder wise see wisdom, I have both practical too. Recommended only shiro, you can better understand the design idea of ​​RBAC, Spring Security is also a good framework, but it comes to the concept too much, is not conducive to beginners to understand the most basic rights design. I only go in a learning perspective comparing the two frameworks, and then in other areas do not compare, not to compare.

Article cited
https://blog.csdn.net/yangwenxue_admin/article/details/73936803

Guess you like

Origin blog.csdn.net/qq_40914991/article/details/91404207