User permission identification method and device, computer device, and storage medium

Abstract

The present application relates to the field of artificial intelligence technology, which can be applied to medical health, financial technology and other business system platforms, and discloses a user permission identification method and device, computer equipment and a storage medium, wherein the access request of the client to the to-be-accessed interface is acquired, the access request is analyzed, the user identifier, request path and additional behavior context are extracted, the user behavior portrait segment is generated based on the additional behavior context; the request path is input into the dynamic feature perception engine, the interface risk heat value of the to-be-accessed interface is determined, the cache strategy of the to-be-accessed interface is determined according to the interface risk heat value and the user behavior portrait segment; according to the cache strategy, the permission data of the target user corresponding to the user identifier is retrieved in the target cache, and the retrieval result is generated; according to the retrieval result, it is judged whether the target user can access the to-be-accessed interface, the authentication result is generated, and the authentication result is returned to the client; the present application can realize efficient and accurate user permission identification.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and specifically to a user permission identification method, apparatus, computer device, and computer-readable storage medium. Background Technology

[0002] Currently, with the rapid development of internet technology and the increasing prevalence of various online services and applications, user access management has become a crucial aspect of ensuring system security and data privacy. In modern distributed systems and microservice architectures, user access identification typically requires collaboration among multiple services and components to ensure that users can only access resources they are authorized to access. Currently, traditional user access management systems usually rely on database queries to verify user permissions. Every time a user requests access to an interface, the system needs to retrieve the user's permission information from the database. This not only increases the database load but can also lead to response delays, impacting user experience, especially in the healthcare and fintech sectors.

[0003] In the healthcare field, user access control is of paramount importance. Medical data contains a wealth of sensitive information, such as patient medical records, diagnoses, and treatment plans. Access to this information must be strictly controlled to ensure patient privacy is protected. For example, only authorized doctors and nurses should have access to detailed patient records, while administrative staff may only have access to limited, non-sensitive information. Furthermore, the high availability and low latency requirements of healthcare systems pose significant challenges to user access control. In emergencies, healthcare professionals need rapid access to patient information; any delay could have serious consequences. Therefore, traditional access control systems that rely on database queries are particularly inadequate in the healthcare field, failing to meet the stringent requirements for real-time performance and security.

[0004] In the fintech sector, user access control is equally crucial. Fintech systems involve a large amount of financial transactions and sensitive data, such as user account information, transaction records, and fund flows. Access to this data must be strictly controlled to prevent data leaks and unauthorized access. For example, only authorized financial institution employees should be able to access customer account balances and transaction details, while external partners may only be able to access anonymized data. Furthermore, the high concurrency and security requirements of fintech systems pose even greater challenges to user access control. During peak trading periods, the system needs to process a large number of user requests rapidly; any delay can lead to transaction failures or a degraded user experience. Therefore, traditional access control systems that rely on database queries are inadequate in the fintech field, failing to meet the dual demands of performance and security.

[0005] Therefore, how to provide a user permission identification method, device, computer equipment, and computer-readable storage medium that can achieve efficient and accurate user permission identification is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0006] In view of the shortcomings of the prior art, the purpose of this invention is to provide a user permission identification method, apparatus, computer device and computer-readable storage medium, aiming to solve the problem of how to achieve efficient and accurate user permission identification.

[0007] To achieve the above objectives, the present invention adopts the following technical solution:

[0008] In a first aspect, the present invention provides a user permission identification method, comprising: Obtain the client's access request for the interface to be accessed, parse the access request, extract the user identifier, request path and additional behavioral context, and generate a user behavior profile fragment based on the additional behavioral context. The request path is input into the dynamic feature perception engine to determine the interface risk heat value of the interface to be accessed, and the caching strategy of the interface to be accessed is determined based on the interface risk heat value and the user behavior profile fragment. According to the caching strategy, retrieve the permission data of the target user corresponding to the user identifier in the target cache and generate retrieval results; Based on the search results, it is determined whether the target user can access the interface to be accessed, an authentication result is generated, and the authentication result is returned to the client.

[0009] Secondly, the present invention provides a user permission identification device, comprising: The acquisition module is used to acquire the client's access request to the interface to be accessed, parse the access request, extract the user identifier, request path and additional behavioral context, and generate user behavior profile fragments based on the additional behavioral context. The determination module is used to input the request path into the dynamic feature perception engine, determine the interface risk heat value of the interface to be accessed, and determine the caching strategy of the interface to be accessed based on the interface risk heat value and the user behavior profile fragment. The retrieval module is used to retrieve the permission data of the target user corresponding to the user identifier in the target cache according to the caching strategy, and generate retrieval results; The judgment module is used to determine whether the target user can access the interface to be accessed based on the search results, generate an authentication result, and return the authentication result to the client.

