In this paper, based on the "4D Permission Management Model", this paper will use the ideas and solutions to the product module design. Dual-use cases associated with permissions in a normal business system: permission management and access control (ie: Access Verification), the summary is designed (deleted).
1. introduction
1.1 Writing
slightly
1.2 project background
slightly
1.3 Terminology and Convention
Security object
Access the controlled object, such as "Report", "Project", etc. The main "business objects" in the system are typical security objects.
Access scenario
An access scenario will provide elements such as "operator", "Operation Object", "Operation Method", "Business Status", "Specific Limits", etc., for access to verification judgment. According to the analysis (see the instructions in the reference document), each access scenario includes at least three must-have:
"Operator", user, role, user group, unit, etc .;
"Operated object", specific business object, such as "report";
"Operation Method", corresponding to the basic operations and business operations of the object operated, depend on "Operation Object".
Access to other elements in the scene, such as "Business Status", "Object", "Valid Term", etc., it is not necessary to meet items in this design, but take care of the design.
System functions
Features of a business system are also accessed. In an access scenario, the entire business system is considered "Operation Object", and each system function has become the "Operation Method" in the scenario, which is easy to unify the model.
Access control
Or access verification, when accessing the scene is accessed, allowing or disabled, different from authority management. See 2. Task overview.
authority management
Or access control management, maintenance management of access rules, different from access control. See 2. Task overview.
1.4 Reference
internal
"4D Permission Management Model"
external
slightly
2. Task overview
There are two main tasks associated with the permissions and "Access Verification" and "Access Control Management":
Access verification
The legitimacy of various access operations (access to system functions, access to system functions) is verified according to the prior defined accessed access license rules. It is a dynamic implementation of access licensing rules.
Access control management
It is mainly to manage the relationship between various factors (visitors, access system functions, access business objects, access business rules, etc.) when the maintenance system is allowed. It is an implementation of static management maintenance of access license rules.
Use case
"Access Verification" and "Access Control Management" are two use cases in the system. The "Access Control Management" is implemented in the permission management module (close to the specific business association of the system, this iteration does not involve), "Access Verification" is implemented in an access control module. Depending on the dependence of data, both the business is independent of each other.
3. Use case analysis
Usage Name: Access Control
Description: Depending on the business requirements and security requirements, access control is permitted or prohibited when accessing the security object in other use cases occurs.
Front conditions: Other use cases are activated to security objects.
Back conditions: no
Basic event stream:
1) Other use cases request access to a security object, and the event stream begins;
2) Verify results according to each element (operator, operation object, operation method, payment, etc.) of the currently visiting scene (operator, operating object, operation method, payment, etc.) to obtain verification results;
3) Perform or disable the current access based on the verification result, the event stream ends.
Optional event stream: slightly.
Deployment constraints:
This use case can be accessed in the physical layer or logic layer where the access control requirements are located.
Activity diagram: Slightly.
Non-functional demand: Time consumption of access verification time and access operation itself is within the same order of time when visiting a single security object.
No problem: no
Description:
4. Object design
4.1 Objects in the case
Boundary object <
>
:no
Control object <
>
That is, the access controller object AccessController is controlled by the object.
Entity object <
>
: That is, a certain security object.
Operation process object <
>
: Abstraction of the flow of the access scene, such as a business operation.
NOTE: Access Controller Object AccessController is the only object that can complete the design in this case, and other objects belong to other use cases, but access control is required to cooperate in design mode.
4.2 Behavior in use
Access verification: All access controller objects, excited by the operational process object (ie, a business operation). Access verification is required to exist in a specific access scenario, which is permitted or prohibited by the atomic operational access.
Permissions logic: When the operation process object triggers an access to multi-object, and therefore in this access scenario, the permission logic is combined according to the security logic or business logic based on security logic or business logic, according to the access verification Or screen selection. Permissions logic operations are excited by the operation process object.
Object Access: Promoted by other use cases or initiated by the entrusting operation process. Object Access requires access to authentication and permission logic.
4.3 Object timing chart
4.4 Class definition
The access control of the security object is accommodated in the use case, which is implemented in the ObjectAccessController class: (see the reference document)
5. Class implementation design
5.1
Secure Object Access Controller ObjectAccessController
Description
Major member Validaterules: Java.util.ArrayList Verification rule array to accommodate different verification rules ValidaterUle, this project contains only ACM verification rule objects --ACMaccessValidate.
Main Method Public Static Bool IsValidate (IOPERATEMETHOD) is used to verify the verification function of access operational legality. The function call class verification rule array verifies one by one, and finally summarizes the judgment.
Verify rule abstract validaterule
Note Main members used to make all verification rules objects have the same call format
Main Method PUBLIC BOOL VALIDATE (IOPERATEMETHOD) Used to verify verification functions for accessing the legitimacy
ACM Verification Rule Class ACMVALIDATERULE
Description Use to implement the main members of accessing verification in accordance with ACM
Main Method Public Override Bool Validate (IOPERATEMETHOD) is used to verify verification functions for accessing the legality of access.
Note: Used to support access control usage, the elements in the access scenario are defined as the standard interface.
Safety object: IsecurityObject
Operator: IOperator
Operation method: IOPERATEMETHOD
Other use cases are inherited here when implementing class design.
5.2 Data Implementation
In this iteration, only ACM verification rules ACMVALIDATERULE needs to be implemented. The principle of ACM is detailed in the reference documentation.
"Access Control Matrix (Rules) Table"
Field Description Field Name Data Types Allow empty data integrity water numbers
id
Int
NOT NULL
PK
Valid code
Intvalid
Int
NOT NULL
DEFAULT "
0
"
Safety object type
Chrsotype
Char (20)
NOT NULL
Security object ID
IntsoID
Int
NOT NULL
Fk
Operator type
Chroprtype
Char (20)
NOT NULL
Operator ID
Intoprid
Int
NOT NULL
Fk
Operation method name
Chrmethod
Char (20)
NOT NULL
Valid until start time
DTMACTIVE
Datetime
NULL
Validity period end time
DTMexpired
Datetime
NULL
Business process status code
INTPROCESSTATE
Int
NULL
Safety object status code
INTSOSTATE
Int
NULL
Description: According to the table record, read the corresponding "effective code", no record (ie, no effect code), for the access prohibition, otherwise the access license.
"Effective code" for expansion
"Valid Start Time", "Validity End Time" is used for future valid period of time limit verification, can be canceled
"Business Process State Code", "Secure Object Status Code" for future business condition permission verification, can be canceled
6. Load Balancing Design
If there is an L security object in the business system, each security object has M Access control operation methods, and N different visits, according to the non-music view: "Access control matrix (rules) table" will have L × M × N records.
It is recommended to establish a 1-to-1 access control table for each secure object, increasing efficiency, balancing load.
...
- END -
Beegee: A Sector Manager I have worked in a product development (actually product manager) telling me that I can leave the project group. Half a year ago, he commissioned me to design the permission management module in his product. So, I used my barren brain to think about some programs. It's hard to see, I support me to achieve my design, of course, I have added a lot of things I don't like. Now, because of some reasons I have to leave this product group, this manager is not ready to make more investment in this module, so I think I can get my thoughts to my blog, It is self-recreation. ^ _ ^, I also hope to help other programmers improve their own design, and they are full of teaching materials! A total of two: 1. "ACM 4D Permission Management Model" 2. "Summary of Permission Management and Access Control" (this article)
Other related original:
Separation Permissions Management and Access Control
"
Talking about the object model and implementation of authority management
