Talking about the object model and implementation of authority management
BEEGEE
2003-7-16)
table of Contents:
1. Analysis of authority management issues
1.1 Principle Analysis of Permissions Management
1.2 Permission Management of E-Government System
1.3 Permission Management of Commercial Application System
1.4 That Mountain Stone
2. Permission management subsystem design
2.1 Overall Targets of Permission Management Subsystem
2.2 Object Model of Permission Management Subsystem
2.3 Note and deficiencies
3. Implementation management subsystem
3.1 Object-oriented implementation
3.2 Component layers and functional layers Packaging objects
3.3 Integration to specific business system
1. Analysis of authority management issues
1.1 Principle Analysis of Permissions Management
Any multi-user system inevitable involves permission issues, the more users of the system, the more complex the social attributes or division of labor itself, the more complex the rights issue. Undoubtedly, whether it is a process system that is supporting complex office political relations, an e-government business system that includes longitudinal administrative relationships or an application integrated system for data business integration, which is inevitable to solve this problem.
The project that our team is driving is a typical multi-service integration system. Simply put, in this system, there is a data center and several specific business systems, each of the specific business systems sharing the data in the data center under the guidance of a logical rule; and there is also a different business system. Data and business calls. In our system architecture design, the data center and these business systems are an intermediate layer that houses the functional interfaces of the data center data operation and the functional interfaces that are called each other.
Permission management requires access to different privileges for different users to different users.
1.2 Permission Management of E-Government System
In the discussion with the company's related artists, I learned that the company's existing office automation or permission management in e-government products is fully able to meet customer requirements. Moreover, in these systems, the designer divides the permissions into functional permissions and resource privileges. Visit users access to system function items and users access to the system (eg, document, notification).
The permissions in these systems are generally based on the customer's needs, and the internal administrative relationships of the analytical service objects are generally divided into several levels, each grade gives different access to the system and resources. . Such user levels are often direct mappings for the administrative relationship between service objects (eg, the length, director).
1.3 Permission Management of Commercial Application System
In the world of IT, there is no lack of application systems that implies permissions management, even an operating system. Thanks to information from the Internet, we learned that the permission management in these more mature systems is implemented through the intermediate objects of the ACL.
ACL, i.e., Access Control List. Chinese translation: Access control column. The principle of ACL works as follows: User, or user group to get its ACL (more than one) through the access control table in the database, the ACL has a permission --Privilege (eg, read-only, reading and writing, etc.), and the ACL Point to an access item, this access item is different from the system where the system is located. Such as: In the operating system, it may be a folder, which may be a database in the relational database management system, and so on. In implementation, the user accesses a specific access item via the ACL and is limited by the permissions attached to the ACL. This allows multiple user access to multi-access items.
1.4 That Mountain Stone
Any design is served on demand. Due to the multi-service unit served in the system in the system, 1.2 The traditional method of the conventional method is established to achieve a lack of flexibility when achieving multidimensional rights management. All, the team decided to use the privilege management principle in combination with the needs of the project to achieve permission management. That is, in our business integration system, ACL management and function module management are used to implement permission management. Below the technology topic: 2. Permission management subsystem design
2.1 Overall Targets of Permission Management Subsystem
Permission management subsystem implements the function of the system's permission management section. With the method of using an example (user case), it can be obtained that the system's rights management subsystem meets three main functions.
A. Get the list of access items
The access item list that is accessible to the user is obtained based on the permission settings that are pre-configured in advance.
B. Access accessible item
When the user accesses an access item list, the permission management subsystem gives permission control, such as: License, not permit, read-only.
C. authority management
Set the access relationship between the user, the user group and the access item, that is, our familiar authority assignment, configuration, etc. At the same time, in this design, "User Group" is used to attribute "users" of the same authority. It can be seen that the user group is an object of objects directly related to authority management, all, users, and user group association management are also an important part of the permission management subscriber.
Figure 1: Example of permission management subsystem
2.2 Object Model of Permission Management Subsystem
Reference "Permission Management Object Model (Briefly)" and "" XXXX (Note: Mask Business Sensitive Character) "Platform Permission Management Subsystem Overview", you can see the production and implementation of object models for this permission management design. Here is a brief description in order to facilitate communication.
Figure 2: Permission management subsystem object model
Object Model Explanation: (Refer to the Noun]
"Function" represents the accessible item in the system, in practical applications, may be the functional interface of the foregoing intermediate layer, or some business resources, such as static reports already generated. The difference can be tagged when implemented.
"ACL" represents an access control column, connects to the user, user group, butction and has a Privilege property.
"Privilege" represents permission, such as: prohibition, read-only, read and write, complete control.
"User / group" user, and user container with the same access attribute - user group. There are many-to-many relationships.
"UserAccess / GroupAccess" access, connect ACL and USER / Group, and bind permissions for it --Privilege
The actual implementation is that the following logic needs to be achieved: that is, when a USER property is multiple groups, the user will make the user get the maximum permissions.
Now we can return to the 1.2 section and see if this design can adapt to the permission related needs of existing e-government systems.
1) You can use the Function object as an abstraction of the "Function Item" and "Resource Item" of the e-government system, you can use the tag to distinguish between "Function Item" and "Resource Item";
2) Use Group to mimic the role in the original system, so that the direct mapping between the original user and the role in the system is changed to the relationship of the group, and can specify different permissions for each group to specify the specific access item --Privilege Access properties make flexible disposal. It is also possible to secure access to the corresponding specific function of each group to the simplified system, and publish it in "role".
As a result, the team determines that the current design can meet the authority association requirements of the ordinary e-government system.
2.3 Note and deficiencies
This design can meet the functional requirements of permission management, but in the face of simple business systems seem much. Also, multiple tables are required to be implemented, along with a large number of management modules. Further, in the system implementation phase, the system is also required to perform software configuration operations. 3. Permission management subsystem
3.1 Object-oriented implementation
In the multi-service integration project of the team, we tried to use the above object model, but in cost consideration, we appropriately simplified the above object models, cancel the direct association of the ACL, uniformly use the Group to group User.
On this basis, we carry out data modeling to implement specific functions of authority management. After completing the modeling, the team also uses object-oriented methods to design and code design for this subsystem. (Please refer to "" "XXXX (Note: Mask Business Sensitive Character)" Platform Permission Management Subsystem Overview ") In the class, all functions of the permission management subsystem are published in the form of these two classes.
image 3:
This part is realized, such as modeling details, code design, "" XXXX (Note: Shielded Business Sensitive Character) "Platform Permission Management Subsystem Overview" and Test Engineering Datacs.
3.2 Component layers and functional layers Packaging objects
The visibility design of the team determined the authority management subsystem should be here. Such permission management subsystems are only a number of documents and several documents that can work with each other and a test demo project. Our reason is that we have completed the construction of the object framework, when implementing the specific functionality of the future (assuming our class is perfect) will be released in a different manner according to the requirements or conditions of the specific project system. Such as: Package Aclmanager and GroupManager into traditional programs available for COM, or more fashionable .NET assemblies, or even Web Service. For teams using Java, we will be willing to re-implement our class with Java with Java with the help of our documentation and package it as EJB, or Web Service.
3.3 Integration to specific business system
It can be seen that the team is not finished on the way of implementing the system's rights management subsystem. The author of this article is the XP software method (extreme programming), I believe that the "plan is not as good". Therefore, when the permission management implementation is implemented, it is necessary to optimize the model for specific requirements, and the improvement is even all pushful!
Subsequential:
This article derived from the experience, knowledge and labor of several colleagues of the company, and I wrote on their respect for their respective interests. Thank you!
