Permission control method, device, storage medium and computer program product

Abstract

The present application discloses a permission control method, device, storage medium and computer program product, which relates to the field of system operation and maintenance technology, and discloses a permission control method, including: obtaining user login information of a target user, and performing user authentication based on the user login information; creating a role cache when the target user authentication is passed; obtaining user permission information of the target user, and storing the user permission information in the role cache; when an access request initiated by the target user is detected, intercepting the access request and obtaining the request permission of the access request; obtaining the user permission information from the role cache, and performing resource access according to the access request when the request permission is consistent with the user permission information. The present application can reduce the problem of repeated development of permission modules caused by business adjustments, and reduce the waste of computing resources when building permission modules.

Description

Technical Field

[0001] The present application relates to the field of system operation and maintenance technology, and in particular to permission control methods, devices, storage media, and computer program products. Background Art

[0002] The permission module is a core component of the business platform, responsible for controlling and managing users' ability to access system resources, ensuring that each user can only access the functions or data they are authorized to access. The design of the permission module usually needs to be closely integrated with specific business logic to meet the specific needs of users with different roles, such as administrators, ordinary employees, and customers. Each role can see and operate different content.

[0003] The business platform may require different permission control granularity and rules in different business scenarios. When a new business is launched or an existing business is adjusted, directly reusing the business platform's existing permission modules may not meet all customized requirements. Therefore, when the business platform undergoes business adjustments, it is usually necessary to redevelop the permission modules. This process involves repeatedly creating similar infrastructure components, such as resetting the database table structure and recreating authentication services. This process of repeatedly creating permission modules requires computing resources, resulting in a waste of computing resources.

[0004] The above content is only used to assist in understanding the technical solution of this application and does not constitute an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a permission control method, device, storage medium and computer program product, aiming to solve the technical problem of resource waste when building a permission module of a business platform.

[0006] To achieve the above objectives, this application proposes a permission control method, which includes:

[0007] Obtaining user login information of the target user and performing user authentication based on the user login information;

[0008] When the target user passes the authentication, a role cache is created;

[0009] Obtaining user authority information of the target user and storing the user authority information in the role buffer;

[0010] When an access request initiated by the target user is detected, intercepting the access request and obtaining the request authority of the access request;

[0011] The user authority information is obtained from the role cache, and when the requested authority is consistent with the user authority information, resource access is performed according to the access request.

[0012] In one embodiment, the step of performing user authentication based on the user login information includes:

[0013] Sending the user login information to the security manager;

[0014] Sending a verification request to the authenticator through the security manager;

[0015] querying a relational database by the authenticator based on the user identifier carried in the verification request;

[0016] If the authenticator finds the user authority information corresponding to the user identifier, it is determined that the target user identity authentication is successful;

[0017] If the authenticator fails to find the user authority information, it is determined that the target user identity authentication fails.

[0018] In one embodiment, after the step of querying the relational database based on the user identifier carried in the verification request by the authenticator, the method further comprises:

[0019] Sending the user authority information to a cache database through the authenticator;

[0020] Before the step of obtaining the user authority information from the role cache, the method further comprises:

[0021] The user authority information is obtained from the cache database according to a first preset period, and the most recently obtained user authority information is stored in the role cache.

[0022] In one embodiment, after the step of sending the user authority information to the cache database through the authenticator, the method further includes:

[0023] When it is detected that the user authority information reaches a preset life cycle, migrating the user authority information to the relational database;

[0024] The data in the cache database is backed up to a distributed search engine or a data warehouse according to a second preset period.

[0025] In one embodiment, the method further comprises:

[0026] Obtain and save the target user's login operation log and permission operation log according to a third preset period;

[0027] When it is determined that the permission check is triggered, the login operation information and the permission operation information are obtained from the login operation log and the permission operation log;

[0028] Performing a permission check on the target user based on the login operation information and the permission operation information;

[0029] If the permission check fails, the role permission is processed.

[0030] In one embodiment, the step of performing authority recheck on the target user based on the login operation information and the authority operation information includes:

[0031] Determining a user login operation of the target user based on the login operation information, and determining a user permission operation of the target user based on the permission operation information;

[0032] If the user login operation or the user authority operation is consistent with the preset abnormal behavior, it is determined that the target user authority check fails;

[0033] If both the user login operation and the user authority operation are inconsistent with the preset abnormal behavior, it is determined that the target user authority backcheck has passed.

[0034] In one embodiment, the step of processing the role authority includes:

[0035] Determining an abnormal operation consistent with the preset abnormal behavior from the user login operation and the user authority operation;

[0036] Determine the operation type of the abnormal operation, and process the target user according to the operation type.

[0037] In addition, to achieve the above-mentioned purpose, the present application also proposes a permission control device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the permission control method described above.

[0038] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by the processor, the steps of the permission control method described above are implemented.

[0039] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, it implements the steps of the permission control method described above.

[0040] In this application, user login information of the target user is obtained, and user authentication is performed based on the user login information; if the target user authentication is passed, a role cache is created; user permission information of the target user is obtained, and the user permission information is saved in the role cache; when an access request initiated by the target user is detected, the access request is intercepted and the request permission of the access request is obtained; the user permission information is obtained from the role cache, and if the request permission is consistent with the user permission information, resource access is performed according to the access request.

