Data access method, apparatus, device, and storage medium

Abstract

Embodiments of the present disclosure provide a method, apparatus, device and storage medium for data access. The method comprises: obtaining an authentication context for authenticating a request, the request being issued to a current service and being for data access, the authentication context being generated based on at least one of the request or a response to the request generated by the current service; generating an authentication result for the request based on the authentication context and at least one authentication policy; and providing feedback corresponding to the authentication result to proxy the current service to respond to the request. In this way, while achieving access control for data, the cost can be effectively reduced, the efficiency of data access can be improved, and the latency of data access can be reduced.

Description

Technical Field

[0001] The exemplary embodiments disclosed herein relate generally to the field of computers, and more particularly to data access methods, apparatus, devices, and computer-readable storage media. Background Technology

[0002] Intelligent services are built upon the collection and use of big data. Various regions have enacted numerous laws and regulations related to data protection, requiring products providing intelligent services to protect data during its use. Therefore, effective data protection solutions are needed for online network requests that allow users to access their data. Summary of the Invention

[0003] In a first aspect of this disclosure, a data access method is provided. The method includes: obtaining an authentication context for authenticating a request, the request being issued to a current service and for data access, the authentication context being generated based on at least one of the request or a response to the request generated by the current service; generating an authentication result for the request based on the authentication context and at least one authentication policy; and providing feedback corresponding to the authentication result to proxy the current service in responding to the request.

[0004] In a second aspect of this disclosure, a data access apparatus is provided. The apparatus includes: a context acquisition module configured to acquire an authentication context for authenticating a request, the request being issued to a current service and for data access, the authentication context being generated based on at least one of the request or a response to the request generated by the current service; an authentication result generation module configured to generate an authentication result for the request based on the authentication context and at least one authentication policy; and a feedback providing module configured to provide feedback corresponding to the authentication result, thereby acting on behalf of the current service in responding to the request.

[0005] In a third aspect of this disclosure, an electronic device is provided. The device includes at least one processing unit; and at least one memory coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit. When executed by the at least one processing unit, the instructions cause the device to perform the method of the first aspect.

[0006] In a fourth aspect of this disclosure, a computer-readable storage medium is provided. A computer program is stored on the medium, which, when executed by a processor, implements the method of the first aspect.

[0007] It should be understood that the content described in this summary section is not intended to limit the key or essential features of the embodiments of this disclosure, nor is it intended to restrict the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0008] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. In the drawings, the same or similar reference numerals denote the same or similar elements, wherein:

[0009] Figure 1 A schematic diagram of an example environment in which embodiments of the present disclosure can be implemented is shown;

[0010] Figure 2 A schematic diagram of an example architecture of a data access system according to some embodiments of the present disclosure is shown;

[0011] Figure 3A A schematic diagram of a data flow for data access according to some embodiments of the present disclosure is shown;

[0012] Figure 3B A schematic block diagram of a data access system according to some embodiments of the present disclosure is shown;

[0013] Figure 4A A schematic diagram of an example interface for label settings according to some embodiments of the present disclosure is shown;

[0014] Figure 4B A schematic diagram of an example interface with annotation settings according to some embodiments of the present disclosure is shown;

[0015] Figure 5 A flowchart illustrating a data access process according to some embodiments of the present disclosure is shown;

[0016] Figure 6 A block diagram of a data access apparatus according to some embodiments of the present disclosure is shown; and

[0017] Figure 7 An electronic device in which one or more embodiments of the present disclosure may be implemented is shown. Detailed Implementation

[0018] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0019] In the description of embodiments of this disclosure, the term "comprising" and similar terms should be understood as open-ended inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The term "some embodiments" should be understood as "at least some embodiments". Other explicit and implicit definitions may also be included below.

[0020] In this document, unless explicitly stated otherwise, performing a step in response to A does not mean that the step is performed immediately after A, but may include one or more intermediate steps.

[0021] It is understood that the data involved in this technical solution (including but not limited to the data itself, the acquisition or use of the data) shall comply with the requirements of relevant laws, regulations and related provisions.

[0022] It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure through appropriate means in accordance with relevant laws and regulations, and user authorization should be obtained.

[0023] For example, in response to receiving a user's active request, a prompt message is sent to the user to clearly inform the user that the requested operation will require the acquisition and use of the user's personal information, thereby enabling the user to choose whether to provide personal information to the software or hardware such as electronic devices, applications, servers or storage media that perform the operation of the technical solution disclosed herein, based on the prompt message.

[0024] As an optional but non-restrictive implementation, in response to a user's active request, a prompt message can be sent to the user, such as a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0025] It is understood that the above notification and user authorization process are merely illustrative and do not constitute a limitation on the implementation of this disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure.

[0026] As used herein, the term "authentication" refers to verifying whether the party initiating a data access request (e.g., an end user) has the necessary permissions to access the data. The term "authentication policy" refers to one or more rules used for authentication. In this document, the terms "policy" and "rule" are used interchangeably.

[0027] Figure 1A schematic diagram of an example environment 100 in which embodiments of this disclosure can be implemented is shown. In environment 100, business requests (i.e., data access requests) from clients typically originate from an access layer (such as a gateway layer, not shown). The access layer routes traffic from the client. After routing, the request enters application layer 110. Application layer 110 assembles the data required by the client, for which it requests lower-level service nodes, i.e., one or more services. That is, application layer 110 accesses the data source through one or more services. One or more services retrieve data from the lowest-level data source and then return the data to the upper layer. At the lowest level, i.e., the database layer, stored data is provided for upstream use. Such data may include data that needs to be protected (also known as protected data).

[0028] One or more services may include, for example, services 120-1, 120-2, 120-3, ..., 120-N (collectively or individually referred to as services 120) for handling different business logic, where N is a positive integer. The different services 120 coordinate and cooperate with each other. Each service 120 runs in its own independent process, and services communicate with each other using lightweight communication mechanisms. Each service is built around a specific business function and can be deployed independently. In one example, service 120 could be a microservice. A microservice is an application composed of many smaller, loosely coupled services.

[0029] The data source can be the database used by the database application or a database server. Figure 1 In the example, the data sources include database 130-1, database 130-2, database 130-3, ..., database 130-N (collectively or individually referred to as database 130).

[0030] For example, user A visits user B's homepage and sends a request through application layer 110 to view user B's birthday. Service 120 receives the request and accesses database 130 to read user B's birthday data. Then, it returns a response containing user B's birthday data to application layer 110.

[0031] Environment 100 may also include a Hypertext Transfer Protocol (HTTP) service (not shown). In some embodiments, service 120 may be a Remote Procedure Call (RPC) service. For example, when a user sends a request to access data via application layer 110, the HTTP service internally obtains the user's identity through methods such as session_lib and calls the downstream RPC service to access database 130 to implement business logic.

[0032] It should be understood that the structure and functionality of the example environment 100 are described for illustrative purposes only and do not imply any limitation on the scope of this disclosure.

[0033] As briefly mentioned above, Figure 1 Service 120 in the text can be a microservice. A microservice is an architecture and organizational method for developing software. Software consists of multiple small, independent services that communicate through well-defined Application Programming Interfaces (APIs). Each service runs in its own independent process, and services communicate with each other using lightweight communication mechanisms. Each service is built around a business function; in other words, each service performs one function. Therefore, individual services can be updated, deployed, and extended to meet the application's specific functional requirements.