[0010] Thirdly, the present invention provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the user permission identification method as described above when executing the computer program.

[0011] Fourthly, the present invention provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the user permission identification method described above.

[0012] Compared to existing technologies, this invention provides a user permission identification method, apparatus, computer device, and computer-readable storage medium. The method involves acquiring a client's access request for an interface to be accessed, parsing the request to extract the user identifier, request path, and additional behavioral context, and generating a user behavior profile fragment based on the additional behavioral context. The request path is then input into a dynamic feature perception engine to determine the interface risk heat value of the interface to be accessed. Based on the interface risk heat value and the user behavior profile fragment, a caching strategy for the interface to be accessed is determined. According to the caching strategy, permission data of the target user corresponding to the user identifier is retrieved from the target cache, generating a retrieval result. Based on the retrieval result, it is determined whether the target user can access the interface to be accessed, generating an authentication result, and returning the authentication result to the client. Therefore, this invention achieves efficient and accurate user permission identification. Attached Figure Description

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

[0014] Figure 1 This is a schematic diagram illustrating the application environment of a user permission identification method provided in an embodiment of the present invention.

[0015] Figure 2 This is a flowchart illustrating a user permission identification method according to an embodiment of the present invention.

[0016] Figure 3 This is a schematic diagram of the program modules of a user permission identification device provided in an embodiment of the present invention.

[0017] Figure 4 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention.

[0018] Figure 5 This is another structural schematic diagram of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0019] 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.

[0020] It should be understood that, when used in this specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0021] It should also be understood that the term “and / or” as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0022] As used in this specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if [the described condition or event] is detected" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once [the described condition or event] is detected," or "in response to detection of [the described condition or event]."

[0023] Furthermore, in the description of this invention and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0024] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of the invention include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0025] It should be understood that the sequence number of each step in the following 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.

[0026] To illustrate the technical solution of the present invention, specific embodiments are described below.

[0027] An embodiment of the present invention provides a user permission identification method, which can be applied to, for example... Figure 1 In the application environment shown, the client and server communicate via a network. The client includes, but is not limited to, handheld computers, desktop computers, laptops, ultra-mobile personal computers (UMPCs), netbooks, cloud computing devices, and personal digital assistants (PDAs). The server can be a standalone server or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0028] Please see Figure 2 An embodiment of the present invention provides a user permission identification method, wherein the method includes the following steps: S100. Obtain the client's access request for the interface to be accessed, parse the access request, extract the user identifier, request path and additional behavioral context, and generate a user behavior profile fragment based on the additional behavioral context. S200. Input the request path into the dynamic feature perception engine to determine the interface risk heat value of the interface to be accessed, and determine the caching strategy of the interface to be accessed based on the interface risk heat value and the user behavior profile fragment. S300. According to the caching strategy, retrieve the permission data of the target user corresponding to the user identifier in the target cache and generate retrieval results; S400. Based on the search results, determine whether the target user can access the interface to be accessed, generate an authentication result, and return the authentication result to the client.

[0029] In practical implementation, the user permission identification method of this embodiment achieves efficient and accurate permission verification through refined steps. First, in step S100, the system acquires and parses the client's access request, extracting the user identifier, request path, and additional behavioral context. Simultaneously, it generates a user behavior profile fragment based on the additional behavioral context, providing rich contextual information for subsequent permission judgment. Next, in step S200, the system uses a dynamic feature perception engine to evaluate the interface risk heat value corresponding to the request path and dynamically determines the caching strategy based on the user behavior profile fragment. This dynamic strategy allows the system to flexibly determine the cache type based on the interface risk and user behavior, optimizing cache usage efficiency, reducing the number of database queries, and thus significantly improving response speed. In step S300, the system retrieves the user's permission data from the target cache according to the caching strategy and generates retrieval results. Finally, in step S400, the system determines whether the user has the right to access the interface based on the retrieval results, generates and returns the authentication result. The entire process not only improves efficiency by determining the caching strategy but also enhances the accuracy of permission judgment through risk perception and user behavior analysis, ensuring the efficiency and security of user permission identification.

[0030] Understandably, the user permission identification method provided in this embodiment of the invention can be applied to user permission identification scenarios in the medical and health field. The following is a specific example: Scene description: In the healthcare field, user access control is crucial because medical data contains a wealth of sensitive information, such as patient medical records, diagnoses, and treatment plans. Access to this information must be strictly controlled to ensure patient privacy is protected. At the same time, the high availability and low latency requirements of healthcare systems pose even greater challenges to user access control.

[0031] Specific examples: Suppose a hospital's electronic medical record system uses the user permission identification method of this invention. When a doctor requests access to a patient's detailed medical records through a client, the system first obtains the request and parses out the doctor's user identifier, request path, and additional behavioral context (such as access time, device information, etc.). Based on the additional behavioral context, the system generates a user behavior profile fragment, such as recording the doctor's access frequency and access time pattern.