[0041] In this application, by introducing a role caching mechanism and a dynamic permission verification process, user authentication and permission allocation are decoupled. Even if business adjustments lead to changes in role permissions, it is only necessary to update the permission information corresponding to the role without changing the authentication logic. This simplifies the permission management process and reduces the possibility of reconstructing the permission module due to business adjustments, thereby effectively reducing the problem of repeated development of permission modules caused by business adjustments and reducing dependence on and waste of computing resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0043] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0044] Figure 1 A flowchart of the first embodiment of the permission control method of this application is provided;

[0045] Figure 2 A flowchart of the second embodiment of the permission control method of this application is provided;

[0046] Figure 3 A schematic diagram of the business platform architecture provided for one embodiment of the present application;

[0047] Figure 4 This is an authentication sequence diagram of a centralized authentication mechanism provided in one embodiment of the present application;

[0048] Figure 5 A schematic diagram of the authorization and interface-level control process provided in one embodiment of the present application;

[0049] Figure 6 A schematic diagram of the architecture of the permission system provided in one embodiment of the present application;

[0050] Figure 7 A flowchart of the permission check provided in one embodiment of the present application;

[0051] Figure 8 A schematic diagram of the microservice architecture provided in one embodiment of the present application;

[0052] Figure 9 A schematic diagram of the structure of data storage provided in one embodiment of the present application;

[0053] Figure 10 A flow chart of the configuration center provided in one embodiment of the present application;

[0054] Figure 11 A schematic diagram of an interface for editing a grayscale release task provided in one embodiment of the present application;

[0055] Figure 12 This is a schematic diagram of the device structure of the hardware operating environment involved in the permission control method in the embodiment of the present application.

[0056] The purpose, features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0057] It should be understood that the specific embodiments described herein are merely used to explain the technical solutions of the present application and are not intended to limit the present application.

[0058] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0059] The main solution of the embodiment of the present application is: obtaining the user login information of the target user, and performing user authentication based on the user login information; creating a role cache when the target user authentication is passed; obtaining the user permission information of the target user, and saving the user permission information in the role cache; when an access request initiated by the target user is detected, intercepting the access request and obtaining the request permission of the access request; obtaining the user permission information from the role cache, and performing resource access according to the access request when the request permission is consistent with the user permission information.

[0060] In this embodiment, for ease of description, the following description is made with the permission control device as the execution subject.

[0061] With the continuous expansion of the bank's business platforms and the development of developer tool platforms, how to quickly integrate the bank's permissions system has become a challenging issue. The permissions module is a core component of the business platform, responsible for controlling and managing user access to system resources, ensuring that each user can only access authorized functions or data. The design of the permissions module is often closely integrated with specific business logic to meet the specific needs of users with different roles, such as administrators, ordinary employees, and customers, each of whom can see and operate differently.

[0062] The business platform may require different permission control granularity and rules in different business scenarios. When a new business is launched or an existing business is adjusted, directly reusing the business platform's existing permission modules may not meet all customized requirements. Therefore, when the business platform undergoes business adjustments, it is usually necessary to redevelop the permission modules. This process involves repeatedly creating similar infrastructure components, such as resetting the database table structure and recreating authentication services. This process of repeatedly creating permission modules requires computing resources, resulting in a waste of computing resources.

[0063] In addition, since the permission module is too deeply coupled with the business module, it is difficult to configure and take effect immediately after the permission module is built, and permission management is prone to confusion, and there is a lack of flexible permission governance solutions.

[0064] In the embodiment of the present application, by introducing a role caching mechanism and a dynamic permission verification process, user authentication and permission allocation are decoupled. Even if business adjustments lead to changes in role permissions, it is only necessary to update the permission information corresponding to the role without changing the authentication logic. This simplifies the permission management process and reduces the possibility of needing to reconstruct the permission module due to business adjustments, thereby effectively reducing the problem of repeated development of permission modules due to business adjustments and reducing dependence on and waste of computing resources.

[0065] Moreover, due to the logical separation of user authentication, role management, and permission verification, the system can more flexibly add and modify roles and permission configurations when facing new business launches or existing business adjustments, without the need to build the permission module from scratch each time. This enhances the maintainability and scalability of the system and the timeliness of permission configuration.

[0066] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, mobile phone, etc., or an electronic device or permission control device capable of implementing the above functions. The following uses the permission control device as an example to illustrate this embodiment and the following embodiments.

[0067] Based on this, the embodiment of the present application provides a permission control method, referring to Figure 1This is a flowchart of the first embodiment of the permission control method of this application.

[0068] In this embodiment, the permission control method includes steps S10 to S50.

[0069] Step S10: Obtain user login information of the target user, and perform user authentication based on the user login information.

[0070] It should be noted that the target user is any user who logs into the service platform, and the user login information is the identity information provided by the target user when logging into the service platform, such as user name and password.

[0071] When a user attempts to log in to the system, the permission control device first receives and verifies the login information provided by the user, and then authenticates the user login information to confirm the authenticity of the user's identity, ensuring that legitimate users can enter the business platform, enhancing the security of the business platform and preventing unauthorized access.

[0072] The method of performing user authentication based on user login information is not described in detail here, and the conventional user authentication process can be referred to. In a feasible implementation, the process of performing user authentication based on user login information can be:

[0073] a1, sends the user login information to the security manager.