[0034] Currently, due to the autonomy and specialization of microservices, the application of microservice architecture is becoming increasingly widespread. Under a microservice architecture, the scenarios of calls and interactions between different services are quite complex; therefore, the protection of data (e.g., user data) is particularly important.

[0035] In some cases, microservice architectures employ data access control to protect data (e.g., protected data). Traditionally, three data access control schemes exist. In the first scheme, logical control modules corresponding to each service are distributed across independently running services. These independent logical control modules manage access to the data accessed by the services corresponding to them, thus protecting the data. In other words, each service, belonging to a specific function, manages its own data access. In the second scheme, a centralized service is established between the independently running services and the data source, using this centralized service to protect the data. Specifically, before retrieving data from the data source, each service, belonging to a specific function, obtains authorization to access the data by accessing this centralized service, thus managing data access. In the third scheme, a standardized software development kit (SDK) is uniformly integrated into each independently running service. The SDK authenticates data access requests and obtains authentication results. Services, belonging to different functions, can access the SDK simultaneously and adjust the request results based on the SDK's authentication results, thus managing data access for each service.

[0036] However, these traditional solutions have some problems. Firstly, for the first and third solutions, since each service, belonging to a different function, handles business logic independently and is not interdependent, the control logic for data access management is inconsistent. Furthermore, this control logic relies on the developers' conscientiousness, leading to higher costs for developing, maintaining, and optimizing the microservice architecture. For the second solution, adding an access node (e.g., a centralized service) between the independently running services not only limits the scalability of the entire microservice architecture but also increases access latency and reduces data access efficiency. In addition, the control logic also depends on the service developers' conscientiousness.

[0037] According to embodiments of this disclosure, a data access scheme is proposed. According to this scheme, an authentication context is generated based on at least one of a request issued to the current service for data access or a response generated by the current service to the request. Further, the authentication context is obtained, and an authentication result for the request is generated based on the authentication context and at least one authentication policy. Feedback corresponding to the authentication result is provided to proxy the current service's response to the request. For example, if the authentication result indicates that the request is rejected, negative feedback (e.g., a response denying data access) is provided. If the authentication result indicates modification, an updated response is provided. If the authentication result indicates success, a response generated by the current service is provided.

[0038] In this way, data access requests sent to various services are uniformly and standardized for authentication. This not only enables access control for data but also effectively reduces costs (e.g., the cost of developing, maintaining, and optimizing microservice architectures), improves the efficiency of data access, and reduces the latency of data access.

[0039] The following description will continue with reference to the accompanying drawings, which will provide some exemplary embodiments of this disclosure.

[0040] Figure 2 A schematic diagram of an example architecture of a data access system 200 according to some embodiments of the present disclosure is shown. The data access system 200 includes distributed modules 210-1, 210-2, 210-3, ..., 210-N (collectively referred to as distributed modules 210) and a control module 220. The data access system 200 can be implemented in environment 100. Reference is made below. Figure 1 Describe the data access system 200.

[0041] Distributed module 210 is used for authentication, that is, verifying whether a user has the permission to access data. For example, distributed module 210 parses requests, responses, and authentication context from incoming traffic. Distributed module 210 constructs authentication input based on the authentication context, executes the authentication policy (also simply called the policy), and performs corresponding authentication actions based on the authentication result. Distributed module 210 can be deployed or implemented on the same host as the service it is responsible for authenticating.

[0042] Authentication input includes information about the requester, the requester, and contextual information. Information about the requester includes, for example, which user and application the request originated from, the Product Subsys Module (PSM) identifiers of the first and previous hops, the requester's location, the URL from which the request was initiated, and the path from which the request was initiated. Information about the requester includes, for example, which application or service to access, and which user. Contextual information includes, for example, the relationship between the requester and the requester, and what information was accessed.

[0043] Authentication strategies include, for example, allowing minors' information to be accessed only by PSM users who have bound a specific data key, or allowing users' birthday information on a platform to be accessed only by their friends, and so on.

[0044] The authentication process includes executing corresponding actions based on the results of the authentication policy, modifying the response information, and returning the correct information. These actions may include, for example, erasing or intercepting one or more fields.

[0045] As an example, user A visits user B's homepage to view their birthday information. Distributed module 210 extracts the authentication context and confirms that user A wants to access user B's birthday information, but user A and user B are not friends. Based on the authentication policy that a user's birthday information can only be accessed by their friends, it is determined that user A does not have permission to view user B's birthday information. Therefore, the action of erasing the birthday information is executed, and a new response is returned.

[0046] Distributed module 210 can be mounted on service 120 and run as a process partially independent of service 120 within the business instance. This reduces call latency and eliminates performance bottlenecks and stability issues caused by centralization. Furthermore, since service 120 is closer to database 130, data can be protected at the data source, preventing data leakage.

[0047] The control module 220 can be an independent configuration platform used to receive and distribute user configurations. Administrators or security teams can use the control module 220 to set policies such as traffic control, security, or access control. For example, an administrator can use the control module 220 to configure authentication policies or operational settings for the distributed module 210-1. The control module 220 transmits instructions, encapsulates data, and forwards it, thus distributing the configuration to the distributed module 210. The distributed module 210 can dynamically manipulate data based on the distributed configuration to achieve online data protection. Furthermore, multiple distributed modules 210 can share the control module 220.

[0048] Figure 3A A schematic diagram of a data flow 300A for data access according to some embodiments of the present disclosure is shown. The data flow 300A can be implemented at the data access system 200. For ease of discussion, reference will be made to... Figure 2 The data access system 200 is used to describe the data flow 300A.

[0049] Application layer 110 issues a request 301 for data access to a service (also called the current service). For example, request 301 could originate from an upstream service of the current service. For instance, if the current service 120 is an RPC service, the request issued by the RPC service could be an RPC request. As an example, the request could include identity information. As described above, identity information includes, for example, information about the request initiator, the requester, and context information. Next, data access system 200 can use a handler to process request 301 using business logic. For example, the handler could be an RPC Handler. After processing the request using business logic 360 corresponding to the current service, a request to access data is issued to database 130 to retrieve the corresponding data. The retrieved data may contain data that needs protection. Database 130 returns a response to the accessed data. The handler processes the response to the accessed data to generate the original response.

[0050] The above describes the general process of data access. The data access system 200 can manage and control data access for each service through the control module 220 and the distributed modules 210 corresponding to each service. The distributed module 210 is used to authenticate requests sent to the current service for data access, generate authentication results, and provide feedback corresponding to the authentication results, thereby proxying the current service 120 to respond to the requests. As an example, in... Figure 3AIn this module, distributed module 210 receives a request 301 sent to the current service. Distributed module 210 may include access point module 330 and update module 340. Access point module 330 can be configured to provide access methods to the service. That is, distributed module 210 accesses the current service 120 through access point module 330, enabling the current service 120 to use various functions of distributed module 210 (e.g., authentication function). Access point module 330 is configured to obtain an authentication context for authenticating the request. Access point module 330 sends the authentication context to update module 340. Update module 340 is configured to generate an authentication result for the request based on the authentication context and at least one authentication policy. Update module 340 returns the authentication result to access point module 330, which provides feedback corresponding to the authentication result to proxy the current service request for response. It is understood that the distributed module 210 can be implemented in ways including but not limited to the access point module 330 and update module 340 described above, and can also be implemented with any appropriate number of other modules with different functions. This embodiment does not impose any specific limitations.

