Dynamic authentication method and device, equipment and medium

Abstract

The invention relates to the technical field of access control, can be applied to financial science and technology and medical health old-age service scenes, and discloses a dynamic authentication method, device, equipment and medium, and the method comprises the steps: when a target engine is initialized, creating an authentication session through the target engine to replace a standard session of the target engine; if the authentication session receives a target statement which is sent by a client and is associated with a target database, the target statement is intercepted and analyzed through the authentication session to obtain context information, and the target database is a database associated with the target engine; generating an authority verification request based on the context information, and sending the authority verification request to the target database for verification; and if the permission verification request is passed, allowing the target statement to continue to be compiled. The target engine can be prevented from directly accessing the database, and the safety is improved.

Description

Technical Field

[0001] This invention relates to the field of access control technology, and in particular to a dynamic authentication method, apparatus, device, and medium. Background Technology

[0002] One of the core components of a data platform is the distributed computing engine. However, distributed computing engines are designed with processing efficiency in mind, resulting in significant shortcomings in their native security model. Especially when working with data warehouse metadata databases, their default privileged process mode can lead to serious risks of unauthorized access.

[0003] In the fintech sector, data platforms typically store large amounts of sensitive data such as customer identity information, transaction records, and credit assessment reports. Different business departments (such as risk control, marketing, and customer service) need to access this data according to a strict principle of least privilege. With current technology, distributed big data engines can directly bypass the database's permission system to access underlying metadata and files, which could lead to large-scale sensitive data leaks due to unintentional configuration errors by internal personnel. In the healthcare and elderly care sectors, medical data contains highly sensitive personal information such as patients' medical history, medication records, and examination results. In traditional solutions, distributed big data engines can directly access the database, posing compliance risks related to privacy breaches.

[0004] The inventors realized that existing technologies could not effectively constrain the computational behavior of distributed computing engines, allowing them to easily access databases and posing security risks. Summary of the Invention

[0005] This invention provides a dynamic authentication method, apparatus, computer equipment, and medium to solve the problem of easy database access caused by the lack of constraints in existing distributed computing engines.

[0006] Firstly, a dynamic authentication method is provided, including: During target engine initialization, an authentication session is created through the target engine to replace the target engine's standard session; If the authentication session receives a target statement associated with the target database, the authentication session intercepts and parses the target statement to obtain context information, wherein the target database is the database associated with the target engine; A permission verification request is generated based on the context information, and the permission verification request is sent to the target database for verification. If the permission verification request is passed, the target statement is allowed to continue compiling.

[0007] Secondly, a dynamic authentication device is provided, including: The replacement module is used to create an authentication session through the target engine during target engine initialization to replace the target engine's standard session; The parsing module is used to intercept and parse the target statement to obtain context information if the authentication session receives a target statement associated with the target database, wherein the target database is a database associated with the target engine; The generation module is used to generate a permission verification request based on the context information and send the permission verification request to the target database for verification. The first authentication module is used to allow the target statement to continue compiling if the permission verification request is passed.

[0008] Thirdly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described dynamic authentication method.

[0009] Fourthly, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the above-described dynamic authentication method.

[0010] In the scheme implemented by the above-mentioned dynamic authentication method, apparatus, computer equipment, and storage medium, during the initialization of the target engine, an authentication session is created through the target engine to replace the standard session of the target engine. If the authentication session receives a target statement associated with the target database, the authentication session intercepts and parses the target statement to obtain context information, wherein the target database is the database associated with the target engine. Based on the context information, a permission verification request is generated and sent to the target database for verification. If the permission verification request passes, the target statement is allowed to continue compiling. In this invention, an authentication session can be created at a critical stage of target engine initialization and replaced with the authentication session to enable intervention in data access operations of the target engine. When a target statement is detected, the target statement can be intercepted and parsed to generate context information. Then, a permission verification request is generated based on the context information. This permission verification request is verified by the target database. Only when the verification passes is the target statement allowed to compile, thereby avoiding direct access of the database by the target engine and improving security. Attached Figure Description