[0074] When a user attempts to log in, the permission control device collects the user login information entered by the user and then forwards the user login information to the security manager in the permission control device. The security manager, as a central coordination component, is responsible for handling security-related tasks. By centrally handling security transactions through the security manager, unified security policy management can be achieved, the system architecture can be simplified, and security can be improved.

[0075] a2, sends a verification request to the authenticator through the security manager.

[0076] After receiving the user login information, the security manager sends a verification request to the authenticator. The verification request usually contains user identification information for subsequent permission queries.

[0077] By setting up separation of responsibilities between the security manager and the authenticator, each component can focus on its own functional area, improving the maintainability and scalability of the system.

[0078] a3. The authenticator queries the relational database based on the user ID carried in the verification request.

[0079] After receiving the verification request, the authenticator uses the user identifier (such as username) in the verification request to search the relational database for the corresponding user record. This query process is intended to verify whether the user exists and obtain the user's preset permission information.

[0080] a4. If the authenticator finds the user authority information corresponding to the user ID, it determines that the target user identity authentication is successful.

[0081] If the database query result shows that the user exists and has the corresponding permission record, the authenticator will determine that the user's identity authentication is successful and the target user can continue to access the system.

[0082] a5. If the authenticator fails to find the user permission information, it determines that the target user identity authentication fails.

[0083] If no record matching the submitted user ID is found in the database, or the found record lacks the necessary permission information, the authenticator will determine that the authentication has failed.

[0084] It should be noted that by setting up a user login authentication mechanism, it can be ensured that only users with legitimate accounts and corresponding permissions can enter the system, effectively preventing unregistered users or users whose permissions have been revoked from accessing the system, further strengthening the security of the system and preventing illegal intrusions.

[0085] Step S20: When the target user passes authentication, a role cache is created.

[0086] When the target user successfully authenticates, the permission control device creates a role cache for the target user to temporarily store the role information associated with the user. This is done to facilitate subsequent quick access and permission verification, reducing database query overhead.

[0087] It should be noted that by creating a role cache, after the user successfully authenticates for the first time, his or her role information will be saved in the cache. Subsequent access requests only need to query the cache instead of the database, which reduces the pressure on the database, improves the system response speed, reduces dependence on the database, and improves user experience and system efficiency.

[0088] Step S30: Obtain the user authority information of the target user and save the user authority information in the role buffer.

[0089] The system queries the corresponding role based on the user ID of the authenticated user and writes the role information into the role cache created previously.

[0090] It should be noted that roles define the scope of user permissions within the system. Target users can be assigned to roles and positions, and can have multiple roles and multiple positions. Positions are abstract collections of roles, and one position can be assigned multiple roles. Each role corresponds to different permission resources (such as pages, buttons, and other permissions), thereby decoupling user permissions from roles, facilitating the management and adjustment of permission allocation, and simplifying the complexity of permission management.

[0091] Step S40: When an access request initiated by a target user is detected, the access request is intercepted and the request authority of the access request is obtained.

[0092] When an authenticated user attempts to access specific resources or perform an operation, the permission control device will first intercept this request through the middleware or permission control module, analyze the permission requirements contained in the request, and determine what kind of permissions are required for the resource the user is trying to access or the operation he is trying to perform.

[0093] Step S50: Obtain user authority information from the role cache, and access resources according to the access request if the requested authority is consistent with the user authority information.

[0094] The permission control device compares the permission required by the access request with the permission possessed by the user permission information in the role cache. If a match is successful, it means that the user has the permission to perform the operation and the system allows access; otherwise, the access request is rejected.

[0095] It should be noted that this embodiment can implement fine-grained permission control, ensuring that each user can only access and operate the resources for which they are authorized, effectively preventing permission abuse and data leakage, and maintaining the safe and stable operation of the system.

[0096] In this embodiment, by introducing a role caching mechanism and a dynamic permission verification process, even if business adjustments lead to changes in role permissions, it is only necessary to update the permission information corresponding to the role without changing the authentication logic. This simplifies the permission management process, reduces the possibility of needing to reconstruct the permission module due to business adjustments, effectively reduces the problem of repeated development of permission modules due to business adjustments, and reduces dependence on and waste of computing resources.

[0097] Moreover, due to the logical separation of user authentication, role management, and permission verification, the system can more flexibly add and modify roles and permission configurations when facing new business launches or existing business adjustments, without the need to build the permission module from scratch each time, thereby enhancing the maintainability and scalability of the system.

[0098] In one feasible implementation, after the step of querying the relational database based on the user identifier carried in the verification request by the authenticator, the permission control method further includes:

[0099] Step S60: Send the user authority information to the cache database through the authenticator.

[0100] The authenticator retrieves the user permission information corresponding to the user ID from the relational database and sends it to the cache database for storage. The cache database is typically an in-memory database or a high-speed cache system designed to quickly access data and reduce direct access to the main database. By storing frequently queried user permission information in the cache database, the speed of subsequent permission verification can be significantly improved, system latency can be reduced, and the user experience can be enhanced.

[0101] It should be noted that user authority information refers to information that characterizes the scope of user authority, including at least the user role, and may also include the authority resources of the user role, etc., which is not limited here.

[0102] In this embodiment, before step S40: obtaining user authority information from the role buffer, the authority control method further includes step S70.

[0103] Step S70: acquiring user authority information from the cache database according to a first preset period, and storing the most recently acquired user authority information in the role cache.