[0032] Next, the system inputs the request path into the dynamic feature perception engine to determine the risk intensity value of the interface. Because the medical record interface involves highly sensitive data, its risk intensity value is relatively high. Combined with user behavior profile fragments, the system determines to adopt a local caching strategy.

[0033] The system retrieves the doctor's permission data from the local cache. If the data is present in the cache, the search result is returned directly; otherwise, the system queries the distributed cache or database and updates the local cache with the result. Finally, the system determines whether the doctor has permission to access the patient's medical records based on the retrieved permission data. If the doctor has permission, the system returns a successful authentication message and provides the medical record information; otherwise, it returns a failed authentication message and records the access attempt.

[0034] In this way, the hospital's electronic medical record system can quickly and accurately identify user permissions, ensuring the security and privacy of patient data, while meeting the low latency requirements of the medical scenario.

[0035] It is understood that the user permission identification method provided in this embodiment of the invention can also be applied to user permission identification scenarios related to the financial technology field. The following is a specific example: Scene description: In the fintech field, user access control is equally crucial. Fintech systems involve a large amount of financial transactions and sensitive data, such as user account information, transaction records, and fund flows. Access to this data must be strictly controlled to prevent data leaks and unauthorized access. At the same time, the high concurrency and high security requirements of fintech systems also pose greater challenges to user access control.

[0036] Specific examples: Suppose that the transaction management system of a fintech platform uses the user permission identification method of this invention. When a bank employee requests access to a customer's account balance and transaction details through a client, the system first obtains the request and parses out the employee's user identifier, request path, and additional behavioral context (such as access time, device information, etc.). Based on the additional behavioral context, the system generates a user behavior profile fragment, such as recording the employee's access frequency and access time pattern.

[0037] Next, the system inputs the request path into the dynamic feature perception engine to determine the risk intensity value of the interface. Because the account information interface involves highly sensitive data, its risk intensity value is relatively high. Combined with user behavior profile fragments, the system determines to adopt a local caching strategy.

[0038] The system retrieves employee permission data from the local cache. If the data is present in the cache, the search result is returned directly; otherwise, the system queries the distributed cache or database and updates the local cache with the result. Finally, the system determines whether the employee has permission to access the customer's account information based on the retrieved permission data. If the employee has permission, the system returns a successful authentication message and provides the account information; otherwise, it returns a failed authentication message and records the access attempt.

[0039] This method enables fintech platform transaction management systems to quickly and accurately identify user permissions, ensuring the security and privacy of financial data while meeting performance requirements in high-concurrency scenarios.

[0040] In other words, the user permission identification method of the present invention can effectively improve the efficiency and accuracy of permission management in the fields of healthcare and fintech. The method can meet the requirements of these two fields for low latency, high security and high concurrency, ensuring that users can only access the resources they are authorized to access.

[0041] Furthermore, in one embodiment, the user permission identification method, wherein obtaining the client's access request for the interface to be accessed, parsing the access request, extracting the user identifier, request path, and additional behavioral context, and generating a user behavior profile fragment based on the additional behavioral context, specifically includes the following steps: Receive the access request for the interface to be accessed initiated by the target user through the client; The access request is subjected to format validation and integrity checks; When both format validation and integrity checks pass, the access request is parsed to extract the user identifier, request path, and additional behavioral context. Based on a preset user behavior profile model, feature calculations are performed on the additional behavioral context to generate a user behavior profile fragment; wherein, the user behavior profile fragment is used to characterize the real-time behavioral risk level of the target user under the current access request.

[0042] In practice, the specific implementation process of the steps in this embodiment is roughly as follows: (1) Receiving access requests The system receives access requests from clients via a network interface. Clients send requests using the HTTP / HTTPS protocol, and the requests include the URL of the interface to be accessed, the request method (e.g., GET, POST), request headers (e.g., Authorization, Content-Type), and the request body (e.g., JSON, Form-data). The system needs to ensure it can handle multiple request types and record basic request information for subsequent processing.

[0043] (2) Format validation The system performs format validation on received requests to ensure they conform to the expected format specifications. The validation includes: Is the request method correct (e.g., is it a allowed GET or POST method)?

[0044] Does the request header contain the necessary fields (such as whether Content-Type is application / json)?

[0045] Is the request body format correct (e.g., is the JSON format valid)?

[0046] If the format validation fails, the system returns an error response (such as 400 Bad Request) and logs the error, indicating that the client's request format is incorrect.

[0047] (3) Integrity check The system performs integrity checks on requests that pass format validation to ensure that the requests have not been tampered with during transmission. The check methods include: Verify the signature of the request (e.g., HMAC-SHA-256 signature).