[0011] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a schematic diagram of an application environment for the dynamic authentication method in one embodiment of the present invention; Figure 2 This is a flowchart illustrating a dynamic authentication method in one embodiment of the present invention; Figure 3 yes Figure 2 A schematic diagram of a specific implementation method for step S10; Figure 4 yes Figure 2 A schematic diagram of a specific implementation method for step S20; Figure 5 yes Figure 2 A schematic diagram of a specific implementation method for step S30; Figure 6 This is a schematic diagram of the first sub-process of the dynamic authentication method in one embodiment of the present invention; Figure 7 This is a schematic diagram of the second sub-process of the dynamic authentication method in one embodiment of the present invention; Figure 8 This is a schematic diagram of the structure of a dynamic authentication device in one embodiment of the present invention; Figure 9 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 10 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0013] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0014] The dynamic authentication method provided in this embodiment of the invention can be applied to, for example... Figure 1In this application environment, the client communicates with the server via a network. The server can receive target statements sent by the client. During target engine initialization, an authentication session is created through the target engine to replace the standard session of the target engine. If the authentication session receives a target statement associated with a target database sent by the client, it intercepts and parses the target statement to obtain context information, where the target database is the database associated with the target engine. Based on the context information, a permission verification request is generated and sent to the target database for verification. If the permission verification request passes, the target statement is allowed to continue compiling. In this invention, the target statement can be intercepted and parsed through the authentication session to generate a permission verification request. Only after the target database verifies the request is the target statement allowed to continue compiling, thereby avoiding direct access to the database by the target engine and improving security. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The invention will be described in detail below through specific embodiments.

[0015] Please see Figure 2 As shown, Figure 2 A flowchart illustrating the dynamic authentication method provided in this embodiment of the invention includes the following steps: S10: During target engine initialization, an authentication session is created through the target engine to replace the target engine's standard session.

[0016] The target engine is deployed on the server side to receive and process various data operation requests sent by clients. When the server starts the target engine, it creates a standard session for data interaction by default. This session only supports basic data transmission functions such as receiving client requests and forwarding them to the target database, and has no permission verification capabilities. This step replaces the standard session to implant authentication capabilities into the server-side target engine. Specifically, during the session construction phase of the server-side target engine initialization, preset logic triggers the creation of an authentication session, which completely replaces the functionality of the standard session and additionally undertakes authentication responsibilities. The creation of the authentication session does not change the core computing logic of the server-side target engine; it only adds a permission verification node to the chain of receiving client target statements and executing compilation. All authentication operations are completed on the server side, without adding any extra burden to the client.

[0017] For example, in a fintech scenario, a bank's credit risk control data platform is deployed on the server side. This credit risk control data platform is configured with a distributed computing engine, namely the target engine. When the platform starts and initializes, it automatically creates an authentication session to replace the original default data interaction session, namely the standard session. This ensures that all subsequent target statements sent by clients (loan officer terminals, risk control specialist workstations) such as risk control model data queries and transaction record statistics must be authenticated on the server side before execution.

[0018] In a healthcare scenario, a hospital's clinical data center is deployed on the server side. This clinical data center is equipped with a distributed computing engine, namely the target engine. During the initialization of the data center, an authentication session is created to replace the standard session, so that the target statements of the client (doctor's workstation, researcher's terminal) that call patient data are all included in the authentication control on the server side.

[0019] In some embodiments, such as Figure 3 As shown, in step S10, that is, creating an authentication session through the target engine to replace the standard session of the target engine, the specific steps include the following: In the session builder of the target engine, security extension logic is dynamically triggered through preset configuration parameters; Based on the security extension logic, a session with authentication functionality is generated to obtain the authentication session; The standard session is replaced by overriding the authentication session.

[0020] The target engine's session builder supports extended configuration. Preset configuration parameters are boolean or enumerated, used to control the enabling state of security extension logic. When the configuration parameters trigger the security extension logic, the session builder loads core components such as the authentication module and context resolution module when creating a session, forming an authentication session with authentication capabilities. Subsequently, through the engine's session management mechanism, the authentication session is set as the default interactive session, overriding the original standard session's call entry point, achieving seamless replacement.

[0021] For example, in the session builder of a certain quantitative trading data platform, setting the configuration parameter auth.enable to true triggers the security extension logic, generates an authentication session that supports permission verification, overriding the original standard session. All data query operations of quantitative trading strategies are executed through this authentication session. In the gene data processing engine (target engine) of a medical research institution, the configuration parameter security.session.mode is set to auth, which triggers the security extension logic to create an authentication session, replacing the standard session, to ensure that all reading and analysis operations of gene sequence data are authenticated.