[0104] A fixed period (i.e., the first preset period) is set in advance, during which user authority information is automatically retrieved from the cache database and the content in the role cache is updated to ensure that the user authority information stored in the role cache is the latest and can be reflected in a timely manner even if the user's role authority changes in the background.

[0105] By updating user permission information in the role cache, dynamic updates are achieved, ensuring real-time and accurate permission control. This reduces the frequency of direct queries to the master database, further optimizing system performance while ensuring the flexibility and security of permission management. Regular synchronization allows the system to adapt to immediate adjustments to user permissions, avoiding misjudgments of permissions due to information lags and improving system reliability and responsiveness.

[0106] In one feasible implementation, after step S60, the authenticator sends the user authority information to the cache database, the authority control method further includes steps S80 to S90.

[0107] Step S80: When it is detected that the user authority information reaches a preset life cycle, the user authority information is migrated to a relational database.

[0108] To maintain data consistency and persistence, a pre-set lifecycle is set. This lifecycle is the validity period of user permission information in the cache database. When the user permission information in the cache database reaches the pre-set lifecycle, the user permission information is moved from the cache database to the relational database for storage.

[0109] It's important to note that migrating user permissions information to a relational database ensures that even if the cache database loses data for some reason, the long-term record of user permissions will not be affected, thus enhancing data reliability. Furthermore, by clearing expired cache data, we help optimize cache space usage and maintain system efficiency.

[0110] Step S90: backing up the data in the cache database to the distributed search engine or data warehouse according to a second preset period.

[0111] A second preset period is pre-set, and the data in the cache database is regularly backed up to a distributed search engine or data warehouse (Elasticsearch, ES) according to this period.

[0112] In this implementation, backing up data to ES provides an additional layer of data security. Even in extreme cases, such as when both the primary and cache databases fail, permission information can be quickly restored through the backup data, reducing the risk of data loss. Furthermore, ES's efficient retrieval capabilities facilitate data analysis and auditing, helping system administrators better understand permission usage and promptly identify potential security threats or abnormal behavior, thereby improving the system's overall security management and decision-making efficiency. In summary, these two steps enhance the data's persistence, recoverability, and analytical capabilities, jointly improving the performance of the permission control system in terms of data management, security, and operational efficiency.

[0113] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above embodiment 1 can be referred to the above introduction and will not be described in detail later. Figure 2 , the authority control method also includes steps A10 to A40.

[0114] Step A10: Obtain and save the target user's login operation log and permission operation log according to a third preset period.

[0115] The authority control device obtains and saves the target user's login operation log and authority operation log according to the third preset period, and specifically saves them in the ES.

[0116] Login operation logs are records of target users' login activities, such as login time and IP address (Internet Protocol Address). Permission operation logs are records of target users' permission operations, such as the resources the user attempted to access and the type of operation. Log data is crucial for monitoring user behavior, auditing, and security analysis.

[0117] By storing operation logs, it is easy to review user activities afterwards, detect abnormal logins or unauthorized operations, and enhance the security and compliance of the system.

[0118] Step A20: When it is determined that the permission check is triggered, the login operation information and the permission operation information are obtained from the login operation log and the permission operation log.

[0119] When the permission control device detects a situation that requires permission review, such as triggering a preset rule, a specific time point, or discovering suspicious behavior, it will extract the target user's operation information from the login operation log and the permission operation log, that is, the login operation information and the permission operation information. The login operation information includes but is not limited to the frequency, time, and location of the login, and the permission operation information includes but is not limited to the user's specific permission operations.

[0120] It should be noted that by proactively identifying scenarios that require review, we can respond to potential risks in a timely manner, reduce the occurrence of security vulnerabilities, and improve the speed of response to abnormal behavior.

[0121] Step A30: Perform authority check on the target user based on the login operation information and the authority operation information.

[0122] Using the collected login and permission operation information, the permission control device re-evaluates whether the user's behavior is consistent with the permissions granted to it, realizing dynamic permission management, ensuring the correctness and timeliness of user permissions, preventing permission abuse, and increasing system security.

[0123] It should be noted that the permission check process is not limited here and can be set according to actual needs. For example, in one feasible implementation, the login operation information and permission operation information can be compared with the preset abnormal behavior to perform permission check; in another feasible implementation, the login operation information and permission operation information can also be input into a pre-trained anomaly recognition model, which uses the login operation information (hereinafter referred to as historical login information) and permission operation information (hereinafter referred to as historical permission information) with known anomaly detection results as input data, and is trained using the anomaly detection results corresponding to the historical login information and historical permission information as training labels.

[0124] Specifically, in one feasible implementation, the process of performing permission check on the target user based on the login operation information and the permission operation information may be:

[0125] b1. Determine a user login operation of the target user based on the login operation information, and determine a user permission operation of the target user based on the permission operation information.

[0126] Analyze information in login operation logs, such as login time, login location (IP address), and login device, to identify user login patterns. For example, if a user usually logs in from the company network during working hours, but suddenly attempts to log in from a remote location late at night, this may be considered an anomaly.

[0127] Review permission operation logs to see if the actions actually performed by users match the permissions they are granted. For example, if a regular user attempts to access sensitive data that only administrators can view, this will be marked as a permission operation anomaly.