[0048] Verify the hash value of the request.

[0049] Use the TLS / SSL protocol to ensure secure transmission.

[0050] If the integrity check fails, the system returns an error response (such as 403 Forbidden) and logs a security message indicating that the request may have been tampered with.

[0051] (4) Parse request Once the format validation and integrity checks pass, the system begins parsing the request and extracting key information: Parse the request path to extract information such as the API name and parameters. For example, extract the version number v1, resource type users, and user ID {userId} from / api / v1 / users / {userId} / info.

[0052] Parse the request headers to extract user identifiers (such as tokens, cookies, etc.). For example, from Authorization:Bearer <token>Extract the user token.

[0053] Parse the request body to extract additional behavioral context and other necessary information.

[0054] Through the above steps, the system can efficiently and securely receive and parse client access requests, providing an accurate data foundation for subsequent caching strategy determination and user permission identification.

[0055] Furthermore, in one embodiment, the user permission identification method, wherein the step of inputting the request path into a dynamic feature perception engine to determine the interface risk heat value of the interface to be accessed, and determining the caching strategy of the interface to be accessed based on the interface risk heat value and the user behavior profile fragment, specifically includes the following steps: Parse the request path and extract the corresponding path information; The path information is input into the dynamic feature perception engine, which calculates the interface risk heat value based on a preset risk assessment model and in combination with the historical access frequency, sensitivity level and recent abnormal call count of the interface to be accessed. The interface risk heat value and the user behavior profile fragment are input into a preset cache decision model, and the cache decision model is used to perform weighted processing to output the cache strategy of the interface to be accessed; wherein, the cache strategy includes cache type, and the cache type includes local cache and distributed cache.

[0056] Furthermore, in the aforementioned user permission identification method, the step of inputting the path information into a dynamic feature perception engine, wherein the dynamic feature perception engine calculates an interface risk heat value based on a preset risk assessment model and in combination with the historical access frequency, sensitivity level, and recent abnormal call count of the interface to be accessed, including: Based on the path information, query the interface risk metadata database to read the historical access frequency, sensitivity level, and recent abnormal call count of the interface to be accessed; The historical access frequency, the sensitivity level, and the number of recent abnormal calls are normalized to generate corresponding risk sub-vectors, which are then concatenated to form the interface basic risk vector. The interface basic risk vector is input into the dynamic feature perception engine. The dynamic feature perception engine, based on a preset risk assessment model, performs a weighted calculation on the interface basic risk vector to obtain the interface risk heat value of the interface to be accessed.

[0057] In practice, the specific implementation process of the steps in this embodiment is roughly as follows: (1) Parse the request path and extract the corresponding path information. After receiving a request, the system first parses the request path and extracts key information from the path, such as the interface name, parameters, and version number.

[0058] Use path parsing tools or regular expressions to process paths to ensure accurate extraction of dynamic parameters and fixed parts.

[0059] (2) Query interface risk metadata database The system queries the interface risk metadata database based on the extracted path information.

[0060] Read the historical access frequency, sensitivity level, and recent abnormal call count of the interface to be accessed from the interface risk metadata database.

[0061] (3) Generate the interface basic risk vector The historical access frequency, sensitivity level, and recent abnormal call count are normalized to generate corresponding risk sub-vectors.

[0062] Normalization ensures that data from different dimensions are comparable; for example, normalizing all data to the range of 0-1.

[0063] The normalized risk sub-vectors are concatenated to form the interface basic risk vector.

[0064] (4) Calculate the interface risk heat value Input the interface-based risk vector into the dynamic feature perception engine.

[0065] The dynamic feature perception engine performs weighted calculations on the basic risk vector of the interface based on a preset risk assessment model.

[0066] Risk assessment models are typically mathematical models that take into account the impact of historical access frequency, sensitivity level, and recent abnormal call count on risk through weighted calculations.

[0067] The calculation result is the interface risk heat value, which reflects the current risk level of the interface to be accessed.

[0068] (5) Determine the caching strategy Input the interface risk heat value and user behavior profile fragments into the preset cache decision model.

[0069] The caching decision model outputs the caching strategy for the interface to be accessed through weighted processing.

[0070] Caching strategies include cache types, which include local caching and distributed caching.

[0071] Based on the interface risk intensity score and user behavior profile fragments, the caching decision model can determine the cache type for the interface to be accessed. For example, a high-risk interface may use a distributed cache to enhance security, while a low-risk interface may use a local cache to improve performance.

[0072] Through the above steps, the system can determine the caching strategy based on the risk characteristics of the interface to be accessed and user behavior, thereby achieving efficient and accurate user permission identification.