[0022] S20: If the authentication session receives a target statement associated with the target database sent by the client, the authentication session intercepts and parses the target statement to obtain context information, wherein the target database is a database associated with the target engine.

[0023] The client (such as a user terminal or a business system client) sends target statements to the server-side target engine based on business needs. These target statements include all instructions that interact with the target database, such as database query statements, data write statements, and metadata modification statements. When the server receives the target statement, it intercepts it to temporarily suspend its compilation. Then, it parses the target statement to obtain context information. This context information includes, but is not limited to, the executing user's identity (a unique identifier for the client's logged-in user, such as an employee ID or doctor's employee number), the target database name (such as a personal credit database or an internal medicine medical record database), the target data table name (such as a customer repayment record table or a patient examination report table), and the data operation type (such as query, add, modify, or delete). This context information provides a complete basis for subsequent permission verification.

[0024] In some embodiments, such as Figure 4 As shown, in step S20, that is, intercepting and parsing the target statement through the authentication session to obtain context information, the specific steps include the following: During the compilation phase of the target engine, after syntax parsing is completed and before the logic plan is generated, the parsed abstract syntax tree is intercepted. The abstract syntax tree is traversed to extract the context information, wherein the context information includes at least the executing user identity, the target database name, the target data table name, and the data operation type.

[0025] The server-side target engine processes the target statement as follows: receiving client requests → syntax parsing → logic plan generation → physical execution. In this step, the authentication node is embedded between the server's syntax parsing and logic plan generation. At this point, the target statement sent by the client has been parsed by the server into a structured abstract syntax tree, facilitating the extraction of key information. By traversing the nodes of the abstract syntax tree, the server can accurately extract contextual information.

[0026] For example, in a fintech scenario, the client (loan officer Zhang San's terminal, login ID: Y001) sends the statement "SELECT repayment amount FROM personal loan database. customer repayment record table WHERE customer ID=C12345" to the server-side credit risk control platform. After receiving the target statement, the server-side authentication session intercepts the abstract syntax tree after syntax parsing and extracts the context information: the user identity is loan officer Zhang San (ID: Y001), the target database name is personal loan database, the target data table name is customer repayment record table, and the data operation type is query.

[0027] In a healthcare scenario, the client (the workstation of physician Li Si, employee ID: D1002) sends the statement "UPDATE Internal Medicine Medical Records Database.Patient Examination Report Table SET Follow-up Recommendation = Regular Follow-up WHERE Patient ID = P67890" to the server's clinical data center. After the server's authentication session intercepts the abstract syntax tree, it extracts the context information: the user identity is physician Li Si (employee ID: D1002), the target database name is Internal Medicine Medical Records Database, the target data table name is Patient Examination Report Table, and the data operation type is Modify.

[0028] S30: Generate a permission verification request based on the context information, and send the permission verification request to the target database for verification.

[0029] The permission verification request encapsulates context information in a structured format, ensuring that the target database can parse it. The target database has a built-in authorization management system that stores permission policies for all users; for example, loan officers can only query customer data within their assigned area, and physicians can only access the medical records of patients they have treated. By calling the target database's authorization management API, its mature permission verification logic can be directly reused, eliminating the need to repeatedly build a permission rule base within the target engine and reducing system complexity. When the target database verifies that the user has the corresponding permissions to operate on the target data, it returns a verification pass response. Alternatively, permission verification logic can be built into the target engine. This logic can be consistent with and synchronously updated with the target database's permission verification logic, allowing for automatic verification without accessing the target database.

[0030] After receiving a permission verification request, the target database can perform the verification itself according to the pre-configured permission verification logic and return the verification result, which can include verification success or verification failure.

[0031] In some embodiments, such as Figure 5 As shown, in step S30, that is, sending the permission verification request to the target database for verification, the specific steps include the following: Invoke the authorization management application interface of the target database, and submit the permission verification request to the target database through the authorization management application interface; If the target database returns a message indicating successful verification, then the permission verification request is confirmed to have passed. If the target database returns a message indicating that the representation verification failed, it is confirmed that the permission verification request was not approved.

[0032] After the server-side authentication session extracts the context information, it encapsulates the information into a standardized verification request according to the interface specification of the target database's authorization management API. Core fields may include: Identity identification fields: unique ID of the user (such as employee number in financial scenarios, doctor's employee number in medical scenarios), and user's role (such as loan officer, internist). Fields to be operated on: Target database name, Target table name, Target column name, Data partition identifier; Operation type field: Specifies the data operation behavior (such as SELECT, INSERT, UPDATE, DELETE, ALTER, etc.); Additional fields: unique request identifier, request timestamp.