[0128] b2. If the user login operation or user permission operation is consistent with the preset abnormal behavior, it is determined that the target user permission backcheck fails.

[0129] If any login behavior or permission operation of the user matches the pre-set abnormal behavior pattern (such as frequent failed login attempts, logging in during non-working hours, operations beyond the scope of permission, etc.), the permission control device will determine that the permission backcheck has failed, which means that there may be security risks or violations.

[0130] b3. If both the user login operation and the user permission operation are inconsistent with the preset abnormal behavior, it is determined that the target user permission backcheck has passed.

[0131] If the user's login and permission operation records show normal behavior and do not violate any preset abnormal behavior rules, the permission control device will consider that the permission backcheck has passed successfully, indicating that the user's login and operation permission use are compliant and safe.

[0132] Step A40: If the permission check fails, the role permission is processed.

[0133] If the permission review finds that the user's behavior exceeds the scope of their authority, or the user's status does not meet the requirements (such as the account has expired), the permission control device will take corresponding measures to ensure system security. The measures include but are not limited to: restricting or revoking some permissions, forcing users to re-authenticate, recording illegal operations and issuing alarms, etc.

[0134] It should be noted that permission backchecking can promptly correct abuse or improper use of permissions, protecting system resources from unauthorized access threats. It also strengthens internal security controls to ensure stable system operation and data security. Furthermore, by continuously monitoring and analyzing user behavior, potential unauthorized access and permission abuse can be promptly detected and addressed, effectively preventing security threats. This ensures that user activities adhere to the organization's security policies and compliance requirements, reducing violations and improving the organization's compliance level. Furthermore, this implementation improves the system's adaptability and defense capabilities by dynamically adjusting permission audit policies and adjusting security thresholds based on actual operational behavior.

[0135] In one feasible implementation, step A10, processing role permissions, includes:

[0136] Step A101: determining abnormal operations consistent with preset abnormal behaviors from user login operations and user authority operations.

[0137] The permission control device first analyzes login and permission operation logs to identify operations that match pre-set abnormal behavior patterns. Abnormal operations may include, but are not limited to, frequent failed login attempts, logging in during unusual hours (such as late at night), logging in from unknown or high-risk areas, and attempting to access unauthorized resources. Using algorithms or pre-set rules, the system automatically identifies these operations that deviate from normal behavior patterns and marks them as abnormal.

[0138] Step A102: Determine the operation type of the abnormal operation and process the target user according to the operation type.

[0139] When an abnormal operation is identified, the permission control device will further classify the nature or type of the operation. For example, it may classify abnormal operations into different categories, such as login-related abnormalities and permission abuse abnormalities. Depending on the type of abnormal operation, the permission control device will take different measures.

[0140] For example, if it is a login-related exception, the account may be temporarily locked and the user may be required to reactivate through secondary verification; if it is a permission abuse exception, the permission control device may immediately revoke or restrict the user's specific permissions, and notify the permission control device administrator or security team to intervene in the investigation.

[0141] This implementation automatically identifies and categorizes abnormal operations when anomalies are detected during permission rechecks. This allows the system to quickly implement targeted measures, effectively curbing potential security threats and reducing losses. Furthermore, customized handling solutions are tailored to the specific type of abnormal operation, effectively preventing accidental harm to legitimate users while precisely combating malicious activity, thereby improving the effectiveness of security measures.

[0142] For example, in order to help understand the technical concept or technical principle of the permission control after combining this embodiment with the above-mentioned embodiment 1 and embodiment 2, the business platform in this embodiment can provide a distributed stress testing engine service, referring to Figure 3 The overall framework of the business platform can include: user center, resource center, authority management center, approval center, audit center, open capability module and basic services.

[0143] User Center: This area primarily includes functions such as permission search, self-service permission application, intelligent permission recommendation, and a unified permission view. Permission search can be used to find and manage user permission information; self-service permission application allows users to apply for required permissions; intelligent permission recommendation can automatically recommend appropriate permissions to users based on an algorithm; and the unified permission view provides a comprehensive perspective to view and manage all permissions.

[0144] Resource Center: This section covers menu resources, button resources, URL (Uniform Resource Locator) resources, data resources, and custom resources. These are objects that can be accessed and controlled within the system. For example, menu resources may refer to various functional options within the application, button resources refer to specific interactive elements, URL resources represent accessible web pages, data resources involve system data access permissions, and custom resources may refer to special resources that users can customize based on their needs.

[0145] Permission Management Center: This section consists of the user system, functional permissions, and data permissions. The user system may involve the creation, management, and maintenance of user accounts; functional permissions restrict the operations that users can perform; and data permissions focus on user access to and manipulation of specific data. Furthermore, there is ETL (Extract-Transform-Load) full data synchronization, which is commonly used in data warehouse construction to extract and transform data from various sources and then load it into the target storage.

[0146] Approval Center: This provides management of approval templates, role and position approvals, API (Application Programming Interface) approvals, and review of approval processes. Approval template management allows you to set and manage standard templates for approval processes; role and position approvals involve setting approval permissions for different roles and positions; API approvals allow you to approve access to application programming interfaces (APIs); and reviewing approval processes allows you to easily understand and track the approval process.

[0147] Audit Center: Audit rules, audit log reporting, audit alerts, and audit result queries constitute the main components of the Audit Center. Audit rules define how to monitor and evaluate system activities; audit log reporting collects and reports logs of these activities; audit alerts issue warnings when anomalies are detected; and audit result queries allow users to query and analyze audit results.

