Design and Implementation of a permission management system based on RBAC model

Abstract: A permission management system based on RBAC is designed and implemented. This paper introduces the multi-layer architecture design of the J2EE architecture, expounds the design idea of Role-Based Access Control RBAC model, and discusses the core Object-Oriented Design Model of the permission management system, and key technologies such as permission access, permission control, and permission storage. Key words: permission management system; role; access control; RBAC model; J2EE; LDAP 0 introduction management information system is a complex human-computer interaction system, where each stage may be vulnerable to security threats. It is very important to build a robust permission management system to ensure the security of the management information system. The permission management system is one of the most Reusable Modules in the management information system.
Any multi-user system inevitably involves the same permission requirements, all need to solve entity identification, data confidentiality, data integrity, anti-denial and access control and other security services (according to ISO7498-2 ). For example, the access control service requires the system to control the resources that the operator can access based on the Operation permissions set by the operator and determine how to operate the resources. At present, the permission management system is also one of the modules with the highest repetition rate. In enterprises, different application systems have an independent permission management system. Each permission management system only meets the permission management needs of its own system. This inconsistency may have the following drawbacks:
A. the system administrator must maintain multiple permission management systems.
B. Duplicate data maintenance for user management and organization, and data consistency and integrity cannot be guaranteed.
C. the permission management system has different designs, different concepts, and different technologies. The integration between permission management systems is difficult to implement Single-point logon, it also brings difficulties for enterprises to build enterprise portals.
Adopts unified security management design ideas, standardized design, and advanced technical architecture system, build a general, complete, secure, easy-to-manage, portable, and scalable permission management system that truly becomes the core of permission control, it is necessary to play an important role in maintaining system security. This article introduces the design and implementation of a role-based RBAC (Role-based policies Access Control) model permission management system, which is implemented based on J2EE architecture technology. It also discusses how the application system can access and control permissions.
1. A permission management system is built based on the J2EE architecture. The J2EE architecture integrates advanced software architecture ideas and features multi-layer Distributed Application Model, component-based and reusable components, unified and complete model, and flexible transaction processing control. The system is logically divided into four layers: Customer layer, web layer, business layer, and resource layer.
A. The customer layer is mainly responsible for machine interaction. The system administrator can access the service through a Web browser, or provide APIs and web service calls for different business systems.
B. The web layer encapsulates the presentation layer logic services used to provide clients that access the system through the Web.
C. The business layer provides business services, including business data and business logic, which centralize system business processing. The main business management modules include organization management, user management, resource management, permission management, and access control.
D. The resource layer is mainly responsible for data storage, organization and management. The resource layer provides two implementation methods: Large relational databases (such as Oracle) and LDAP (light Directory Access Protocol, Lightweight Directory Access Protocol) directory servers (such as Microsoft's Active Directory ).
2 RBAC model access control is a defense against unauthorized use of resources. The basic goal is to restrict the access permissions of the access subject (users, processes, services, etc.) to the Access Object (files, systems, etc.), so that the computer system can be used within the legal scope; determine what a user can do and what a program that represents a certain user interest can do [1]. There are generally three access control policies in the enterprise environment: autonomous access control method, forced access control method, and Role-Based Access Control Method (RBAC ).
The autonomy is too weak and the force is too strong. The two have a large workload and are not easy to manage [1]. The role-based access control method is currently recognized as an effective solution to centralized resource access control for large enterprises. The two notable features are: 1. Reduce the complexity of authorization management and reduce management overhead;
2. flexible support for enterprise security policies and great scalability for enterprise changes. The National Institute of Standards and Technology (NIST) Standard RBAC model consists of four component models, the four component models are the basic model rbac0 (core RBAC), The Role classification model rbac1 (hierarchal RBAC), The Role restriction model rbac2 (constraint RBAC), and the unified model rbac3 (combines RBAC) [1]. Rbac0 Model 1 is shown.
Figure 1 rbac0 Model
A. rbac0 defines the smallest element set that can constitute an RBAC control system. RBAC contains five basic data elements: User Users (users), role roles (roles), target objects (OBS), Operation operations (OPS), and permission permissions (PRMS, permissions are granted to a role rather than a user. When a role is assigned to a user, the user has the permissions contained in the role. Session sessions is the ing between the user and the activated role set. The difference between rbac0 and traditional access control is that adding an indirect layer brings flexibility. rbac1, rbac2, and rbac3 are successively extended on rbac0.
B. rbac1 introduces the inheritance relationships between roles. The Inheritance relationships between roles can be divided into general inheritance relationships and restricted inheritance relationships. Generally, the inheritance relationship only requires that the role inheritance relationship is an absolute partial-order relationship, allowing multi-inheritance between roles. The restricted inheritance relationship further requires that the role inheritance relationship is a tree structure.
C. The responsibility separation relationship is added to the rbac2 model. Rbac2 constraints specify the mandatory rules to be followed when a role is granted or a role is granted to a user and when a user activates a role at a certain time. Separation of duties includes static and dynamic separation of responsibilities. The relationship between constraints and user-role-Permission determines the access permission of users in the rbac2 model.
D. rbac3 contains rbac1 and rbac2, which provide both the inheritance relationship between roles and the separation of responsibilities. 3. Design the core object model based on the permission Design Concept of the RBAC model, and establish the core object model of the permission management system. 2.

The object model contains the following basic elements: user (users), user group (group), role (role), target (objects), and access mode) and operator ). The main relationships include: assigning role permissions PA (permission assignment) and assigning user roles UA (users assignmen). The descriptions are as follows:
Figure 2 core categories of the permission management system
A. control object: it is the resource to be protected by the system and can be accessed. Pay attention to the following two issues when defining resources:
1. Resources have hierarchical and inclusive relationships. For example, a webpage is a resource, and objects such as buttons and text boxes on a webpage are also resources. It is a subnode of a webpage node. If buttons can be accessed, the webpage must be accessible.
2. The resource concept mentioned here refers to the Resource class, not the instance of a specific resource ). The distinction between resource categories, resource instances, and resource granularity is conducive to determining the management boundaries between the permission management system and the application system, the permission management system needs to manage permissions for resource categories, and the application system needs to manage permissions for instances of specific resources. The distinction between the two is mainly based on the following two considerations: on the one hand, the permissions of resource instances are often related to resources. That is, the instance permission of a resource can be determined based on the association between the resource instance and the resource access subject.
For example, in the management information system, customers in different departments need to be divided according to the business region. Both Zone A and Zone B have the controlled resource of modifying customer information, here, "customer archives" belong to the category of resources. If it is required that only the customer data managed by zone A can be modified, the ownership of the data must be distinguished. The resources here belong to the category of resource instances. Customer archives (resources) should have user information (customer data may contain the business region attribute) in order to differentiate instance operations for specific resources, you can modify the information content under your jurisdiction.
On the other hand, the instance permissions of resources often have considerable business logic relevance. Different business logics often mean completely different permission judgment principles and policies.
B. Permission: access permission for protected resource operations is bound to a specific resource instance. Correspondingly, the access strategy is related to the resource category. Different resource categories may adopt different access modes ). For example, a page has an access mode that can be opened or cannot be opened, a button has an available and unavailable access mode, and a text editing box has an editable and uneditable access mode. Access policies of the same resource may have exclusion and inclusion relationships. For example, the modifiable access mode of a dataset contains the queryable access mode.
C. User: The owner or subject of the permission. Users and permissions are separated and bound through authorization management.
D. User Group: a set of users. In the judgment of business logic, the individual identity or group identity can be used for judgment. The system weakens the concept of user groups and mainly Implements user (personal identity.
E. Role: the unit and carrier of permission allocation. Roles support hierarchical permissions through inheritance relationships. For example, the section chief role also has the section chief role and different business personnel roles in the Section. F. Operation: bind the resource category and access policy.
G. Assign role permission PA: ing the association between operations and roles.
H. Assign User Role UA: ing between users and roles. The object model converts the access control model into an Access Matrix. The rows in the Access Matrix correspond to users, and the columns correspond to Operations. Each matrix element specifies the corresponding roles and corresponds to the authorized access permission and implementation behavior of the target. The content of the access capability table Cl (access capabilities) is viewed by rows in the access matrix, and the content of the access control table ACL (access control lists) is viewed by columns in the Access Matrix.
4. Permission Access Mechanism permission management system: provides centralized permission management services and provides user identification, user information, organizational structure information, and permission relationship table calculation. 3. Figure 3 access permission to fig.3 the privilege invoke system considers the relationship between the user, role, operation, access policy, and control object, and grants the permissions plus or minus the permissions, calculate the minimum permission of the user. In the business logic layer, you can use Session Bean to implement this service or publish it as a web service. The proxy mode is used to centrally control the permission calculation service to be accessed from the application system, and return the permission relationship table, that is, the Binary Group {objectid, operatorid }. Application System: You can access the permission management system through the access capability table CL and access control table ACL.
The following uses a J2EE-based application system as an example to describe the access process:
A. form-based authentication and servlet-based centralized login request processing [2]. Considering that the entity to be identified is a user, ACL-based access is adopted. When a user logs on, the user identification service of the permission management system is called. If the verification succeeds, the permission calculation service is called, and the permission relationship table is returned, which is stored in the global Session of the logged on user by hashmap; if there is no global session or expiration, it will be directed to the logon page and re-obtain the permission.
B. Access Control of direct URL resources using Cl-based access. If you directly enter a URL to access the page, you can use either of the following methods to control access:
1. Read Cl through the permission tag for control; 2. Use the filter mode for permission control. If you do not have the permission, redirect to the logon page. 5. The resource categories to be controlled by the permission control mechanism are defined according to the needs of the application system. The semantics and control rules are also provided by the application system, the permission management system is transparent, and the permissions treat resources and operations of different application systems in a unified manner. The permission relationship table obtained by the Application System Call permission management system also needs to be explained by the application system. According to this design, the permission management system is more universal, and the permission control mechanism is handled by the application system. Because the permission control of the application system is related to a specific technical environment, the main display component of the system is the JSP page, the tag library and permission control components are used together.
A. Permission ID: tags are used to identify different levels of resources. The page permission tag identifies the Page Object.
B. Permission registration: traverse the permission control tag on the JSP page and read the control permission of the JSP. Use the permission registration component to register the permission control objects and rules on the JSP page to the permission management information system.
C. permission control: When an application system user logs on to the system, after obtaining the permission relationship table from the permission management system, on the one hand, the permission tag control page is displayed; on the other hand, use the permission control component to control permissions in the business logic, especially the permission control of the object instance that is closely linked with the business logic.
6. Permission storage mechanism the permission management system adopts two optional storage mechanisms: LDAP (Lightweight Directory Access Protocol) Directory Service database and relational database. Stores user information, organizational structure, roles, operations, access modes, and other information. The directory service system is based on the LDAP standard and has extensive data integration and sharing capabilities. The meta-directory function allows you to quickly and concisely integrate with existing enterprise infrastructure to solve the synchronization problem between user databases such as traditional RDBMS and LDAP user databases. 7. Conclusion This article discusses the technical solution for implementing a permission management system based on RBAC model. This permission management system has been successfully applied to system design and development practices and is well integrated with the application system. The practice shows that permission Assignment Based on RBAC has the following advantages: Permission assignment is intuitive, easy to understand, and easy to use; it has good scalability and supports changing positions and permissions; hierarchical permissions are suitable for hierarchical organizational structures with high reusability.