[0073] Furthermore, in one embodiment, the user permission identification method, wherein retrieving permission data of the target user corresponding to the user identifier from the target cache according to the caching strategy and generating retrieval results specifically includes the following steps: Based on the caching strategy, determine the type of the target cache corresponding to the interface to be accessed; When the target cache type is local cache, the permission data of the target user corresponding to the user identifier is retrieved from the local cache; When the target cache is a distributed cache, the target user's permission data is retrieved from the distributed cache. The search results are generated based on the target user's permission data retrieved from the local cache or distributed cache.

[0074] In practice, the specific implementation process of the steps in this embodiment is roughly as follows: (1) Determine the target cache type The system determines the type of target cache corresponding to the interface to be accessed based on the previously determined caching strategy. The caching strategy specifies the type of cache to be used by the interface (local cache or distributed cache).

[0075] If the caching strategy specifies that a local cache is used, then the target cache type is a local cache.

[0076] If the caching strategy specifies the use of distributed caching, then the target cache type is distributed cache.

[0077] (2) Retrieve permission data from the local cache If the target cache type is local cache, the system retrieves the permission data of the target user corresponding to the user identifier from the local cache.

[0078] Local caches are typically stored in the application server's memory, offering fast access speeds. The system uses the user identifier as a key to retrieve the corresponding permission data for the target user from the local cache.

[0079] (3) Retrieve permission data from the distributed cache If the target cache type is a distributed cache, the system retrieves the permission data of the target user corresponding to the user identifier in the distributed cache.

[0080] Distributed caches are typically deployed on standalone cache servers or clusters and accessed over a network. The system uses the user identifier as a key to retrieve the permission data corresponding to the target user from the distributed cache.

[0081] (4) Generate search results The search results are generated based on the permission data retrieved from the local cache or distributed cache.

[0082] If permission data is found in the cache, a search result containing the permission data is generated.

[0083] If the permission data is not found in the cache, a cache miss result is generated, and relevant information (such as user ID, interface path, etc.) is recorded.

[0084] (5) Handling cache misses (optional step) If the search results indicate a cache miss, the system can perform further operations as needed, such as querying permission data from the database and updating the cache.

[0085] If permission data is found in the database, the data is written to the target cache (local cache or distributed cache), and the search results are updated.

[0086] If no permission data is found in the database, record this situation and mark it as "Permission data does not exist" in the search results.

[0087] This step ensures that even if the cache is missed, the system can still provide accurate permission data and optimize subsequent access performance.

[0088] Through the above steps, the system can efficiently retrieve user permission data according to the caching strategy and generate accurate retrieval results, thereby supporting fast permission verification and response.

[0089] Furthermore, in one embodiment, the user permission identification method, wherein determining whether the target user can access the interface to be accessed based on the search results, generating an authentication result, and returning the authentication result to the client specifically includes the following steps: Parse the search results and extract the target user's permission data; Based on the target user's permission data, determine whether the target user has permission to access the interface to be accessed, and generate an authentication result; The authentication result is packaged according to a predetermined format and returned to the client.

[0090] Furthermore, in the aforementioned user permission identification method, the step of encapsulating the authentication result according to a predetermined format and returning it to the client specifically includes the following steps: The authentication result is formatted and encapsulated according to the client's result display requirements; The authentication result after format encapsulation is encrypted, and the encrypted authentication result is returned to the client.

[0091] In practice, the specific implementation process of the steps in this embodiment is roughly as follows: (1) Parse the search results and extract the target user's permission data. The system parses the received search results and extracts the target user's permission data.

[0092] The search results may include detailed information such as whether the user has permission to access a specific interface, the user's role, and permission level.

[0093] The system extracts necessary permission data from the search results, such as user ID, interface path, and access permission flags.

[0094] (2) Determine whether the target user has access rights and generate the authentication result. The system determines whether the target user has permission to access the interface to be accessed based on the extracted permission data.

[0095] Compare user permissions with the permission level required by the interface to determine whether the user has the right to access.

[0096] If the user has access rights, generate a successful authentication result; otherwise, generate a failed authentication result.

[0097] The authentication result usually includes a status code (e.g., 200 for success, 403 for forbidden access) and a description.

[0098] (3) Encapsulate the authentication results in a specific format according to the client's result display requirements. The system encapsulates the authentication results according to the client's result display requirements. The client's result display requirements may include the response format (such as JSON, XML), encoding method (such as UTF-8), and whether additional metadata is required.

[0099] Based on these requirements, the system converts the authentication results into the format expected by the client. The encapsulated authentication results should contain necessary information, such as status codes, descriptions, and user permission levels.

[0100] (4) Encrypt the authentication result after format encapsulation. The system encrypts the authentication results after format encapsulation to ensure data security during transmission.

[0101] Choose an appropriate encryption algorithm (such as AES, RSA, etc.) to encrypt the authentication result.