[0148] Open Capabilities: This module showcases the system's external interfaces and services, including authentication services, role permissions, job roles, micro-frontends, style isolation, permission configuration, data-level One-Stop, One-Number Access, operating organizations, and interface authentication. These features may be used for integration with other systems or provided to third-party developers.

[0149] Basic Services: Finally, the basic services section includes tenant isolation, front-end component packaging, interface authentication, and the StarterKit toolkit (a collection of basic components, documentation, sample code, and tutorials provided to help users quickly start a project, use a platform, or use a technology). Tenant isolation is a security measure in a multi-tenant architecture that ensures data and resources are isolated between different users; front-end component packaging may be used to build and deploy the front-end interface; interface authentication is for authorizing and authenticating system interfaces; and the StarterKit toolkit may be a collection of tools to help developers quickly get started and use it.

[0150] 1.1. The business platform adopts a centralized authorization mechanism and interface permission control with zero business code intrusion. Specifically:

[0151] (1) Please refer to Figure 4 , the authentication process of the centralized authentication mechanism can be:

[0152] The user initiates a login request (Login) and sends a message to the unified login.

[0153] After receiving the request, the unified login forwards the request to the security manager for authentication (that is, sends the user login information to the security manager).

[0154] After receiving the authentication request, the security manager sends a verification request to the authenticator (that is, sends a verification request to the authenticator through the security manager).

[0155] The authenticator obtains user permission information from the relational database, performs authentication based on the user permission information, and returns the result to the security manager (that is, the authenticator queries the relational database based on the user identifier carried in the verification request).

[0156] If the authentication is successful, the security manager returns a Token to the target user; if the authentication fails, the security manager returns 401 (that is, if the authenticator queries the user permission information corresponding to the user ID, it is determined that the target user identity authentication is successful; if the authenticator does not query the user permission information, it is determined that the target user identity authentication is unsuccessful).

[0157] At the same time, the authenticator caches the user permission information from the relational database to the cache database. If authentication is successful, the security manager creates a session (role cache), and the session manager caches the user permission information from the cache database to the role cache (i.e., the authenticator sends the user permission information to the cache database, obtains the user permission information from the cache database according to a first preset period, and saves the most recently obtained user permission information in the role cache).

[0158] (2) Please refer to Figure 5 , the process of authorization and interface-level control can be:

[0159] 1) Access the system interface. 2) The authorizer intercepts the access request. 3) Determine whether the user carried in the access request is in the whitelist. If in the whitelist, access is allowed. 4) If not in the whitelist, determine whether a session exists. If no session exists, access is denied. 5) If a session exists, check whether the session user has permission annotations for the corresponding resources, positions, and roles. 6) If the session user does not have permission annotations for the corresponding resources, positions, or roles, access is denied; if the session user has permission annotations for the corresponding resources, positions, and roles, access is allowed. (That is, when an access request initiated by the target user is detected, the access request is intercepted and the requested permissions for the access request are obtained; the user permission information is obtained from the role cache, and if the requested permissions are consistent with the user permission information, resource access is performed according to the access request).

[0160] When the access system backend service is called, the authorizer of the SDK (Software Development Kit) security manager will intercept it to implement interface-level verification. All interfaces other than the whitelist interface (configured by the access party) need to verify the Session, that is, the user has passed the authentication. The SDK provides interface-level permission annotations @RequiresRoles (having roles), @RequiresPosts (having posts), and @RequiresPermissions (having resource permissions), and implements interface permission control by adding different annotations to the interface. In order to improve authorization efficiency, a permission distributed cache is introduced to cache the user's personal permissions, and finally returns whether the access is successful or not after the permission verification.

[0161] 1.2. In this embodiment, the permission module of the business platform also includes an intelligent permission audit strategy, specifically:

[0162] (1) The permission operation log is automatically expanded. Please refer to Figure 6 The architecture of the general permission background system mainly includes the following parts:

[0163] SDKs: There are three different SDKs (SDK1, SDK2, and SDK3), which are integrated into different applications to interact with the general permission background system.

[0164] Kafka (open source distributed stream processing platform) log reporting: When an application uses the SDK to perform operations, corresponding log records are generated and sent to the Kafka message queue.

[0165] Log collection service: Consists of Server1, Server2, and Server3 (Server: service), which consume log messages from Kafka and process them.

[0166] Audit monitoring: Analyze collected logs, including alarm rule configuration, abnormal login detection, duplicate login detection, and operation auditing.

[0167] Type in ES index: Processed logs are stored in Elasticsearch. A new index is automatically generated for each application every month, and a type is automatically generated for each type of operation log.

[0168] ES: As the underlying data storage and service provider, it saves all log data and provides search and analysis capabilities for upper-level applications.

[0169] The main workflow based on this system architecture is as follows: the application communicates with the general permission backend through the SDK, and the generated logs are transmitted through Kafka; the log collection server receives and processes these logs, and then sends the processing results to the audit monitoring link; finally, all log data is stored in Elasticsearch for subsequent query and analysis.