[0033] The authentication session loads a preset API connection configuration, including the access address of the target database's authorization management API, connection timeout, retry policy, and transmission encryption configuration. Verification requests can be submitted using a one-time, non-repeating submission mechanism. A unique request identifier prevents duplicate verification. Upon receiving the request, the target database first checks if the identifier has already been processed. If processed, it directly returns the historical result; otherwise, it performs permission verification, ensuring that the same operation does not result in multiple permission checks due to retries or network latency.

[0034] After receiving a verification request, the target database's authorization management system first verifies the request's legitimacy (e.g., whether the request signature is valid, whether the request format conforms to specifications, and whether the request timestamp is within a valid range). If invalid, it directly returns an invalid request response. Then, it queries the permission rule base to match the permission relationship between user / role, operation object, and operation type, such as a loan officer's personal loan database in a financial scenario, a customer repayment record table to check if an authorized record exists, or a doctor's internal medicine medical record database in a medical scenario, or a patient examination report table to check if modification conforms to the permission rules. If the permission match is successful, the target database's authorization management API returns a standardized verification success response. The response information can include the unique identifier of the request, the verification result status code, the verification passed identifier, and the permission validity period.

[0035] After receiving a successful verification response, the authentication session will record the verification result (including response information and timestamp) and immediately allow the compilation process of the target statement, that is, allow the target engine to generate a logical execution plan, and then interact with the target database to complete data operations according to the normal process.

[0036] If the user / role executing the operation does not have the corresponding operation permissions for the target database / table / column (e.g., in a financial scenario, a regular teller does not have the permission to delete customer credit data, or in a medical scenario, a researcher does not have the permission to query patient gene data), or if the user's identity is not registered in the target database authorization system, the identity identifier has expired or been disabled, or the user previously had the permission but the permission has expired, or the operation type exceeds the authorization scope (e.g., a user with only query permissions attempts to perform a modification operation), the target database authorization management API will return a verification failure response. The response information may include the request unique identifier, verification result status code, verification failure identifier, failure reason code and description.

[0037] After receiving a verification failure response, the authentication session terminates the target engine's subsequent processing of the target statement (without generating a logical plan or interacting with the target database), preventing illegal operations at the source, and then returns an exception response to the client containing failure details and compliance prompts.

[0038] S40: If the permission verification request is passed, the target statement is allowed to continue compiling.

[0039] The authentication session can perform a secondary verification on the validation response returned by the target database to confirm the response's legitimacy, such as matching the request unique identifier, valid status code, and unexpired permissions. This avoids security risks caused by forged responses or expired permissions. The authentication session then updates its own state, marking the current target statement as authorized and executable, and caches the authorization result. The cache validity period is consistent with the permission validity period returned by the target database, typically 5-15 minutes, to avoid repeatedly initiating authentication requests for the same operation within a short period, reducing system interaction overhead. Afterwards, the authentication session removes the interception of the target statement, and the target engine compilation process, previously paused for authentication, is activated. The target statement switches from the authentication pending state to the compilation ready state, and can be compiled normally.

[0040] In some embodiments, such as Figure 6 As shown, the dynamic authentication method further includes the following steps: S50: If the target database returns a verification failure message, the compilation process of the target statement is immediately terminated, and an exception message containing details of the permission error is returned to the user.

[0041] When verification fails, the authentication session blocks further processing of the target statement (i.e., no logical plan or physical execution plan is generated) to prevent illegal operations from being executed. Simultaneously, clear exception information is returned to the user, including the reason for the failure and compliance tips, helping the user quickly locate the problem and complying with industry regulatory requirements for operational auditing.

[0042] For example, if a teller's deletion operation fails to be verified, the target engine immediately terminates the compilation of the statement and returns an exception message to the teller's terminal: Permission verification failed: The user has no personal credit database.

