We have developed a system that is bound to face problems of access control, that is, different users have different access, operation and data access. Theory formed permissions control model are: discretionary access control (DAC: Discretionary Access Control), mandatory access control (MAC: Mandatory Access Control), based on the authentication authority attribute (ABAC: Attribute-Based Access Control) and the like. The most commonly developers use is relatively easy to use, is the common RBAC permissions model (Role-Based Access Control), this paper will introduce the permissions model.
A, RBAC permissions model Introduction
RBAC permissions model (Role-Based Access Control) namely: Role Based Access Control. There are several models of key terms:
- User: operator interface and access the system
- Authority: the ability to access an interface or authorized to do the qualifications of an operation
- Role: the user has the same general term for a class of operating authority
Core RBAC permissions model authorization logic is as follows:
- What is the role of a user?
- What a role has privileges?
- Derivation user's permissions by role permissions
Two, RBAC evolutionary process
2.1. User privileges directly associated with
Think of access control, people first thought must be a model user permissions directly associated with, simply put, it is: a user has certain privileges. Figure:
- Joe Smith has the rights to create and remove users, so that he could maintain personnel system
- John Doe has a records management product and sales records management authority, so he may be a business sales
This model is able to clearly express the relationship between users and permissions, simple enough. But there is also a problem:
- Now the user is John Doe, later with the increase in personnel, each user will need to reauthorize
- Or John Doe to leave, we need to recover a variety of privileges for each user
2.2 A user has a role
In the actual business community, users can be classified. For example, for the salary management system, usually classified according to levels: managers, senior engineers, mid-level engineers, junior engineers. User is classified according to certain roles, usually have the same role have the same privileges. After this change, it can be converted for user empowerment empowerment for the role.
- A user has a role
- There is a role more operations (menu) Permissions
- An operating privileges can belong to multiple roles
We can use the lower figure of database design model that describes such a relationship.
2.3 a user one or more roles
But in the actual application system, a user with a role far from meeting the demand. If we want a user both as a sales role, but also temporarily served as vice president role. how should I do it? In order to increase the applicability of the system design, we usually design:
- A user has one or more roles
- A role that contains multiple users
- There are a variety of roles permissions
- A privilege belonging to more than one role
We can use the lower figure of database design model that describes such a relationship.
Second, access to the page with the operating authority
- Page access: all systems are composed of one page, the page re-composition module, whether the user can see this page of the menu, whether to enter the page is called page access.
- Operating authority: any user action, interaction in the operating system needs to have the authority to operate as CRUD like. For example: a button, a hyperlink whether the user can click on, whether permission should see.
To meet this demand, we can put the resources page (menu) and operating resources (button) sub-table storage, as shown above. Both may be put into a table stored inside, with a flag to distinguish a field.
Third, the data permissions
Data authority is better understood, it is what a user can access and data manipulation.
- Generally speaking, the data is determined by the rights organization the user belongs. For example: the production of a production data can only see his own department, the production of two production data can only see his own department; sales department can only look at sales data, the data can not look at the financial sector. The company's general manager can see all the data.
- In the actual business system, data rights tend to be more complex. Very likely sales department can look at the data production sector, in order to determine the sales strategy, plan of arrangement and so on.
So in order to face complex needs, authority control data is typically written by the programmer personalized SQL to limit the scope of the data, rather than to the permission model or Spring Security or shiro to control. Of course, you can go to solve this problem from the perspective of rights or privileges model framework, but limited applicability.
Look forward to your attention
- Bloggers to recommend a series of documents: "Hands touch hands teaches you SpringBoot series chapter 97 section -16"
- This article is reproduced indicate the source (en must not turn only the text): letters Gebo off .