[0170] The platform provides a universal login and permission operation log storage service to facilitate subsequent auditing needs. The SDK automatically reports login operation logs asynchronously through Kafka. Permission operations are uniformly reported by the general permission system backend, and logs are stored in Elasticsearch by type. To meet the continuous growth of docking systems, the log data model layer supports automatic expansion: each docking system corresponds to an appKey (Application Key), and each appKey automatically creates an index according to the template and date, supporting automatic expansion; each type of log corresponds to a type in the Elasticsearch index, and when a new permission operation log is added, the type is automatically created.

[0171] (2) Intelligent permission check. Please refer to Figure 7As shown, at the end of the day, the authority information of the system access party is reviewed. The review rules include: cleaning up resigned personnel, abnormal personnel login, data authority mismatch with the organization, and authority duplication. Specifically, the authority review process can be:

[0172] 1) Configuration of permission review rules, with default support for: cleanup of resigned personnel, abnormal personnel login, data permission and organization mismatch, and permission duplication. 2) Scheduled task review by the timed scheduler. 3) The rule parser obtains permission information and determines whether the review rule is hit. 4) Notify the target user. 5) Confirmation by the access party (that is, when it is determined that the permission review is triggered, the login operation information and permission operation information are obtained from the login operation log and the permission operation log; the target user is reviewed based on the login operation information and permission operation information; if the permission review fails, the role permissions are processed).

[0173] 1.3. The permission module of the business platform can also achieve high availability and stability of the permission API interface. Specifically,

[0174] (1) Microservice architecture, please refer to Figure 8 To ensure the stability and high availability of the permission API service module, the Universal Permission Platform splits the module into a microservices architecture, separating the core external API interface services from internal non-core services. Microservices are deployed in multiple AZs (Availability Zones) with multiple instances to prevent service unavailability caused by a single instance failure.

[0175] (2) High-performance solution for permission data. For details, please refer to Figure 9 The structural diagram of data storage shown in the figure shows that each microservice data is stored in a Mysql (relational database) sub-database, and mycat (the name of the source database middleware project, used for database sub-database and table sub-database, read-write separation, data routing, etc.) is used for read-write separation, and service circuit breaking and degradation are supported to ensure high availability of the service. Hot data such as roles and resources are cached in Redis to improve the performance of the API interface, and are automatically transferred to Mysql for query when the Redis (cache) cache is unavailable. Inactive data such as permission operation records, login operation logs, and daily historical backup data are stored in Elasticsearch for audit and downgrade protection. Circuit breaking is also supported when the service is unavailable to ensure the availability of core services.

[0176] (3) Implement high-performance gateway grayscale based on Nacos. Specifically, implement high-performance gateway grayscale based on Nacos (Nacos Config Service, an open source distributed configuration management platform): Introduce the Starter launcher into the Spring Cloud Gateway gateway, and the gateway can have the grayscale release function.

[0177] Reference Figure 10 The flow chart shown, the process of Nacos configuration center can be:

[0178] The management end edits the grayscale release task. The interface for editing grayscale release tasks can be as follows Figure 11 As shown, the specific grayscale release content includes gateway service, source address, grayscale address, and grayscale rules.

[0179] The Nacos Configuration Center synchronizes the configuration of the Nacos configuration file. After the configuration is complete, the data MD5 value (Message Digest Algorithm 5, a common hash function used to generate a message digest or checksum) is checked. Then, it is determined whether the MD5 value has changed. If it has not changed, the system returns to continue checking the data MD5 value. If it has changed, the local cache on the gateway side is updated.

[0180] The gateway starts the gateway, registers the gateway Filter (component) for grayscale verification, registers the NacosConfig Service (also known as Nacos) for the gateway, obtains the Nacos configuration and registers the listener. When the MD5 value changes, the local cache is updated, and then the user request is filtered through the filter. The gateway reads the grayscale rules and updates the Route (router) object.

[0181] Because the Nacos configuration center stores grayscale rules, the gateway monitors configuration file changes in the specified namespace through the Nacos Client API (Nacos click interface). This long polling method retrieves the changed data in near real time and stores it in the local cache. Compared to solutions using Redis, this implementation offers superior grayscale configuration performance. Furthermore, since only the local cache is read, service unavailability caused by Redis downtime, which is common in Redis grayscale solutions, is avoided.

[0182] This implementation achieves 1) decoupling of permissions and business implementation, providing componentized services to support secondary development; 2) one-stop permission center services, providing fast access to SAAS tenants (Software as a Service); 3) integration of classic permission models with the bank's internal permission system; and 4) intelligent permission governance and audit services.

[0183] It should be noted that the above examples are only used to understand this application and do not constitute a limitation on the permission control method of this application. More simple transformations based on this technical concept are all within the scope of protection of this application.

[0184] This application also provides a permission control device that uses the permission control method in the above embodiment to solve the problem of resource waste when building a permission module for a business platform. Compared with the prior art, the beneficial effects of the permission control device provided by this application are the same as those of the permission control method provided by the above embodiment, and the other technical features of the permission control device are the same as those disclosed in the above embodiment method, which will not be repeated here.

[0185] The present application provides a permission control device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the permission control method in the above-mentioned embodiment one.