[0043] After a nurse's query operation failed to be validated, the data processing engine terminated the statement execution and returned the following error message: Permission verification failed: The user did not have authorization to access the patient's medical records, and unauthorized access is prohibited.

[0044] In some embodiments, such as Figure 7 As shown, the dynamic authentication method further includes the following steps: The authentication session supports dynamic state switching, which can be controlled through configuration parameters or management commands. Authentication is enabled by default to ensure data security. When existing business systems need to be upgraded or certain urgent tasks require temporarily bypassing authentication (which requires strict approval), the session can be switched to the disabled state. In this case, the authentication session only performs the basic data interaction functions of a standard session to avoid affecting business continuity. State switching records are retained by the logging system for easy auditing and traceability.

[0045] For example, in the early stages of the bank's data platform launch, some systems' batch data synchronization tasks were not yet adapted to the authentication logic. The authentication session could be switched to the off state through configuration commands to ensure that the batch tasks would be executed normally. After the adaptation was completed, the session could be switched back to the on state to restore the authentication function. In the event of a sudden public health incident in a hospital, it is necessary to urgently collect and analyze the symptom data of all patients in the hospital. The authentication function of the authentication session can be temporarily disabled to ensure rapid data collection. After the incident is handled, it can be switched back to the active state to restore fine-grained authentication.

[0046] As can be seen, in the above scheme, an authentication session can be created during the critical stage of target engine initialization, and the standard session can be replaced with the authentication session to enable intervention in data access operations of the target engine. When the target statement is detected, the target statement can be intercepted and parsed to generate context information. Then, based on the context information, a permission verification request is generated. This permission verification request is verified by the target database. Only when the verification is passed is the target statement allowed to be compiled, thereby avoiding the target engine from directly accessing the database and improving security.

[0047] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0048] In one embodiment, a dynamic authentication device is provided, which corresponds one-to-one with the dynamic authentication methods described in the above embodiments. For example... Figure 8 As shown, the dynamic authentication device includes a replacement module 101, a parsing module 102, a generation module 103, and a first authentication module 104. Detailed descriptions of each functional module are as follows: Replacement module 101 is used to create an authentication session through the target engine during target engine initialization to replace the standard session of the target engine; The parsing module 102 is used to intercept and parse the target statement to obtain context information if the authentication session receives a target statement associated with the target database, wherein the target database is a database associated with the target engine; The generation module 103 is used to generate a permission verification request based on the context information and send the permission verification request to the target database for verification. The first authentication module 104 is used to allow the target statement to continue compiling if the permission verification request is passed.

[0049] In one embodiment, the replacement module 101 is specifically used for: In the session builder of the target engine, security extension logic is dynamically triggered through preset configuration parameters; Based on the security extension logic, a session with authentication functionality is generated to obtain the authentication session; The standard session is replaced by overriding the authentication session.

[0050] In one embodiment, the parsing module 102 is specifically used for: During the compilation phase of the target engine, after syntax parsing is completed and before the logic plan is generated, the parsed abstract syntax tree is intercepted. The abstract syntax tree is traversed to extract the context information, wherein the context information includes at least the executing user identity, the target database name, the target data table name, and the data operation type.

[0051] In one embodiment, the generation module 103 is specifically used for: Invoke the authorization management application interface of the target database, and submit the permission verification request to the target database through the authorization management application interface; If the target database returns a message indicating successful verification, then the permission verification request is confirmed to have passed. If the target database returns a message indicating that the representation verification failed, it is confirmed that the permission verification request was not approved.

[0052] In one embodiment, the dynamic authentication device further includes: The second authentication module is used to immediately terminate the compilation process of the target statement and return an exception message containing details of the permission error to the user if it receives a verification failure message returned by the target database.

[0053] In one embodiment, the dynamic authentication device further includes: A configuration module is used to configure a startup state and a shutdown state for the authentication session, wherein the default state of the authentication session is the startup state; The startup module is used to start the authentication function so that the authentication session can authenticate the target statement when the authentication session is in the startup state; The closing module is used to disable the authentication function when the authentication session is in the closed state, so that the authentication session is used as the standard session.