[0051] like Figure 3A As shown, the access point module 330 may include a data extraction module 331. The data extraction module 331 processes the original response to request 301 generated by request 301 or service 120 to obtain an authentication context for authenticating the request. As an example, the authentication context may include standardized information. For example, the standardized information may be information with a predetermined format and type (explained in more detail below). Specifically, in Figure 3A In the example, the data extraction module 331 can parse the request 301 or the original response to obtain the original authentication context. In some embodiments, the data extraction module 331 can further convert the original authentication context into a standard authentication context. After parsing, as described above, the data access system 200 can use the handler to perform the business logic processing on the request as described above. At this time, the distributed module 210 will not interfere with the business logic processing flow. After the business logic processing of the request is performed, the original response of the request is returned to the distributed module 210.

[0052] The access point module 330 may also include an action module 332 and a routing module 333. The routing module 333 determines whether authentication of request 301 is required based on routing rules and request information (e.g., the request's identity information). For example, if the request originates from a specific authorized application (e.g., a social application), authentication is not required. If request 301 originates from a non-specific website or application, authentication is required. If request 301 does not require authentication, the original response to request 301 can be provided directly; for example, the original response can be directly returned to the upstream service. If request 301 requires authentication, the routing module 333 sends the original response to the data extraction module 331. The data extraction module 331 extracts information from the original response and uses it together with the information extracted from request 301 as the authentication context. Alternatively, if request 301 is a read request, authentication information may not be extracted from request 301 before request 301 enters the business logic 360; instead, authentication information can be extracted together with the original response to generate the authentication context.

[0053] Next, the authentication context can be provided to the update module 340 via the action module 332. For example, the action module 332 initiates an authorization check for request 301 to the update module 340. Specifically, the action module 332 sends the authentication context obtained by the data extraction module 331 from parsing request 301 and the original response to the update module 340, so that the update module 340 can authenticate request 301.

[0054] The update module 340 generates an authentication result for request 301 based on the authentication context and at least one authentication policy. The update module 340 may include an authentication module 341 and at least one policy loader. Figure 3A In the example, the policy loader includes, for example, policy loader 350-1, policy loader 350-2... policy loader 350-N (which are also collectively or individually referred to as policy loader 350). Each policy loader 350 is used to apply the corresponding authentication policy to the authentication context.

[0055] In some embodiments, the authentication module 341 can be configured to convert the original authentication context into a standard authentication context. That is, either the data extraction module 331 or the authentication module 341 can convert (e.g., encapsulate) the original authentication context to obtain a standard authentication context. The authentication module 341 selects a corresponding policy loader from multiple policy loaders to perform authentication based on the authentication context (e.g., the standard authentication context), thereby generating an authentication result for request 301. Alternatively, the authentication module 341 can also select a set of multiple policy loaders from multiple policy loaders to perform authentication based on the authentication context. Specifically, the authentication module 341 can traverse all policy loaders in the set to determine multiple policy loaders associated with request 301, and then use these policy loaders to generate multiple intermediate authentication results. Then, the multiple intermediate authentication results are aggregated to generate the final authentication result.

[0056] The update module 340 returns the authentication result to the access point module 330. The action module 332 in the access point module 330 can provide corresponding feedback based on the authentication result returned by the update module 340 for request 301. Such feedback can proxy the current service's response to request 301. For example, if the authentication result indicates rejection of the request, negative feedback (e.g., a response denying data access) is provided. If the authentication result indicates modification, an updated response is provided. If the authentication result indicates success, a response generated by the current service is provided. In other words, such feedback can replace the original response returned to the upstream service. In some embodiments, the access point module 330 provides feedback via at least one of the following: a proxy for handling communication between the current service and other services, or middleware located between the current service and the application layer. A communication proxy is, for example, a wireless mesh network (e.g., Mesh Sidecar). Middleware between the current service and the application layer is, for example, middleware in different languages ​​(e.g., the KiteX framework for Go, the Spring Boot framework for Java).

[0057] The data extraction module 331, routing module 333, action module 332, and update module 340 described above can be considered as the data plane. The control module 220 can be a module independent of each service. The control module 220 and the distributed module 210 can be decoupled. The control module 220 is used to generate authentication configuration information and send the configuration information to the distributed module 210 for configuration. In some embodiments, the configuration information indicates at least one of the following: one or more fields used for authentication in the request (e.g., protected fields, value fields, annotation information for authentication fields), one or more fields used for authentication in the response (e.g., protected fields, value fields, annotation information for authentication fields), or conditions requiring authentication for the request. For example, conditions requiring authentication for a request may include fields or data that need to be protected in the response to the request, such as protected fields, protected data, etc. In this way, administrators or security teams can adjust the configuration of data access control through the control module 220.

[0058] Control module 220 can send configuration information, such as authentication policies, to update module 340. For example, control module 220 can periodically send updated authentication policies to update module 340. Alternatively, if the authentication policy is updated, control module 220 can immediately send the updated authentication policy to update module 340. Thus, update module 340 can dynamically update the authentication policy based on configuration information without adjusting the business logic code. Control module 220 can also send configuration information (such as routing rules) to routing module 333. Thus, routing module 333 can dynamically update routing rules based on configuration information to determine which requests require authentication. In some embodiments, control module 220 may include labeling module 371, observation module 372, publishing module 373, and routing module 374. This will be described in more detail below.

[0059] refer to Figure 2 and Figure 3A This describes how a distributed module 210 authenticates requests and provides feedback (e.g., rejection, modification, approval) based on the authentication result to effectively protect the protected data being accessed. The above only provides an example of the data flow for data access; it is understood that the implementation of the access point module 330 and the update module 340 can be including, but not limited to, those described above, and can also be implemented with any appropriate number and functionality of other modules.

[0060] The above references Figure 3A The data access process is described from the perspective of data flow. See below for reference. Figure 3B Let's take a closer look at the functions of each module in the data access system 200. Figure 3BA schematic block diagram of a data access system according to some embodiments of the present disclosure is shown. For example... Figure 3B As shown, the data access system 200 can generally include an access point 320, a data plane 390, and a control plane 330. The access point 320 and data plane 390 can be implemented as distributed modules 210, and the control plane 330 can be implemented as a control module 220. The services managed by the data access system 200 can include various suitable types of services, such as, but not limited to, BIZ services, platform services, Cronjob services, API services, etc.

[0061] Access point 320 is designed to provide services with access methods that utilize authentication functionality. Access point 320 can be configured to offer multiple access methods for the business logic within a service, allowing different services to choose the appropriate access method based on their specific business logic. For example, access methods may include wireless mesh networks or middleware in different languages. That is, services can utilize the functionality of distributed module 210 through wireless mesh networks or middleware in different languages. Diverse access methods reduce interference with service code (e.g., user code) while improving control over data (e.g., user data). Access point 320 can also be further configured to provide standardized access methods for the service's business logic, enabling services to access the service according to standardized procedures based on their business logic.

[0062] In this embodiment, the distributed module 210 accesses service 120 through various access methods provided by access point 320, requiring little or no code modification and resulting in low access costs. For example, if accessing service 120 via the sidecar mode, no code modification is required for the business logic within service 120. If accessing service 120 via middleware, minimal code modification is needed for the business logic within service 120. Compared to the existing first and third solutions described above, this significantly reduces code modification costs.

[0063] In some embodiments, the data plane 390 is used to obtain an authentication context by parsing the request and / or response, and to determine whether authentication is required based on the authentication context. Further, the data plane 390 can perform authentication based on the authentication context and at least one authentication policy to obtain an authentication result, and adjust the response to the request (i.e., the original response) according to the authentication result, returning the adjusted response to the application layer 110. The data plane 390 may include a data extraction module 331, a routing module 333, an update module 340, and an action module 332.

[0064] The data extraction module 331 can be configured to extract authentication context for requests and / or responses. Authentication context includes, for example, terminal traffic identity context, request destination context, and request source context. The authentication context determines which user the current request originates from, which service initiated it, and which data from which service is to be accessed. In some embodiments, the authentication context can be standardized, for example, it may include predefined type information. Predefined type information includes, for example, at least one of the following: identity information related to the initiation of the request (also known as traffic identity information), upstream and downstream information related to the upstream and downstream services of the current service, or subject information related to the authentication subject in the request.

[0065] As an example, the data extraction module 331 can encapsulate the extracted authentication context (i.e., the original authentication context) to obtain a standard authentication context (e.g., predefined type information). Exemplarily, the data extraction module 331 can encapsulate the extracted authentication context into three types of predefined type information.

[0066] Identity information can be implemented as traffic identity markers, for example. Traffic identity information represents the source identity of this traffic, that is, the origin of the traffic. Traffic identity information can include the initiating user identifier, the initiating API address, the initiating user's identity, the initiating service node, etc. Specifically, traffic identity information can include: Meta tag (an auxiliary tag in the HTML head section) information, such as protocol-related information; user-related information, such as user-dimensional information related to the traffic, which can identify which user the traffic comes from; device-related information, such as device-dimensional information related to the traffic, which can identify which device the traffic comes from; geographic information, such as parameters related to user data accounts, which can identify the data center, region, etc., where the user data is located; application-related information, such as information related to the application to which the traffic belongs, which can identify which application the traffic comes from; service-related information, such as information related to the starting service of the traffic, which can identify the entry API service information of the traffic; request-related information, such as information related to the request of the traffic, which can identify the domain name or request path of the traffic; and scenario-related information, such as scenario attribute information of the traffic, which can identify whether the traffic belongs to stress testing traffic.

[0067] Upstream and downstream information can be implemented as RPC Endpoint Information, which represents the previous and next hop information of the current request. Upstream and downstream information can include information about upstream services, such as service name, service address, and service invocation method. It can also include information about downstream services, such as service name, service address, and service invocation method.

[0068] The subject information can be implemented as authentication point information. For example, authentication point information represents the location information expected to be authenticated within this request, including the fields that need to be authenticated and their corresponding values. In other words, the subject information includes the minimum dimension of this authentication, and the related indivisible data contained within that minimum dimension. For example, the subject information can include authentication points and authentication elements. An authentication point represents the scope of the current authentication subject, and an authentication element represents a single element of the current authentication subject. For example, an authentication point can include the name of the authentication scope, the authentication scope path, the protected fields contained in the current authentication scope, and all authentication subject elements contained in the current authentication scope. An authentication element can include the authentication subject element index and a graph of constant values ​​for the authentication subject elements.

[0069] In some embodiments, the data extraction module 331 receives configuration information for data annotation sent by the control plane 390 (described in detail below), and parses the request and the response to the request according to the configuration information to obtain the original authentication context. The original authentication context is then encapsulated into a standard authentication context for use by the update module 340.

[0070] The routing module 333 can be configured to route requests. If a request is routed, it is authenticated; otherwise, the response can be directly returned to the application layer 110. In some embodiments, the routing rules may include at least one of the following: degradation routing rules, canary routing rules, sampling routing rules, and refined terminal request marking routing rules. A degradation routing rule means that when a service fails or its corresponding loader is downgraded, a degradation effect is achieved, and the request does not need to be authenticated; it directly returns to the application layer 110. A canary routing rule means that when a service exists in different data centers, the routing rules can be controlled to apply only to a subset of data centers. Requests to services in these data centers can be authenticated, while requests to services in other data centers can be unauthenticated. A sampling routing rule means that the distributed module 210 also provides a percentage-based sampling logic; only traffic within the sample will proceed to the next stage of authentication logic. The refined terminal request routing rules mean that the distributed module 210 will also determine whether a route has been hit based on the terminal traffic identity information extracted by the data extraction module 331. For example, if the terminal user is online, their request will hit the routing rules, thus authenticating the request. If the terminal user is offline, their request will not hit the route, and therefore no authentication will be performed.

[0071] The update module 340 can be configured to generate an authentication result for a request based on the authentication context and at least one authentication policy. That is, the update module 340 is used to implement the authentication logic process. The business logic process and the authentication logic process are independent processes. They can execute in parallel or adaptively according to set rules; the scope of this disclosure does not specifically limit this. The authentication logic process can be deployed on the same host as the business logic process. The authentication logic process can use the same environment resources as the business logic process; for example, in the distributed module 210, they rely on the same environment resources. Because the authentication logic process is close to the business logic process on the same host, there is no significant delay in communication between them. By separating the authentication logic process from other logic processes (e.g., the business logic process), the code complexity of different logic processes is reduced. For example, the update module 340 can be implemented using the sidecar pattern, which has the specificity of hot updates. In this way, the authentication logic process better serves the business logic process. The authentication logic can be dynamically changed without adjusting the business logic code.

[0072] In some embodiments, at least one authentication policy is selected from pre-configured candidate authentication policies based on identity information. For example, a request arriving at the distributed module 210 may originate from multiple tenants (e.g., tenant A, tenant B, and tenant C). The distributed module 210 determines which tenant the request originates from (e.g., from tenant A) based on the identity information of these requests, and selects one or more authentication policies configured for tenant A from among the multiple candidate authentication policies to authenticate the user's request / response to access data.

[0073] Considering the standardized authentication context and standardized access method described above, the distributed module 210 can also be configured with a standardized authentication strategy. The update module 340 in the data plane is controlled to send pre-configured candidate authentication strategies (i.e., standardized authentication strategies). The update module 340 authenticates the request based on the standardized authentication context and standardized authentication strategy, obtaining the authentication result.

[0074] In some embodiments, the update module 340 determines the authentication element as the authentication object and the protected field of the protected data including the authentication element from the authentication context; and selects the target authentication action to be performed on the response from a plurality of predetermined authentication actions as the authentication result by applying at least one authentication policy to the authentication element and the protected field. The protected field includes protected data. The authentication object (also called the authentication subject) may include one or more authentication elements. An authentication element refers to a single element of the authentication subject mentioned above, such as a single user.

[0075] Pre-defined authentication actions can include standardized adjustments to the original response, such as modification, rejection, and approval. Approval means the request passes normally without any adjustment to the request or response. Rejection means the request is blocked, preventing any data from being returned to the client. Modification means modifying the request, potentially changing fields of all elements or a specific field of a single element. Standardized modification actions can include erasing all fields, erasing fields of a single element, modifying all fields, erasing fields of a single element, and so on. Therefore, standard authentication strategies are applied to authentication elements and protected fields, and the target authentication action to be performed on the response is selected from the standardized authentication actions as the standard authentication result for the authentication elements and protected fields. Regardless of the service, request, or access method, the authentication actions and results are standardized, predictable, and enumerable.

[0076] In some embodiments, multiple predetermined authentication actions include two or more of the following: providing a response; preventing the provision of a response, preventing protected data from being provided with the response. In the case of providing a response, action module 332 passes the original response normally without any adjustments. In the case of preventing the provision of a response, action module 332 intercepts the original response, disallowing any user data from returning to application layer 110, thereby preventing any user data from returning to the user's client. In the case of preventing protected data from being provided with the response, action module 332 erases, modifies, simultaneously modifies and erases, or removes elements from the original response to prevent protected data from returning to application layer 110 with the original response. For example, action module 332 can modify fields of all elements in the original response. Alternatively, action module 332 can modify a field of a specific element. For example, a field in the original response can be modified to another value. Alternatively, action module 332 can erase a field in the original response to the zero value of that field. Alternatively, action module 332 can simultaneously modify and erase the original response. For example, some fields in the original response can be erased, and others can be modified. In the case of erasing elements, if the original response returned multiple elements, action module 332 can directly remove one of the elements.

[0077] As described above, the control plane can send multiple authentication policies to the update module 340, enabling the update module 340 to determine the target authentication action based on these policies. The update module 340 first generates multiple intermediate authentication results based on each authentication policy, for example, selecting one from a set of predetermined authentication actions. Then, the update module 340 aggregates these intermediate authentication results into a final authentication result. For example, in some embodiments, the update module 340 selects a first authentication action from a set of predetermined authentication actions by applying a first authentication policy from at least one authentication policy to the authentication element and the protected field; and selects a second authentication action from a set of predetermined authentication actions by applying a second authentication policy from at least one authentication policy to the authentication element and the protected field. The update module 340 determines the target authentication action based at least on the first and second authentication actions.

[0078] Update module 340 may include two sub-modules: a plugin and a loader. The plugin can be configured to further encapsulate the original authentication context described above into a standardized authentication context. The plugin can also provide a standard interface to the loader, allowing the loader to obtain the standardized authentication context, perform authentication actions, and modify the response to the request. The standardized interface is not defined using specific functions, but rather relies on a language-based (e.g., Go) interface mechanism. Furthermore, the plugin can be configured to determine which loader to use to perform the authentication action based on the request, and to aggregate the authentication results returned by different loaders into a unified authentication result. When different loaders perform authentication, they may not directly return the authentication result, but instead cache a temporary authentication intermediary within the plugin. After all loaders have completed their execution, the plugin aggregates this temporary authentication intermediary and finally returns the aggregated authentication result to action module 332 to adjust the original response based on the aggregated authentication result.

[0079] Authentication strategies, or authentication rules, are abstracted as loaders. Correspondingly, different loaders can have the same defined interface. Within the plugin, the authentication strategies of all loaders are called through this shared interface to obtain the authentication results from different loaders. Each loader can load an authentication context. Since all loaders conform to the same definition, the loading methods of different loaders can be executed sequentially within the plugin. The authentication context can also be an interface through which the loader can obtain the authentication context mentioned above.

[0080] The loader can obtain relevant data and perform specific actions from the plugin through a standard interface without depending on the specific plugin code, thus achieving decoupling between the loader and the plugin.

[0081] A loader is a set of authentication rules. A single request can match one or more of these rules, i.e., one or more loaders. Within a loader, specific authentication rules determine the validity of the request, whether it should be rejected, or whether adjustments are needed, based on the standard authentication context described above. If adjustments are required, the loader can modify the request result according to the standard modification interface. The loader can determine one or more authentication policies based on the request, and then use these policies and the authentication context to determine whether the original response should be approved, rejected, or adjusted. If the original response is approved, it is returned to application layer 110. If the original response is rejected, it is not returned to application layer 110. If the original response needs adjustment, the loader will adjust it according to the standard interface.

[0082] The plugin obtains the authentication result from the loader. Authentication points and authentication elements can also be defined as interfaces. Communication provides the loader with this interface to manipulate authentication points and authentication elements, allowing different loaders to adjust the authentication result internally. The loader obtains the currently requested authentication point and the authentication elements within that point. The authentication point interface can retrieve protected fields and authentication elements by calling defined functions. For authentication elements, their relevant values ​​can be retrieved. This interface can also define the aforementioned authentication actions, such as reject, erase, erase itself, modify, and replace. If the loader determines to reject the request, it will directly call the block method (BlockMethod). If the loader determines to erase a field within an authentication element, it calls the erase function. If the loader determines to erase an authentication element, it calls the eraseSelf function. If the loader determines to modify a field within an authentication element, it calls the modify function.

[0083] In some embodiments, action module 332 can be configured to adjust the response to the request (i.e., the original response) based on the authentication result of update module 340. The adjustment of the original response is completed within distributed module 210, without affecting the business logic process; that is, no corresponding code for adjusting business logic is required. Specifically, action module 332 can define node entity types (RefNodes) in the authentication body according to annotation module 371 and data path. Different node entity types represent different nodes in the authentication body. Nodes can be defined as adjustment methods such as erasure, modification, and replacement, which correspond to the authentication results returned by the plugin. Action module 332 intercepts the original response, parses the node entity types in the original response, receives the authentication results returned by the plugin, and operates on the node entities according to the authentication results to achieve the effect of correctly adjusting the original response. Specifically, each node contains a unique authentication key. The authentication results contain different authentication elements, each containing a different authentication key, and the authentication keys in the nodes correspond one-to-one with the authentication keys in the authentication results. Therefore, the action module 332 can determine the corresponding node based on the authentication key of the authentication element, and perform operations on the node to adjust the original response.

[0084] The data plane modules have been described above. The various embodiments of this disclosure can implement standard authentication contexts, standard authentication access methods, standard authentication strategies, standard authentication actions, and configurations. Regardless of whether the business logic code is adjusted, the authentication logic code does not need to be changed, thereby reducing access and maintenance costs. Simultaneously, all traffic entering the distributed module is controlled in real time at the source, further reducing development costs.

[0085] The control plane modules are described below. Considering that different business logics require access to different data containing data that needs protection (e.g., protected data), some embodiments of this disclosure can use a general method to obtain the data requiring protection accessed under different business logics. Return Figure 3B For example, the annotation module 371 is used to implement the data annotation function. In some embodiments, the annotation module 371 uses the labeled data as input to the data extraction module 331, so that the data extraction module 331 extracts the authentication context based on the labeled data.

[0086] In some embodiments, the annotation module 371 can generate predefined labels for identifying corresponding fields and map fields with predefined labels to requests or responses. Predefined labels may include protected labels, value labels, and authentication labels.

[0087] Protected tags are used to identify fields that need to be controlled. Such fields may be erased or audited. A protected tag indicates a protected field represented by the request or response structure. If a field is marked as protected, it will be used as an input parameter for authentication (i.e., part of the authentication context). Possible results include the field being erased, modified, or the entire request being rejected due to that field. This retrieves which protected data was returned by the request and what protection level of data was returned.

[0088] Value tags are used to identify the fields whose values ​​are to be read. The fields identified by the value tags (also called value fields) need to be extracted and parsed by the distributed module 210 (e.g., data extraction module 331) to obtain their corresponding values ​​for control decisions. As an example, the value field can be the purpose of a request, such as the user or tenant to be accessed. For instance, each time it is invoked, the distributed module 210 extracts the specific value of the user's identity from each request to determine which user's information the request accessed. Therefore, the labeling module 320 needs to tag the user identity field in the request with a value tag and set corresponding policy rules to allow access to users who meet the rules.

[0089] Authentication tags are used to identify fields that represent authentication objects (also known as authentication subjects). Distributed module 210 can authenticate fields marked with authentication tags. Authentication tags can be used to mark authentication dimensions; if a field is marked with this tag, authentication will be performed on that field. If the tag is placed on the entire response, the granularity of authentication is the entire response. If the tag is placed on a batch container, the granularity of authentication is the elements within the container. The main purpose of this tag is to ensure that authentication rules apply to the correct authentication dimensions. It is generally used to mark batch responses and can automatically categorize elements under the root node of the path indicated by the authentication tag: if the field type is a list, it can be categorized as list elements; if the field type is a map, it will be categorized as map elements; if the field type is a structure, it will not be split.

[0090] In some embodiments, the control module 220 may provide an interface for annotation, allowing administrators or security team members to configure data annotation-related functions.

[0091] Figure 4A A schematic diagram of an example interface 400A for label settings according to some embodiments of the present disclosure is shown. Interface 400A schematically illustrates a label setting interface for a response, which includes a field name field 410, a field type field 420, and a label type field 430.

[0092] Field Name column 410 includes multiple field names, such as "User Response," "User," "Address," etc. These field names can be arranged hierarchically. The symbols "+" or "-" before a field name indicate that the subfield names contained within that field name can be expanded or collapsed. The top-level field name in the hierarchy can be called the root node, and its subfield names can be called nodes. For example, the root node of the hierarchy is "User Response." "User Response" can be expanded into two fields: "Base Response" and "User." "User" can be further expanded into multiple fields: "Address," "List," "Graph," "Gender," etc. Additionally or alternatively, the symbols "+" or "-" after a field name indicate that the subfield name can be added or deleted.

[0093] The field type column 420 includes various field types, such as "structure", "list", "string", "graph", etc.

[0094] The label type field 430 includes various labels, such as "Protected Labels," "Value Retrieval Labels," and "Authentication Labels," etc. The "+" symbol in label type field 430 indicates that a label can be added to the corresponding field. For example, adding a protected label named "Address" to the "Address" field will display the label name "Address" in the protected label field. Similarly, value retrieval labels, authentication labels, etc., can also be added.

[0095] Administrators or security team members can select and associate fields and predefined labels through interface 400A to achieve data annotation. Control module 220 can convert the annotation results into a mapping between data paths and predefined labels, and send it as configuration to distributed module 210.

[0096] As an example, such as Figure 4A As shown, if the protected field label "Gender" is annotated on the "Gender" attribute of the user response structure, it means that the response contains the protected field "Gender". The value label "Target ID" is annotated on the "ID" attribute of the user response structure, indicating that the response needs to parse the specific value of "Target ID". The authentication labels "Response" and "Default" are annotated on "User Response" and "User" respectively, representing that the authentication dimension is the original user response and the elements in the user array under the user response, respectively. The above description demonstrates the annotation interface from the user's perspective.

[0097] In some embodiments, the distributed module 210 determines the location of the authentication subject based on the authentication tag and data path (also known as location information) to perform authentication actions. Therefore, the authentication subject and data path are the smallest units of execution for authentication actions.

[0098] In some embodiments, a data path includes multiple fields and the structural relationships between the fields.

[0099] In some embodiments, the annotation module 371 extracts annotation data from the Interface Description Language (IDL). Alternatively or additionally, the annotation module 371 parses the IDL file to render a structure corresponding to a request or response to enable human-computer interaction, allowing administrators to annotate specific fields. For example, annotating user identity, user name, user's birthday, etc.

[0100] In some embodiments, the distributed module 210 (e.g., the access point module 330) can classify the fields of the request response based on the data path (also known as the location information of the label) corresponding to the authentication label. For example, the field type can be classified as a structure type, a list type, a graph type, etc. Specifically, the distributed module 210 can determine the mapping between the data path and the interface field according to the data path rules. Each field can be represented by a data path. If the field is a primitive type or a structure, the relative path can be directly represented by the field name, such as in a user response. If the field is a container type, such as a list or a graph, it needs to be handled differently. Specifically, if the field is a list type, ".[]" needs to be added after the field name. If the field is an element with a specified ID in the list, ".[id]" needs to be added after the field name. If the field is a graph type, ".{}" needs to be added after the field name. If it is necessary to retrieve the key in the graph type, ".{key}" needs to be added after the field name. In addition, different fields are separated by the symbol ".". For example, "user response.user" represents two different fields: one field is "user response" and the other field is "user".

[0101] As an example, Figure 4B A schematic diagram of an example 400B of a response data structure according to some embodiments of the present disclosure is shown. Example 400B schematically illustrates a response data structure such as IDL format in the form of a block diagram. The user response is the top-level structure 460, which includes multiple fields such as "User ID", "List of User IDs", "User Graph", etc. The "User Graph" field further contains another user structure 470, which in turn includes multiple fields such as "User ID", "User Name", "User Gender", "Address", "Phone Number", etc. The above data paths are given by way of example only and do not imply any limitation on the scope of the present disclosure.

[0102] The following are examples of how distributed module 210 can apply authentication actions to some example data paths. For example, the data path “user response.userID” represents an operation on the “user response.userID” field. The data path “user response.userID list.[]” represents traversing all elements in “user response.user list” and operating on the traversed elements. The data path “user response.user list.[2]” represents an operation on the third element in “user response.user list” (the first element is “user response.user list.[0]” and the second element is “user response.user list.[1]”). For example, the data path “user response.user graph.{key}.name” represents traversing all users corresponding to all keys in “user response.user graph” and operating on the “name” field of the traversed users. For example, the data path “user response.user graph.{key}” represents traversing all key values ​​in “user response.user graph” and operating on them. The above are merely examples of data paths and do not imply any limitation on the scope of this disclosure.

[0103] Return to continue reading Figure 3B The observation module 372 is configured to monitor the service's operational status in real time. The alarm module (not shown) is configured to determine whether a service failure has occurred based on its operational status, and if a failure occurs, to issue an alarm or fault notification. The publishing module 373 can be configured to provide highly reliable and secure hierarchical publishing and rollback capabilities for the configuration of variable information involved in all the above modules. The routing module 374 is configured to provide fine-grained method-level routing capabilities, support routing rule configuration, and support comprehensive operational strategy configuration capabilities at all levels.

[0104] The various embodiments of this disclosure can implement standardized, low-cost, high-performance, and low-latency distributed architecture data protection solutions. For example, in some embodiments described above, authentication context standardization is implemented. In these embodiments, the core data access protection context is encapsulated, corresponding to the terminal traffic identity context, the request destination context, and the request source context, respectively. Through these three standard contexts, it can be determined which user the request originated from, which service initiated it, and which data of which service is to be accessed.

[0105] In some of the embodiments described above, authentication access methods have been standardized. These embodiments standardize the access methods; regardless of the language or framework, there are generally only two access methods: one is through middleware within the framework the language relies on, and the other is through the sidecar pattern in a microservice architecture. For the services that need access, they only need to find the appropriate access method.

[0106] In some of the embodiments described above, authentication policies are standardized. In these embodiments, data protection policies are abstracted into different horizontal service loaders. Regardless of which service accesses this solution, only different loaders need to be selected in the control plane, without requiring the service provider to adjust any code in its own code.

[0107] In some of the embodiments described above, authentication configuration standardization was implemented. In these embodiments, all configurations are standardized for the business units that need to access the system, eliminating scenarios where business units need to make dynamic adjustments. As described above, the authentication configuration includes four modules: an annotation module, a routing module, an observation module, and a publishing module.

[0108] In the embodiments described above, authentication actions are standardized. In these embodiments, predictability and enumerability of the authentication results are crucial for these actions. Regardless of the access method, a standard authentication result can be generated based on the authentication rules. This result is categorized into three types: pass, reject, and modify. The modify type further includes several sub-items, such as erasing all fields, erasing a field of a single element, modifying all fields, modifying a field of a single element, etc. Regardless of the service, request, or access method, after authentication using this solution, both the authentication actions and results are strictly enumerable and within expectations.

[0109] In some of the embodiments described above, lower access costs are achieved. In these embodiments, the two access methods described above have significantly lower access costs compared to the three traditional solutions. If access is via the sidecar mode, no code modification is required for business integration; the business is completely unaware of the changes and incurs zero cost. If access is via middleware, although the business needs to modify the code, the modifications are minimal compared to the three traditional solutions mentioned above; only the script needs to be initialized and imported in the code. In practice, the code modification is often less than five lines.

[0110] In some of the embodiments described above, lower maintenance costs are achieved. In these embodiments, regardless of the access method, the code coupling between data access control and the business logic itself is very low. This means that, under normal circumstances, the business is almost unaware of the existence of the data access scheme of this disclosure embodiment, no matter what adjustments are made to its own code. For example, interface logic adjustments are very common in daily operations and maintenance. In the three traditional schemes, if the business logic itself is adjusted, the corresponding access control code logic will inevitably need to be adjusted as well (adjusting custom authentication logic, adjusting the logic for initiating RPC requests, and adjusting the input to the authentication SDK, etc.). However, in contrast, in the scheme of this disclosure, regardless of whether the business logic is adjusted, the logic within the access point does not need to be changed; at most, the annotation configuration may need to be adjusted in the control plane. This significantly reduces maintenance costs compared to other schemes.

[0111] In some of the embodiments described above, degradation prevention is implemented. The three traditional solutions all rely on the self-discipline of business developers during daily development. When adding new interfaces, they depend on this self-discipline combined with the development of data access protection logic. If development time is tight, or developers are unaware of this, or due to time changes or personnel iterations, developers may not be aware of the need to add data protection logic. Over time, authentication rules will be neglected and prone to degradation, ultimately leading to numerous authentication logic vulnerabilities. The solution disclosed in this paper controls all traffic at the source. All traffic enters the distributed module, eliminating the need for business developers to spend time adjusting data access protection-related code during daily iterations, thus freeing up developer manpower. Although manpower costs are reduced, the control entry point routes all traffic to the control module. Through the observation and alarm modules, relevant personnel are notified to adjust governance rules on the control plane, ensuring that the logic of daily iterations does not degrade.

[0112] In some of the embodiments described above, high performance is achieved. Compared to centralized authentication architectures, the solution disclosed herein is a distributed architecture, which eliminates single points of failure from an architectural perspective, preventing all business services from failing due to performance bottlenecks in the data protection module. Furthermore, in embodiments employing middleware access, the authentication logic and business logic reside in the same instance, reducing network overhead and offering advantages in latency and CPU overhead compared to RPC calls.

[0113] Example process

[0114] Figure 5 A flowchart of a data access process 500 according to some embodiments of the present disclosure is shown. For example, process 500 may be performed by data access system 200.

[0115] In box 510, obtain an authentication context for authenticating a request that is issued to the current service and is used for data access. The authentication context is generated based on at least one of the request or a response to the request generated by the current service.

[0116] In box 520, an authentication result for the request is generated based on the authentication context and at least one authentication policy.

[0117] In box 530, provide feedback corresponding to the authentication result to proxy the current service's response to the request.

[0118] In some embodiments, generating an authentication result includes: determining, from the authentication context, the authentication element as the authentication object and the protected field of the protected data including the authentication element; and selecting, from a plurality of predetermined authentication actions, a target authentication action to be performed on the response as the authentication result by applying at least one authentication strategy to the authentication element and the protected field.

[0119] In some embodiments, the multiple predetermined authentication actions include two or more of the following: providing a response, preventing the provision of a response, or preventing protected data from being provided with a response.

[0120] In some embodiments, selecting a target authentication action includes: selecting a first authentication action from a plurality of predetermined authentication actions by applying a first authentication strategy from at least one authentication strategy to the authentication element and the protected field; selecting a second authentication action from a plurality of predetermined authentication actions by applying a second authentication strategy from at least one authentication strategy to the authentication element and the protected field; and determining a target authentication action based at least on the first authentication action and the second authentication action.

[0121] In some embodiments, the authentication context includes predefined type information, which includes at least one of the following: identity information related to the initiation of the request, upstream and downstream information related to the upstream and downstream services of the current service, or subject information related to the authentication subject in the request.

[0122] In some embodiments, at least one authentication strategy is selected from a pre-configured pool of candidate authentication strategies based on identity information.

[0123] In some embodiments, feedback is also provided via at least one of the following: a proxy for handling communication between the current service and other services, or middleware located between the current service and the application layer.

[0124] In some embodiments, configuration information related to authentication is generated based on user input. The configuration information indicates at least one of the following: one or more fields used for authentication in the request, one or more fields used for authentication in the response, or conditions under which the request needs to be authenticated.

[0125] Figure 6 A schematic structural block diagram of a data access apparatus 600 according to some embodiments of the present disclosure is shown. The various modules / components in apparatus 600 may be implemented by hardware, software, firmware, or any combination thereof.

[0126] The apparatus 600 includes a context acquisition module 610 configured to acquire an authentication context for authenticating a request, the request being sent to the current service for data access, the authentication context being generated based on at least one of the request or a response to the request generated by the current service; an authentication result generation module 620 configured to generate an authentication result for the request based on the authentication context and at least one authentication policy; and a feedback provision module 630 configured to provide feedback corresponding to the authentication result to proxy the current service's response to the request.

[0127] In some embodiments, the authentication result generation module 620 is further configured to determine, from the authentication context, the authentication element as the authentication object and the protected field of the protected data including the authentication element; and to select, from a plurality of predetermined authentication actions, the target authentication action to be performed on the response as the authentication result by applying at least one authentication strategy to the authentication element and the protected field.

[0128] In some embodiments, the multiple predetermined authentication actions include two or more of the following: providing a response, preventing the provision of a response, or preventing protected data from being provided with a response.

[0129] In some embodiments, the authentication result generation module 620 is further configured to select a first authentication action from a plurality of predetermined authentication actions by applying a first authentication strategy from at least one authentication strategy to the authentication element and the protected field; select a second authentication action from a plurality of predetermined authentication actions by applying a second authentication strategy from at least one authentication strategy to the authentication element and the protected field; and determine a target authentication action based at least on the first authentication action and the second authentication action.

[0130] In some embodiments, the authentication context includes predefined type information, which includes at least one of the following: identity information related to the initiation of the request, upstream and downstream information related to the upstream and downstream services of the current service, or subject information related to the authentication subject in the request.

[0131] In some embodiments, at least one authentication strategy is selected from a pre-configured pool of candidate authentication strategies based on identity information.

[0132] In some embodiments, the feedback providing module 630 is further configured to provide feedback via at least one of the following: a proxy for handling communication between the current service and other services, or middleware located between the current service and the application layer.

[0133] In some embodiments, the apparatus 600 further includes a configuration information generation module configured to generate authentication-related configuration information based on user input, wherein the configuration information indicates at least one of the following: one or more fields used for authentication in a request, one or more fields used for authentication in a response, or conditions under which authentication is required for the request.

[0134] Figure 7 A block diagram of an electronic device 700 in which one or more embodiments of the present disclosure may be implemented is shown. It should be understood that... Figure 7 The electronic device 700 shown is merely exemplary and should not be construed as limiting the functionality and scope of the embodiments described herein. Figure 7 The electronic device 700 shown can be used to achieve Figure 1 Terminal equipment 110.

[0135] like Figure 7 As shown, electronic device 700 is in the form of a general-purpose electronic device. Components of electronic device 700 may include, but are not limited to, one or more processors or processing units 710, memory 720, storage device 730, one or more communication units 740, one or more input devices 750, and one or more output devices 770. Processing unit 710 may be a physical or virtual processor and is capable of performing various processes according to programs stored in memory 720. In a multiprocessor system, multiple processing units execute computer-executable instructions in parallel to improve the parallel processing capability of electronic device 700.

[0136] Electronic device 700 typically includes multiple computer storage media. Such media can be any available media accessible to electronic device 700, including but not limited to volatile and non-volatile media, removable and non-removable media. Memory 720 can be volatile memory (e.g., registers, cache, random access memory (RAM)), non-volatile memory (e.g., read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory), or some combination thereof. Storage device 730 can be a removable or non-removable medium and can include machine-readable media, such as flash drives, disks, or any other media that can be used to store information and / or data (e.g., training data for training) and can be accessed within electronic device 700.

[0137] Electronic device 700 may further include additional removable / non-removable, volatile / non-volatile storage media. Although not explicitly stated... Figure 7 As shown, disk drives for reading from or writing to removable, non-volatile disks (e.g., "floppy disks") and optical disk drives for reading from or writing to removable, non-volatile optical disks can be provided. In these cases, each drive can be connected to a bus (not shown) via one or more data media interfaces. Memory 720 may include computer program product 725 having one or more program modules configured to perform various methods or actions of various embodiments of this disclosure.

[0138] The communication unit 740 enables communication with other electronic devices via a communication medium. Additionally, the functionality of the components of the electronic device 700 can be implemented using a single computing cluster or multiple computing machines capable of communicating via communication connections. Therefore, the electronic device 700 can operate in a networked environment using logical connections to one or more other servers, network personal computers (PCs), or another network node.

[0139] Input device 750 can be one or more input devices, such as a mouse, keyboard, trackball, etc. Output device 770 can be one or more output devices, such as a monitor, speaker, printer, etc. Electronic device 700 can also communicate with one or more external devices (not shown) via communication unit 740 as needed. These external devices include storage devices, display devices, etc., and can communicate with one or more devices that enable user interaction with electronic device 700, or with any device that enables electronic device 700 to communicate with one or more other electronic devices (e.g., network card, modem, etc.). Such communication can be performed via input / output (I / O) interface (not shown).

[0140] According to an exemplary implementation of this disclosure, a computer-readable storage medium is provided that stores computer-executable instructions thereon, wherein the computer-executable instructions are executed by a processor to implement the methods described above. According to an exemplary implementation of this disclosure, a computer program product is also provided, which is tangibly stored on a non-transitory computer-readable medium and includes computer-executable instructions, which are executed by a processor to implement the methods described above.

[0141] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatuses, devices, and computer program products implemented according to this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0142] These computer-readable program instructions can be provided to a processing unit of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processing unit of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner. Thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0143] Computer-readable program instructions can be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions that execute on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0144] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0145] Various implementations of this disclosure have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed implementations. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described implementations. The terminology used herein is chosen to best explain the principles, practical applications, or improvements to technology in the market, or to enable others skilled in the art to understand the various implementations disclosed herein.