[0102] The encryption process should ensure that only the client can decrypt and read the authentication result.

[0103] (5) Return the encrypted authentication result to the client. The system returns the encrypted authentication result to the client through a secure communication protocol (such as HTTPS).

[0104] Ensure that the returned response conforms to the client's expected format and security requirements.

[0105] Through the above steps, the system can accurately determine user permissions based on the search results, generate and return secure and formatted authentication results, and ensure the accuracy and security of user permission identification.

[0106] As can be seen from the above method embodiments, the user permission identification method provided by the present invention includes: obtaining an access request from a client to an interface to be accessed, parsing the access request, extracting the user identifier, request path, and additional behavioral context, and generating a user behavior profile fragment based on the additional behavioral context; inputting the request path into a dynamic feature perception engine to determine the interface risk heat value of the interface to be accessed, and determining the caching strategy of the interface to be accessed based on the interface risk heat value and the user behavior profile fragment; retrieving the permission data of the target user corresponding to the user identifier in the target cache according to the caching strategy, and generating a retrieval result; determining whether the target user can access the interface to be accessed based on the retrieval result, generating an authentication result, and returning the authentication result to the client. Thus, the method of the present invention can achieve efficient and accurate user permission identification.

[0107] It should be understood that although this application provides the method operation steps as described in the embodiments or flowcharts, conventional or non-inventive labor may include more or fewer operation steps, and these operation steps are not necessarily executed sequentially according to the order of the embodiments or flowcharts. The order of steps listed in the embodiments or flowcharts is merely one way of executing many steps and does not represent the only execution order. It should be noted that there is no necessary sequential order between the above steps. Those skilled in the art can understand from the description of the embodiments of the present invention that the above steps may have different execution orders in different embodiments, that is, they may be executed in parallel or in exchange, etc. Moreover, at least some steps in the embodiments or flowcharts may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but may be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but may be executed in turn, alternately, or synchronously with other steps or at least a part of the sub-steps or stages of other steps.

[0108] Based on the above method embodiments, please refer to Figure 3 Another embodiment of the present invention also provides a user permission identification device, wherein the device includes: The acquisition module 11 is used to acquire the access request of the client to the interface to be accessed, parse the access request, extract the user identifier, request path and additional behavioral context, and generate a user behavior profile fragment based on the additional behavioral context. The determination module 12 is used to input the request path into the dynamic feature perception engine, determine the interface risk heat value of the interface to be accessed, and determine the caching strategy of the interface to be accessed based on the interface risk heat value and the user behavior profile fragment. The retrieval module 13 is used to retrieve the permission data of the target user corresponding to the user identifier in the target cache according to the caching strategy, and generate retrieval results; The judgment module 14 is used to determine whether the target user can access the interface to be accessed based on the search results, generate an authentication result, and return the authentication result to the client.

[0109] Furthermore, in one embodiment, the user permission identification device, wherein obtaining the client's access request for the interface to be accessed, parsing the access request, extracting the user identifier, request path, and additional behavioral context therein, and generating a user behavior profile fragment based on the additional behavioral context, specifically includes: Receive the access request for the interface to be accessed initiated by the target user through the client; The access request is subjected to format validation and integrity checks; When both format validation and integrity checks pass, the access request is parsed to extract the user identifier, request path, and additional behavioral context. Based on a preset user behavior profile model, feature calculations are performed on the additional behavioral context to generate a user behavior profile fragment; wherein, the user behavior profile fragment is used to characterize the real-time behavioral risk level of the target user under the current access request.

[0110] Further, in one embodiment, the user permission identification device, wherein inputting the request path into a dynamic feature perception engine to determine the interface risk heat value of the interface to be accessed, and determining the caching strategy of the interface to be accessed based on the interface risk heat value and the user behavior profile fragment, specifically includes: Parse the request path and extract the corresponding path information; The path information is input into the dynamic feature perception engine, which calculates the interface risk heat value based on a preset risk assessment model and in combination with the historical access frequency, sensitivity level and recent abnormal call count of the interface to be accessed. The interface risk heat value and the user behavior profile fragment are input into a preset cache decision model, and the cache decision model is used to perform weighted processing to output the cache strategy of the interface to be accessed; wherein, the cache strategy includes cache type, and the cache type includes local cache and distributed cache.

[0111] Furthermore, in the aforementioned user permission identification device, the step of inputting the path information into a dynamic feature perception engine, wherein the dynamic feature perception engine calculates an interface risk heat value based on a preset risk assessment model and in combination with the historical access frequency, sensitivity level, and recent abnormal call count of the interface to be accessed, including: Based on the path information, query the interface risk metadata database to read the historical access frequency, sensitivity level, and recent abnormal call count of the interface to be accessed; The historical access frequency, the sensitivity level, and the number of recent abnormal calls are normalized to generate corresponding risk sub-vectors, which are then concatenated to form the interface basic risk vector. The interface basic risk vector is input into the dynamic feature perception engine. The dynamic feature perception engine, based on a preset risk assessment model, performs a weighted calculation on the interface basic risk vector to obtain the interface risk heat value of the interface to be accessed.

