Also talk about permission management-Introduction

Permission. However, if there is almost no need to use the application software, it is so late that I have to carefully sort out this idea.

I did some homework yesterday:
1. I searched online related documents.
2. glanced at JAAS Materials
3. Aimed at the same acegi security document

The overall feeling is that it is a technical aspect, and the combination with applications is not very close.

I tried to sort out the ideas in this area. It was messy and I was not clear at the moment. I made a mind chart and put it here first: Mind.

In general, I want to view the permission from the application perspective and implementation perspective:

1. What is the definition of permission, its category and boundaries?
What is the relationship between permissions and business logic? Will the two overlap?
What is the relationship between workflows, workflows, and permissions that are often used in application development?

2. Permission Data Management
Permission description can be abstracted as who, what, how, who, what object, and what operations can be performed.
In terms of data description, there are different methods. However, no matter how it is processed, we can divide the involved data into two categories.
The first type can be called "definition data". It mainly includes: What objects are in the system and what operations are performed on each object. This type of data is generally managed by developers or deployers. If the demand does not change, it does not change.
The second type can be called "authorized data", which can include the permissions of the owner or the subject. This type of data often changes during system operation. The changes do not require the participation of developers and deployment personnel, but are generally completed by the user's system administrator.
Because of the frequency of the two types of data changes and the different owners of data management, the data management needs are different.
For "definition data", it focuses on ensuring the flexibility and configurability of permission management, ensuring that users' permission management needs can be met, and considering foreseeable permission management changes, provide reasonable data interfaces.
For "authorized data", the focus is on clear logic and simple operations. Permissions must be described from the business perspective. The permission judgment logic is clear and easy to understand. Common personnel adjustments and permission settings do not cause a large amount of data operations (manual operations ).
How are the two types of data described separately?
What are the boundaries between the two types of data?

Program= Data Structure +Algorithm
In terms of permission management, what information should be stored in the data, which information can be solidified in the program, and is there a certain rule to follow?

Divergence.
Considering the concept of EJB, the development and deployment are clearly divided into two stages. Deployment is not limited to configuring server ports and database connection pools. The frontend calls the background service through an interface-oriented method, and the specific implementation of the background service completes the configuration through the deployment environment. That is to say, during deployment, each module is assembled into a complete system. Spring and Other lightweight frameworks are consistent with EJB in this regard.
This has an impact on the development process and development mode. We need to consider which ones should be handed over to developers and which ones should be handed over to deployment engineers. (Of course, it is also an option not to consider)

3. Domain models and best practices
Permission management needs to be considered by a system. On the other hand, permission management needs vary for each system.
In this way, can we find some common fields and provide different best practices for different fields?
From the design perspective, it provides different reuse levels at different levels.

Continue with your homework.
To learn from Mr. Ma weidu, stick to it.
PS:
Yesterday, I briefly read the acegi security document and provided two methods to intercept requests and perform permission verification. One is filter, and the other is method-level AOP interception. It feels reasonable and is suitable for permission control needs of different granularities to select different interception methods. However, in a specific project, which logic is used as the permission still exists, which is a best practice issue. Continue with your homework and read the documents.