[0054] This invention provides a dynamic authentication device that can create an authentication session during the critical initialization stage of the target engine and replace the standard session with the authentication session to enable intervention in data access operations of the target engine. When a target statement is detected, the target statement can be intercepted and parsed to generate context information. Then, a permission verification request is generated based on the context information. This permission verification request is verified by the target database. Only when the verification passes is the target statement allowed to be compiled, thereby avoiding direct access to the database by the target engine and improving security.

[0055] For specific limitations regarding the dynamic authentication device, please refer to the limitations of the dynamic authentication method above, which will not be repeated here. Each module in the aforementioned dynamic authentication device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of the computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0056] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 9As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When executed by the processor, the computer program implements a dynamic authentication method server-side function or steps.

[0057] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 10 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When executed by the processor, the computer program implements the client-side functions or steps of a dynamic authentication method. In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: During target engine initialization, an authentication session is created through the target engine to replace the target engine's standard session; If the authentication session receives a target statement associated with the target database, the authentication session intercepts and parses the target statement to obtain context information, wherein the target database is the database associated with the target engine; A permission verification request is generated based on the context information, and the permission verification request is sent to the target database for verification. If the permission verification request is passed, the target statement is allowed to continue compiling.

[0058] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor: During target engine initialization, an authentication session is created through the target engine to replace the target engine's standard session; If the authentication session receives a target statement associated with the target database, the authentication session intercepts and parses the target statement to obtain context information, wherein the target database is the database associated with the target engine; A permission verification request is generated based on the context information, and the permission verification request is sent to the target database for verification. If the permission verification request is passed, the target statement is allowed to continue compiling.

[0059] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0060] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0061] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0062] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A dynamic authentication method, characterized in that, Applied to the server side, including: During target engine initialization, an authentication session is created through the target engine to replace the target engine's standard session; If the authentication session receives a target statement sent by the client that is associated with the target database, the authentication session will intercept and parse the target statement to obtain context information, wherein the target database is the database associated with the target engine; A permission verification request is generated based on the context information, and the permission verification request is sent to the target database for verification. If the permission verification request is passed, the target statement is allowed to continue compiling.

2. The method according to claim 1, characterized in that, The step of creating an authentication session through the target engine to replace the standard session of the target engine includes: In the session builder of the target engine, security extension logic is dynamically triggered through preset configuration parameters; Based on the security extension logic, a session with authentication functionality is generated to obtain the authentication session; The standard session is replaced by overriding the authentication session.

3. The method according to claim 1, characterized in that, The step of intercepting and parsing the target statement through the authentication session to obtain context information includes: During the compilation phase of the target engine, after syntax parsing is completed and before the logic plan is generated, the parsed abstract syntax tree is intercepted. The abstract syntax tree is traversed to extract the context information, wherein the context information includes at least the executing user identity, the target database name, the target data table name, and the data operation type.

4. The method according to claim 1, characterized in that, Sending the permission verification request to the target database for verification includes: Invoke the authorization management application interface of the target database, and submit the permission verification request to the target database through the authorization management application interface; If the target database returns a message indicating successful verification, then the permission verification request is confirmed to have passed.

5. The method according to claim 4, characterized in that, After submitting the permission verification request to the target database through the authorization management application interface, the process further includes: If the target database returns a message indicating that the representation verification failed, it is confirmed that the permission verification request was not approved.

6. The method according to claim 1, characterized in that, The method further includes: If a verification failure message is received from the target database, the compilation process of the target statement is immediately terminated, and an exception message containing details of the permission error is returned to the user.

7. The method according to claim 1, characterized in that, The method further includes: Configure an active state and a closed state for the authentication session, wherein the default state of the authentication session is the active state; When the authentication session is in the started state, the authentication function is started to enable the authentication session to authenticate the target statement; When the authentication session is in the closed state, the authentication function is turned off so that the authentication session is used as the standard session.

8. A dynamic authentication device, characterized in that, include: The replacement module is used to create an authentication session through the target engine during target engine initialization to replace the target engine's standard session; The parsing module is used to intercept and parse the target statement to obtain context information if the authentication session receives a target statement associated with the target database, wherein the target database is a database associated with the target engine; The generation module is used to generate a permission verification request based on the context information and send the permission verification request to the target database for verification. The first authentication module is used to allow the target statement to continue compiling if the permission verification request is passed.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the dynamic authentication method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the dynamic authentication method as described in any one of claims 1 to 7.

Images