Claims

1. A data access method, comprising: Obtain an authentication context for authenticating a request made to the current service for data access, the authentication context being generated based on the request and response, the response being generated by the current service based on the request; Based on the authentication context and at least one authentication strategy, an authentication result is generated for the request; as well as Provide feedback corresponding to the authentication result to proxy the current service in responding to the request; The generation of the authentication result includes: From the authentication context, determine the authentication element as the object of authentication and the protected fields including the protected data of the authentication element; and By applying the at least one authentication strategy to the authentication element and the protected field, a target authentication action to be performed on the response is selected from a plurality of predetermined authentication actions, and the result is the authentication result. The selection of the target authentication action includes: By applying the first authentication strategy from the at least one authentication strategy to the authentication element and the protected field, a first authentication action is selected from the plurality of predetermined authentication actions; By applying the second authentication strategy from the at least one authentication strategy to the authentication element and the protected field, a second authentication action is selected from the plurality of predetermined authentication actions; and The target authentication action is determined based at least on the first authentication action and the second authentication action.

2. The method according to claim 1, wherein the plurality of predetermined authentication actions includes two or more of the following: Provide the response, To prevent the provision of the response, or To prevent the protected data from being provided with the response.

3. The method according to claim 1, wherein the authentication context includes predetermined type information, and the predetermined type information includes at least one of the following: Identity information related to the initiation of the request. Upstream and downstream information related to the current service's upstream and downstream services, or Subject information related to the authentication subject in the request.