[0112] Further, in one embodiment, the user permission identification device, wherein retrieving permission data of the target user corresponding to the user identifier from the target cache according to the caching strategy and generating retrieval results specifically includes: Based on the caching strategy, determine the type of the target cache corresponding to the interface to be accessed; When the target cache type is local cache, the permission data of the target user corresponding to the user identifier is retrieved from the local cache; When the target cache is a distributed cache, the target user's permission data is retrieved from the distributed cache. The search results are generated based on the target user's permission data retrieved from the local cache or distributed cache.

[0113] Furthermore, in one embodiment, the user permission identification device, wherein determining whether the target user can access the interface to be accessed based on the search result, generating an authentication result, and returning the authentication result to the client specifically includes: Parse the search results and extract the target user's permission data; Based on the target user's permission data, determine whether the target user has permission to access the interface to be accessed, and generate an authentication result; The authentication result is packaged according to a predetermined format and returned to the client.

[0114] Furthermore, in the aforementioned user permission identification device, the step of encapsulating the authentication result according to a predetermined format and returning it to the client specifically includes: The authentication result is formatted and encapsulated according to the client's result display requirements; The authentication result after format encapsulation is encrypted, and the encrypted authentication result is returned to the client.

[0115] It should be noted that, in the device embodiments of the present invention, the information interaction and execution process between the above modules are based on the same concept as in the method embodiments of the present invention. For details on their specific functions and the resulting technical effects, please refer to the aforementioned method embodiments section, which will not be repeated here.

[0116] Based on the above method embodiments, another embodiment of the present invention also provides a computer device, which can be a server, and its internal structure diagram can be as follows. Figure 4 As 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 a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements the functions or steps of the user permission identification method on the server side as described in any of the above method embodiments.

[0117] Based on the above method embodiments, another embodiment of the present invention also provides a computer device, which can be a client, and its internal structure diagram can be as follows. Figure 5 As shown, the computer device includes a processor, memory, network interface, display screen, and input device connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an 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 medium. The network interface is used to communicate with external terminals via a network connection. When executed by the processor, the computer program implements the functions or steps of the user permission identification method on the client side as described in any of the above method embodiments.

[0118] Those skilled in the art will understand that Figure 4 and Figure 5 The structural schematic diagram shown is only a schematic diagram of a part of the structure related to the present invention and does not constitute a limitation on the computer device on which the present invention is applied. The specific computer device may include more components than shown in the figure, or combine certain components, or have different component arrangements.

[0119] The processor referred to herein can be a CPU, but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0120] The memory includes readable storage media, internal memory, etc., where internal memory can be the RAM of a computer device. Internal memory provides an environment for the operation of the operating system and computer-readable instructions stored in the readable storage media. The readable storage media can be the hard drive of the computer device, or in other embodiments, it can be an external storage device of the computer device, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory can include both internal storage units and external storage devices of the computer device. The memory is used to store the operating system, applications, bootloader, data, and other programs, such as program code for computer programs. The memory can also be used to temporarily store data that has been output or will be output.

[0121] Based on the above method embodiments, another embodiment of the present invention provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the user permission identification method as described in any of the above method embodiments. The computer-readable storage medium may be non-volatile or volatile.

[0122] It should be noted that the functions or steps that can be achieved by the computer-readable storage medium or computer device, and the technical effects brought about by the functions / steps, can be referred to the relevant descriptions in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0123] 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, and when executed, it 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 can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various 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. The disclosed memory components or memories of the operating environment described herein are intended to include one or more of these and / or any other suitable types of memory.

[0124] Those skilled in the art will understand that, for the sake of convenience and brevity, the embodiments of the device of the present invention are only illustrated by the division of the above-mentioned functional units and modules. 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. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of the present invention. The specific working process of the units and modules in the above device can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here. If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium.

[0125] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0126] In the embodiments provided by this invention, it should be understood that the disclosed apparatus / computer devices and methods can be implemented in other ways. For example, the apparatus / computer device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0127] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0128] It should be noted that if any software tools or components not belonging to this company appear in the embodiments of this application, they are merely illustrative examples and do not represent actual use. The above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; 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; and these 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.< / token>

Claims