[0186] Reference below Figure 12 , which shows a schematic diagram of the structure of a permission control device suitable for implementing the embodiments of the present application. The permission control device in the embodiments of the present application may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), in-vehicle terminals (such as in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 12 The permission control device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0187] like Figure 12As shown, the permission control device may include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes based on programs stored in a read-only memory (ROM) 1002 or programs loaded from a storage device 1003 into a random access memory (RAM) 1004. RAM 1004 also stores various programs and data required for the operation of the permission control device. The processing device 1001, ROM 1002, and RAM 1004 are connected to each other via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the permission control device to communicate wirelessly or wired with other devices to exchange data. Although the figure shows a permission control device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented or provided instead.

[0188] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0189] The permission control device provided by this application adopts the permission control method in the above embodiment, which can solve the problem of resource waste when building the permission module of the business platform. Compared with the existing technology, the beneficial effects of the permission control device provided by this application are the same as those of the permission control method provided by the above embodiment, and the other technical features of the permission control device are the same as those disclosed in the method of the previous embodiment, which will not be repeated here.

[0190] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0191] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

[0192] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer program) stored thereon, and the computer-readable program instructions are used to execute the permission control method in the above embodiment.

[0193] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0194] The computer-readable storage medium may be included in the authority control device, or may exist independently without being assembled into the authority control device.

[0195] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by the permission control device, the permission control device: obtains the user login information of the target user and performs user authentication based on the user login information; creates a role cache when the target user authentication is passed; obtains the user permission information of the target user and saves the user permission information in the role cache; when an access request initiated by the target user is detected, intercepts the access request and obtains the request permission of the access request; obtains the user permission information from the role cache, and when the request permission is consistent with the user permission information, performs resource access according to the access request.

[0196] Computer program code for performing the operations of the present application may be written in one or more programming languages, or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0197] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, program segment or a part of code, and the module, program segment or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented by a dedicated hardware-based system that performs the specified function or operation, or can be implemented by a combination of dedicated hardware and computer instructions.

[0198] The modules described in the embodiments of the present application may be implemented in software or hardware, wherein the name of a module does not necessarily limit the unit itself.

[0199] The readable storage medium provided in this application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., a computer program) for executing the above-mentioned permission control method, and can solve the problem of resource waste when building the permission module of the business platform. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the permission control method provided in the above-mentioned embodiment, and will not be repeated here.

[0200] The present application also provides a computer program product, including a computer program, which implements the steps of the above-mentioned permission control method when executed by a processor.

[0201] The computer program product provided by this application can solve the problem of resource waste when building the permission module of the business platform. Compared with the prior art, the beneficial effects of the computer program product provided by this application are the same as those of the permission control method provided by the above embodiment, and will not be repeated here.

[0202] The above description is only part of the embodiments of the present application and does not limit the patent scope of the present application. All equivalent structural transformations made by using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect application in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A permission control method, characterized in that: The method includes: Obtaining user login information of the target user and performing user authentication based on the user login information; When the target user passes the authentication, a role cache is created; Obtaining user authority information of the target user and storing the user authority information in the role buffer; When an access request initiated by the target user is detected, intercepting the access request and obtaining the request authority of the access request; Obtaining the user authority information from the role cache, and accessing the resource according to the access request if the requested authority is consistent with the user authority information; Wherein, the method further comprises: Obtain and save the target user's login operation log and permission operation log according to a third preset period; When it is determined that the permission check is triggered, the login operation information and the permission operation information are obtained from the login operation log and the permission operation log; Performing a permission check on the target user based on the login operation information and the permission operation information; If the permission check fails, the role permission of the target user is processed.

2. The method according to claim 1, wherein The step of performing user authentication based on the user login information includes: Sending the user login information to the security manager; Sending a verification request to the authenticator through the security manager; querying a relational database by the authenticator based on the user identifier carried in the verification request; If the authenticator finds the user authority information corresponding to the user identifier, it is determined that the target user identity authentication is successful; If the authenticator fails to find the user authority information, it is determined that the target user identity authentication fails.

3. The method according to claim 2, wherein After the step of querying the relational database based on the user identifier carried in the verification request by the authenticator, the method further comprises: Sending the user authority information to a cache database through the authenticator; Before the step of obtaining the user authority information from the role cache, the method further comprises: The user authority information is obtained from the cache database according to a first preset period, and the most recently obtained user authority information is stored in the role cache.

4. The method according to claim 3, wherein After the step of sending the user authority information to the cache database through the authenticator, the method further comprises: When it is detected that the user authority information reaches a preset life cycle, migrating the user authority information to the relational database; The data in the cache database is backed up to a distributed search engine or a data warehouse according to a second preset period.

5. The method according to claim 1, wherein The step of performing authority recheck on the target user based on the login operation information and the authority operation information includes: Determining a user login operation of the target user based on the login operation information, and determining a user permission operation of the target user based on the permission operation information; If the user login operation or the user authority operation is consistent with the preset abnormal behavior, it is determined that the target user authority check fails; If both the user login operation and the user authority operation are inconsistent with the preset abnormal behavior, it is determined that the target user authority backcheck has passed.

6. The method according to claim 5, wherein The step of processing the role authority of the target user includes: Determining an abnormal operation consistent with the preset abnormal behavior from the user login operation and the user authority operation; Determine the operation type of the abnormal operation, and process the target user according to the operation type.

7. A permission control device, characterized in that: The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the permission control method according to any one of claims 1 to 6.

8. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the permission control method according to any one of claims 1 to 6 are implemented.

9. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the steps of the permission control method according to any one of claims 1 to 6 are implemented.

Images