4. The method according to claim 1, wherein the at least one authentication strategy is selected from a pre-configured candidate authentication strategy based on identity information.

5. The method of claim 1, further comprising providing the feedback via at least one of: A proxy used to handle communication between the current service and other services, or The middleware located between the current service and the application layer.

6. The method of claim 1, further comprising generating configuration information related to the authentication based on user input, the configuration information indicating at least one of the following: One or more fields used for authentication in the request One or more fields used for authentication in the response, or The request requires authentication.

7. A data access device, comprising: The context acquisition module is configured to acquire an authentication context for authenticating a request, which is sent to the current service and is used for data access. The authentication context is generated based on the request and response, and the response is generated by the current service based on the request. The authentication result generation module is configured to generate an authentication result for the request based on the authentication context and at least one authentication policy. as well as The feedback providing module is configured to provide feedback corresponding to the authentication result, so as to proxy the current service in responding to the request; The authentication result generation module is configured as follows: From the authentication context, determine the authentication element as the authentication object and the protected fields of the protected data including the authentication element; as well as By applying the at least one authentication strategy to the authentication element and the protected field, a target authentication action to be performed on the response is selected from a plurality of predetermined authentication actions, and the result is the authentication result. The selection of the target authentication action includes: By applying the first authentication strategy from the at least one authentication strategy to the authentication element and the protected field, a first authentication action is selected from the plurality of predetermined authentication actions; By applying the second authentication strategy from the at least one authentication strategy to the authentication element and the protected field, a second authentication action is selected from the plurality of predetermined authentication actions; and The target authentication action is determined based at least on the first authentication action and the second authentication action.

8. An electronic device, comprising: At least one processing unit; as well as At least one memory, coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, the instructions causing the device to perform the method according to any one of claims 1 to 6 when executed by the at least one processing unit.

9. A computer-readable storage medium having a computer program stored thereon, the computer program, when executed by a processor, implementing the method according to any one of claims 1 to 6.

Images