1. A user permission identification method, characterized in that, include: Obtain the client's access request for the interface to be accessed, parse the access request, extract the user identifier, request path and additional behavioral context, and generate a user behavior profile fragment based on the additional behavioral context. The request path is input into the dynamic feature perception engine to determine the interface risk heat value of the interface to be accessed, and the caching strategy of the interface to be accessed is determined based on the interface risk heat value and the user behavior profile fragment. According to the caching strategy, retrieve the permission data of the target user corresponding to the user identifier in the target cache and generate retrieval results; Based on the search results, it is determined whether the target user can access the interface to be accessed, an authentication result is generated, and the authentication result is returned to the client.

2. The user permission identification method according to claim 1, characterized in that, The process of obtaining the client's access request for the interface to be accessed, parsing the access request, extracting the user identifier, request path, and additional behavioral context, and generating a user behavior profile fragment based on the additional behavioral context includes: Receive the access request for the interface to be accessed initiated by the target user through the client; The access request is subjected to format validation and integrity checks; When both format validation and integrity checks pass, the access request is parsed to extract the user identifier, request path, and additional behavioral context. Based on a preset user behavior profile model, feature calculations are performed on the additional behavioral context to generate a user behavior profile fragment; wherein, the user behavior profile fragment is used to characterize the real-time behavioral risk level of the target user under the current access request.

3. The user permission identification method according to claim 1, characterized in that, The step of inputting the request path into the dynamic feature perception engine to determine the interface risk heat value of the interface to be accessed, and determining the caching strategy of the interface to be accessed based on the interface risk heat value and the user behavior profile fragment, includes: Parse the request path and extract the corresponding path information; The path information is input into the dynamic feature perception engine, which calculates the interface risk heat value based on a preset risk assessment model and in combination with the historical access frequency, sensitivity level and recent abnormal call count of the interface to be accessed. The interface risk heat value and the user behavior profile fragment are input into a preset cache decision model, and the cache decision model is used to perform weighted processing to output the cache strategy of the interface to be accessed; wherein, the cache strategy includes cache type, and the cache type includes local cache and distributed cache.

4. The user permission identification method according to claim 3, characterized in that, The path information is input into a dynamic feature perception engine. The dynamic feature perception engine, based on a preset risk assessment model and combined with the historical access frequency, sensitivity level, and recent abnormal call count of the interface to be accessed, calculates the interface risk heat value, including: Based on the path information, query the interface risk metadata database to read the historical access frequency, sensitivity level, and recent abnormal call count of the interface to be accessed; The historical access frequency, the sensitivity level, and the number of recent abnormal calls are normalized to generate corresponding risk sub-vectors, which are then concatenated to form the interface basic risk vector. The interface basic risk vector is input into the dynamic feature perception engine. The dynamic feature perception engine, based on a preset risk assessment model, performs a weighted calculation on the interface basic risk vector to obtain the interface risk heat value of the interface to be accessed.

5. The user permission identification method according to claim 1, characterized in that, The step of retrieving the permission data of the target user corresponding to the user identifier in the target cache according to the caching strategy and generating retrieval results includes: Based on the caching strategy, determine the type of the target cache corresponding to the interface to be accessed; When the target cache type is local cache, the permission data of the target user corresponding to the user identifier is retrieved from the local cache; When the target cache is a distributed cache, the target user's permission data is retrieved from the distributed cache. The search results are generated based on the target user's permission data retrieved from the local cache or distributed cache.

6. The user permission identification method according to claim 1, characterized in that, The step of determining whether the target user can access the interface to be accessed based on the search results, generating an authentication result, and returning the authentication result to the client includes: Parse the search results and extract the target user's permission data; Based on the target user's permission data, determine whether the target user has permission to access the interface to be accessed, and generate an authentication result; The authentication result is packaged according to a predetermined format and returned to the client.

7. The user permission identification method according to claim 6, characterized in that, The step of encapsulating the authentication result according to a predetermined format and returning it to the client includes: The authentication result is formatted and encapsulated according to the client's result display requirements; The authentication result after format encapsulation is encrypted, and the encrypted authentication result is returned to the client.

8. A user permission identification device, characterized in that, include: The acquisition module is used to acquire the client's access request to the interface to be accessed, parse the access request, extract the user identifier, request path and additional behavioral context, and generate user behavior profile fragments based on the additional behavioral context. The determination module is used to input the request path into the dynamic feature perception engine, determine the interface risk heat value of the interface to be accessed, and determine the caching strategy of the interface to be accessed based on the interface risk heat value and the user behavior profile fragment. The retrieval module is used to retrieve the permission data of the target user corresponding to the user identifier in the target cache according to the caching strategy, and generate retrieval results; The judgment module is used to determine whether the target user can access the interface to be accessed based on the search results, generate an authentication result, and return the authentication result to the client.

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 user permission identification method as described in any one of claims 1-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 user permission identification method as described in any one of claims 1-7.

Images