How to realize the control function of data authority in application system

Design and Implementation of Authority Management System Based on BASED Model; Management information system is a complex human-computer interaction system, in which every specific link may be threatened by security. It is very important to establish a robust authority management system to ensure the security of management information system. Authority management system is one of the most reusable modules in management information system. Any multi-user system inevitably involves the same authority requirements, and needs to solve security services such as entity authentication, data confidentiality, data integrity, non-repudiation, access control, etc. (according to ISO7498-2). For example, the access control service requires the system to control which resources the operator can access and determine how to operate these resources according to the operation rights set by the operator. At present, the authority management system is also one of the modules with the highest repeated development rate. In an enterprise, different application systems have independent rights management systems. Each set of rights management system only meets the rights management needs of its own system, and may be different in data storage, rights access and rights control mechanism. This inconsistency has the following shortcomings: a. System administrators need to maintain multiple sets of rights management systems and repeat their work. B repeated maintenance of data such as user management and organization cannot guarantee the consistency and integrity of data. C due to different rights management system designs, different concepts and different technologies, it is very difficult to realize single sign-on, and there are also problems in the integration of rights management systems, which also brings difficulties to enterprises in building enterprise portals. It is very necessary to construct a universal, perfect, safe, easy to manage, portable and extensible authority management system by adopting unified safety management design idea, standardized design and advanced technical architecture system, so that the authority management system can truly become the core of authority control and play an important role in maintaining system security. This paper introduces the design and implementation of a privilege management system based on RBAC (Role-based Policy Access Control) model, which is implemented by J2EE architecture technology. It also discusses how to access and control the permissions of the application system. 1 Using J2EE architecture design and J2EE enterprise platform architecture to build a rights management system. J2EE architecture integrates advanced software architecture ideas, and has the characteristics of multi-layer distributed application model, component-based and reusable components, unified and complete model and flexible transaction control. The system is logically divided into four layers: client layer, Web layer, business layer and resource layer. A. The client layer is mainly responsible for human-computer interaction. It can be accessed by the system administrator through a Web browser, and can also provide API and Web service calls of different business systems. B the Web layer encapsulates the services for providing presentation layer logic for clients accessing the system through the web. C. The business layer provides business services, including business data and business logic, and centralizes system business processing. The main business management modules include organization management, user management, resource management, authority management and access control. D. The resource layer is mainly responsible for data storage, organization and management. The resource layer provides two implementations: large relational database (such as ORACLE) and LDAP (Lightweight Directory Access Protocol) directory server (such as Microsoft Active Directory). 2 RBAC model access control is a defensive measure to prevent unauthorized use of resources. The basic goal is to limit the access rights of access subjects (users, processes, services, etc.). ) to access objects (files, systems, etc. ), so that the computer system can be used within the legal scope; Decide what users can do, and also decide what programs that represent some users' interests can do [1]. There are generally three access control strategies in enterprise environment: autonomous access control method, mandatory access control method and role-based access control method (RBAC). Among them, the autonomy is too weak and the compulsion is too strong, and both of them have a large workload, which is inconvenient for management [1]. Role-based access control method is currently recognized as an effective method to solve the unified resource access control of large enterprises. Its two notable features are: 1. Reduce the complexity of authorization management and reduce management overhead; 2. Flexible support for enterprise security strategy, providing great flexibility for enterprise changes. The national institute of standards and technology (NIST) standard RBAC model consists of four component models. These four component models are basic model RBAC0 (core RBAC), role classification model RBAC 1 (hierarchical RBAC), role restriction model RBAC2 (constrained RBAC) and unified model RBAC3 (combined RBAC)[ 1]. A. RBAC0 defines the minimum set of elements that can constitute an RBAC control system. In RBAC, there PRMS five basic data elements: users, roles, objects, operations and permissions. Permissions are granted to roles, not users. When a role is assigned to a user, the user will have the rights contained in the role. A session is a mapping between a user and a set of activated roles. The difference between RBAC0 and traditional access control is that it increases the flexibility brought by a layer of indirection. RBAC 1, RBAC2 and RBAC3 are all extensions of RBAC0. B. RBAC 1 introduces the inheritance relationship between roles, which can be divided into general inheritance relationship and restricted inheritance relationship. The general inheritance relationship only requires that the role inheritance relationship is an absolute partial order relationship, allowing multiple inheritance between roles. The restricted inheritance relationship further requires that the role inheritance relationship is a tree structure. C. RBAC2 model increases the separation of duties. The constraint of RBAC2 specifies the mandatory rules that should be followed when granting permissions to roles, or when granting roles to users, and when users activate roles at a certain moment. Responsibility separation includes static responsibility separation and dynamic responsibility separation. Constraints and user-role-permission relationship jointly determine the access rights of users in RBAC2 model. D. RBAC3 includes RBAC 1 and RBAC2, which not only provides the inheritance relationship between roles, but also provides the separation of responsibilities. 3 Core object model design According to the permission design idea of RBAC model, the core object model of permission management system is established. The basic elements of the object model mainly include: users, groups, roles, objects, access patterns and operators. The main relationships are: assigning role authority PA (authority assignment) and assigning user role UA (user assignment men are described as follows: a. Control object: it is a resource to be protected by the system and an accessible object. The definition of resources needs to pay attention to the following two issues: 1. Resources have hierarchical relationship and inclusion relationship. For example, a web page is a resource, and objects such as buttons and text boxes on a web page are also resources, which are children of web page nodes. If you can access the button, you must be able to access the page. 2. The concept of resources mentioned here refers to resource classes, rather than instances of specific resources. The distinction between resource categories and resource instances, as well as the subdivision of resource granularity, are conducive to determining the management boundary between the rights management system and the application system. The rights management system needs the rights to manage resource categories, while the application system needs the rights to manage specific resource instances. The distinction between the two is mainly based on the following two considerations: on the one hand, the permissions of resource instances often have the relevance of resources. That is to say, according to the relationship between the resource instance and the subject accessing the resource, the instance authority of the resource can be judged. For example, in the management information system, customers in different departments need to be divided according to business areas. Both Area A and Area B have controlled resources to modify customer data, among which "customer files" belong to the category of resources. If it is stipulated that area A can only modify the customer data managed by area A, it is necessary to distinguish the ownership of the data, and the resources here belong to the category of resource instances. Customer files (resources) should have the information of their users (customer data may contain the attributes of business fields), so as to distinguish the instance operations of specific resources and modify the information content under their jurisdiction. On the other hand, the instance permissions of resources often have considerable business logic relevance. For different business logic, it often means completely different principles and strategies for determining permissions. B. Permission: Access rights of protected resource operations are bound to specific resource instances. Accordingly, access policies are related to resource categories, and different resource categories may adopt different access methods. For example, pages have access modes that can be opened or not, buttons have access modes that can be used or not, and text editing boxes have access modes that can be edited or not. There may be exclusion and inclusion relationships in the access policy of the same resource. For example, modifiable access patterns of data sets include queryable access patterns. C. user: the owner or subject of the right. Users and permissions are separated and bound through authorization management. D. user group: a collection of users. In the judgment of business logic, it can be judged based on individual identity or group identity. The system weakens the concept of user groups and mainly realizes the way of users (personal identity). E. Role: the unit and carrier of power distribution. Roles support hierarchical permissions through inheritance relationships. For example, the role of section chief includes both the role of section chief and the roles of different business personnel in the department. F. Operation: complete the binding of resource category and access policy. G. Assign role permissions PA: realize the mapping of association between operations and roles. H. Assign user role UA: realize the association mapping between users and roles. The object model finally transforms the access control model into an access matrix. Rows in the access matrix correspond to users, columns correspond to operations, and each matrix element specifies a corresponding role, which correspondingly grants access rights and implementation behaviors to corresponding targets. According to the rows in the access matrix, it is the content of CL (Accessibility); According to the columns in the access matrix, it is the content of ACL (Access Control List). 4. Right access mechanism Right management system: provides centralized right management services, and is responsible for providing user identification, user information, organizational structure information and calculation of the right relationship table. According to the relationship among users, roles, operations, access policies and control objects, and considering the positive and negative granting of rights, the system calculates the minimum rights of users. In the business logic layer, the service can be implemented by using Session Bean, or it can be published as a Web service. Centralized control of the application system access authority calculation service by proxy, and return the authority relation table, namely the binary group {ObjectId, operated}. Application system: You can access the rights management system through two optional access methods: access ability table CL and access control table ACL. Taking the application system based on J2EE framework as an example, the access process is explained as follows: a. First, form-based authentication is adopted, and the login request is processed centrally by Servlet [2]. Considering that the entity to be authenticated is a user, ACL-based access mode is adopted. When the user logs in, the user authentication service of the rights management system is called. If the verification is successful, the authority calculation service is called, and the authority relation table is returned and stored in the global session of the logged-in user in the form of HashMap. If there is no global session or the session expires, it will be directed to the login page to regain permissions. B. Access control of direct URL resources is based on CL access. If the user directly enters the URL address to access the page, there are two ways to control the access: 1. Control by reading CL from the permission tag; 2. Take the filter mode to control the permissions. If there is no permission, redirect to the login page. 5 The authority control mechanism defines the resource categories to be controlled by the authority according to the requirements of the application system. The semantics and control rules provided by the application system are transparent to the authority management system, and the authority uniformly treats the resources and operations of different application systems. The permission relation table obtained by the application system calling the permission management system also needs to be interpreted by the application system. According to this design, the rights management system is universal, and the control mechanism of rights is handled by the application system. Because the access control of the application system is related to the specific technical environment, taking the application system based on J2EE architecture as an example, the main display component of the system is JSP page, which is realized by tag library and access control component * * *. A. Permission identification: use tags to identify resources at different levels, and page permission tags will identify page objects. B. Permission registration: traverse the permission control label on the JSP page and read the control permission of JSP. Register the rights control objects and rules on JSP pages into the rights management information system through the rights registration component. C. Permission control: when the user of the application system logs into the system, on the one hand, after obtaining the permission relationship table from the permission management system, the permission tag controls the page display; On the other hand, the authority control component is used to control the corresponding authority in the business logic, especially the authority control of the control object instance closely related to the business logic. 6 Rights storage mechanism Rights management system adopts two optional storage mechanisms: LDAP (Lightweight Directory Access Protocol) directory service database and relational database. Store user information, organizational structure, roles, operations, access methods and other information. Among them, the directory service system is based on LDAP standard and has extensive data integration and * * * sharing ability. The metadirectory function allows quick and simple integration with the existing infrastructure of the enterprise, which solves the synchronization problem between traditional RDBMS and LDAP user databases. Conclusion This paper discusses the technical scheme of realizing the rights management system based on RBAC model. The rights management system has been successfully applied in the design and development practice of the system, and has a good integration with the application system. Practice shows that adopting the permission based on RBAC model has the following advantages: the permission distribution is intuitive, easy to understand and easy to use; Good scalability, support the changing needs of posts and permissions; Hierarchical authority applies to hierarchical organizational structure; Strong reusability.