Preventing data leakage in multi-tenant services through request and response containerization using source check

Abstract

The techniques disclosed herein utilize source check to prevent data leakage in multi-tenant services through request and response containerization. When a web request is received on behalf of a tenant, a request container is created and initialized using identification information extracted from the request. Derived identifiers, which may be verified to be associated with the tenant, may be added to the request container. A response container is then created for accumulating data retrieved when processing the request. The request container and the response container are passed throughout the call path in which the request is processed. Identification information delivered to the data access operation is obtained from the request container, and the result of the data access operation is stored in the response container. Before generating a web response using data from the response container, the response container is validated as containing data associated with the appropriate request.

Description

Background Art

[0001] Cloud-based services use a pool of computing resources to handle requests from different tenants. Sharing resources between tenants utilizes resources more efficiently than allocating dedicated resources to each tenant. However, using shared resources to handle requests from different tenants introduces the possibility of data leakage, i.e., inadvertently exposing one tenant's data to a different tenant. For example, a service might cache a tenant-related identifier and then reuse that identifier when handling requests from a different tenant. Any data access performed using the cached identifier will retrieve data for the wrong tenant, resulting in a data leakage. These errors are difficult to spot manually in code reviews or even when applying static code analysis.

[0002] The consequences of a data breach can be severe, exposing sensitive financial information, trade secrets, or other confidential data. Cloud service providers may also suffer significant reputational damage once a data breach is discovered.

[0003] It is with respect to these and other considerations that the present disclosure is presented herein. Summary of the invention

[0004] The technology disclosed herein uses source checking to prevent data leakage in multi-tenant services through request and response containerization. When a web request is received on behalf of a tenant, a request container is created and initialized using identification information extracted from the request. A derived identifier that can be verified as associated with the tenant can be added to the request container. A response container is then created for accumulating data obtained when processing the request. The request container and the response container are passed throughout the call path of processing the request. The identification information passed to the data access operation is obtained from the request container, and the results of the data access operation are stored in the response container. Before generating a web response using data from the response container, the response container is verified to contain data associated with the appropriate request.

[0005] The technical solution to the above problem consists of various mechanisms that can detect and prevent cross-tenant data leakage. A mechanism ensures that the identification information used to process the request is accurate, for example, the call path for processing a web request does not accidentally use outdated or corrupted identification information. Always using appropriate identification information prevents data from one tenant from being accidentally returned to a different tenant.

[0006] Specifically, the data extracted from the web request is containerized, i.e., stored in an immutable object that cannot be tampered with while processing the request. The extracted data includes identification information, such as identifiers, tokens, and other user-supplied data. An identifier is a unique sequence of characters that identifies an entity in a cloud service. Examples of identifiers include tenant identifiers, user identifiers, and organization identifiers. An example of a token is a user authentication token that confirms the identity of a user. The extracted identification information is considered a source of baseline truth because it originates from the request. Storing the extracted identification information in an immutable object ensures that it is not replaced, overwritten, corrupted, or otherwise altered before it is used.

[0007] The request container is available throughout the call path for processing web requests and is used as a source of identification information when calling data access APIs. For example, when generating a database query, the tenant identifier parameter is obtained from the request container. Because the tenant identifier is stored immutably in the request container, the likelihood of using a replaced, cached, corrupted, or otherwise inappropriate identifier when calling a database query is significantly reduced.

[0008] The second mechanism allows derived identifiers (including derived tokens) to be added to the request container. A derived identifier is an identifier or token that is not extracted from a web request. For example, an "on-behalf-of" (OBO) token obtained from an authentication service can be added to a request container. Before being added to the request container, the derived identifier is first confirmed to be associated with the tenant of the request. This ensures that any identifier stored in the request container is obtained directly from the web request or is otherwise provably associated with the tenant. In some configurations, the derived identifier is confirmed to be associated with the tenant by cryptographically verifying that the derived identifier contains the tenant identifier associated with the request being processed. After the derived identifier is stored in the request container, the derived identifier can be used as a parameter when calling the cloud service when processing a web request.

[0009] The third mechanism is to containerize the data used to generate the response to the web request. In some configurations, the response container is initialized with a request container or a request identifier that uniquely points to the request container. Throughout this document, when referring to storing a request container or comparing a request container, it is also expected that the request identifier of the request container is stored or compared. The request container is stored in the response container and is used to verify that any data added to the response container is associated with the appropriate request. Specifically, the data accessor method that assigns data to the response container also accepts the request container as a parameter. Before allowing data to be added to the response container, the response container first verifies that the request container parameters match the request container stored in the response container. This ensures that only data for the appropriate request is added to the response container.

[0010] The fourth mechanism applies origin checking to the response container before generating a web response. Specifically, when generating a web response to a web request, the response container is verified to store the request container generated for the web request. This ensures that only data associated with the tenant of the web request is used to generate the response - i.e., ensures that cross-tenant data is not accidentally leaked into the response using an improper response container.

[0011] The fifth mechanism ensures that request and response containerization is always applied when calling user data APIs. User data APIs refer to functions that retrieve data based on identifiers. Typically, user data APIs are user-generated code that calls data access APIs provided by the cloud service. In some configurations, static source code analysis of user data APIs verifies that only identifiers retrieved from the request container are provided as identifier arguments to the data access API. Calls to the data access API that use identifiers that are not retrieved from the request container are flagged as potential cross-tenant data leakage vulnerabilities.

[0012] For example, the source code of a data access API can be analyzed to identify parameters with a "user input" annotation. This annotation indicates that the values ​​passed into these parameters should be provably associated with the tenant of the request. Static source code analysis can identify all calls to the data access API and ensure that at each call site, all values ​​passed into parameters annotated as "user input" originate from the request container. Calling the data access API with "user input" parameters that do not originate from the request container may use outdated values ​​that are not associated with the current web request.

[0013] Similarly, static source code analysis can verify that data returned from a cloud service data access API is stored directly in the response container. Data stored elsewhere is flagged as a potential cross-tenant data leakage vulnerability because data not stored in the response container may leak into responses sent to different tenants.

[0014] By reading the following detailed description and reviewing the relevant drawings, features and technical advantages other than those explicitly described above will be apparent. This summary is intended to provide an introduction to some concepts in a simplified form, which will be further described in the following specific embodiments. This summary is not intended to identify the key or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. For example, the term "technology" may refer to (multiple) systems, (multiple) methods, computer-readable instructions, (multiple) modules, algorithms, hardware logic and / or (multiple) operations allowed by the above content and the entire document. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The detailed description is described with reference to the accompanying drawings. In the drawings, the leftmost digit(s) of a reference number identifies the drawing in which the reference number first appears. The same reference numbers in different drawings represent similar or identical items. References to individual items of a plurality of items may use reference numbers with letters in the alphabetical sequence to refer to each individual item. Generic references to items may use specific reference numbers without the alphabetical sequence.

[0016] Figures 1A to 1C It is shown that a web request is processed in a manner consistent with the prior art.

[0017] Figure 2 Shows the creation and initialization of a request container when processing a web request.

[0018] Figure 3 Shown is adding a derived identifier to the request container.

[0019] Figure 4A Creating and initializing a response container is shown.

[0020] Figure 4B Calling the User Data API using request and response containers is shown.

[0021] Figures 5A to 5B Shows verification that the web response is generated using the appropriate response container.

[0022] Figure 6 Static source code analysis of the User Data API is shown for consistent use of request and response containers.

[0023] Figure 7 is a flow chart of an example method for verifying the origin of data transmitted in a web response.

[0024] Figure 8 is a computer architecture diagram illustrating an exemplary computer hardware and software architecture for a computing system capable of implementing aspects of the processes and techniques presented herein.

[0025] Fig. 9 is a diagram illustrating a distributed computing environment capable of implementing various aspects of the techniques and technologies presented herein. DETAILED DESCRIPTION

[0026] Figure 1AA user 102 of a client device 104 is shown submitting a request 110 to a server device 120 of a cloud service 124. The user 102 may be an entity of a tenant 160 of the cloud service 124. As described herein, a tenant is a group of cloud service users that are collectively managed. Tenants may be created for organizations such as businesses, schools, etc. Tenants are often viewed as security boundaries within a cloud service 124 such that data accessible to users within one tenant is not accessible to users of other tenants, at least by default.

[0027] Client device 104 may be any desktop computer, laptop computer, mobile phone, IoT device, car, virtual or augmented reality headset, or any other computing device. Server device 120 represents one or more computing devices that perform operations of cloud service 124 .

[0028] Request 110 can be any type of network-based request, such as a web request or an HTTP request. Request 110 includes one or more identifiers 112. As described herein, an identifier is a number, a string, or any other data that refers to an entity within cloud service 124. An identifier can be in the form of a serial number, a globally unique identifier (GUID), a user name, a domain-qualified user name, and the like. Typically, users, tenants, and computing resources are associated with identifiers within cloud service 124. Operations performed within cloud service 124, such as data retrieval operations, can use identifier 112 to indicate which user the operation is for.

[0029] Additionally or alternatively, the identifier 112 may be a token. The identifier 112 may be an authentication token for the user 102 that proves that appropriate credentials were provided to authenticate the user 102.

[0030] As shown, in response to request 110, server device 120 sends authorization request 122 to authorization service device 130. Authorization request 122 includes identifier 112. The authorization request may be a request for an "on behalf of" (OBO) token that authorizes server device 120 to operate with access rights associated with identifier 112. Service device 130 may be a directory server that cryptographically identifies, evaluates, and generates authentication and / or authorization tokens.

[0031] Database 150 represents a data access API provided by a cloud service. As discussed in more detail below, the database 150 can be queried using identifier 112 and / or an OBO token to retrieve data specific to user 102. Another example of a user-specific data access API is a file storage service. A file storage service may provide an operation that lists files associated with a specific user. User-specific operations are typically implemented as functions that accept a user identifier or some other user credentials as parameters.

[0032] As described herein, a token refers to the cryptographically protected result of a security operation. Tokens are typically passed between applications and devices as proof that a security operation was successfully performed. The recipient of the token can perform cryptographic operations to verify that the issuer of the token actually did perform the claimed security operation. For example, a directory server can provide an authentication token after authenticating user credentials. The authentication token can then be used to track the user's identity within the cloud service 124. For example, a file retrieval data access API can use the authentication token to retrieve files for the corresponding user.

[0033] Figure 1B Authentication server device 130 is shown responding to authorization request 122 with authorization response 126. Authorization response 126 includes token 136, which may be an OBO token that grants server device 120 access to cloud resources that user 102 is authorized to use. Upon receiving authorization response 126, server device 120 may invoke cache put operation 142 to cache token 136 to token cache 140.

[0034] Token cache 140 stores authorization tokens 132, 134, and 136. Tokens 132 and 134 are retained in token cache 140 for other requests, which may come from other users or other tenants. If the tokens stored in token cache 140 are retrieved by the call path to which they are added, no data leakage will occur. However, due to common programming errors, tokens stored when processing one web request may be returned to the call path for processing a different web request. As shown, server device 120 calls cache acquisition operation 144. However, what is retrieved is not token 136 associated with user 102 of tenant 160, but token 132 associated with a different tenant. As described below, this error will occur in a chain until the data associated with the other tenant is leaked into the response sent to user 102.

[0035] Figure 1C Server device 120 is shown sending a database request 152 to database 150. Database request 152 includes token 132 that was inadvertently retrieved from token cache 140. Database 150 generates a database response 154 that includes data 156. Data 156 is associated with token 132, which is not associated with tenant 160. Therefore, when data 156 is included in response 170 sent to client device 104, server device 120 leaks cross-tenant data.

[0036] Another source of cross-tenant data leakage is improper use of data cache 158. Similar to token cache 140, data cache 158 can be used appropriately to speed up data access without causing cross-tenant data leakage. However, common but difficult to detect programming errors may result in retrieving data associated with an improper tenant from data cache 158 and including the data in response 170.

[0037] Figure 2 Request container 202 is shown created and initialized when processing a web request 208 received from client device 104. Request 208 includes identifier 212, which is similar to identifier 112 discussed above in conjunction with Figure 1. Request 208 may also include user token 204, an authentication token that user 102 has obtained from a directory server.

[0038] Request controller 206 is an example of a component of a web service that processes request 208. Request controller 206 can be the first user-defined component that the underlying web server of server device 120 provides to request 208. Request controller 206 can be responsible for processing request 208 and generating a response to be returned to user 102. Controllers are components of many common network application architectures (e.g., model view controller (MVC)). However, controller 206 is only an example of a component of a web service, and other components that implement other architectures are also considered to process request 208. In some configurations, controller 206 is an example of a user data API. Additionally or alternatively, controller 206 calls the user data API, which may or may not be executed on a computing device different from controller 206.

[0039] In some configurations, request controller 206 generates request container 202 from request 208 because request controller 206 is the first component to access request 208 along the call path in response to request 208. By applying the disclosed techniques as quickly as possible on the call path of processing request 208, maximum protection against cross-tenant data leakage is achieved.

[0040] As shown, the request controller 206 extracts the identifier 212 and / or the user token 204 from the web request 208 and stores one or both of these values ​​in corresponding read-only properties of the request container 202. Specifically, the identifier 212 is stored in the identifier property 252, and the user token 204 is stored in the user token property 254. In some configurations, the request 208 is passed to the constructor of the request container 202, which extracts the identifier 202 and / or the user token 204 and uses them to initialize the corresponding read-only property 210. However, any similar technique for initializing the read-only property 210 using the identifier and token included in the request 208 can also be similarly considered.

[0041] Request container 202 also initializes request identifier 220, which is a unique identifier associated with request container 202. Request identifier 220 may be used throughout the disclosed embodiments to determine whether two different request containers are actually the same.

[0042] Figure 3 Derived identifiers 322, 324, and 326 are shown added to request container 202. Representative token 322, role-based access control 324, and organization ID 326 are examples of derived identifiers. Derived identifiers are identification information, including tokens, that are typically derived from information contained in request 208. For example, user token 204 can be extracted from request 208 and used to obtain representative token 322 from a directory server. In some configurations, derived identifiers include identifiers or tokens associated with tenant 160. As shown, representative token 322 includes identifier 212, role-based access control 324 includes user token 204, and organization ID 326 includes identifier 382.

[0043] The request controller 206 can obtain these derived identifiers and attempt to add them to the request container 202. The derived user identifier validator 330 analyzes the derived identifiers to determine whether they are indeed associated with the tenant 160. In some configurations, the derived user identifier validator 330 checks the identifier stored in the candidate derived identifier to determine whether it is indeed associated with the tenant 160. The derived user identifier validator 330 can apply encryption technology when performing this determination. As shown, the representative token 322 and the role-based access control 324 will be determined to be associated with the tenant 160 based on the identifier included therein. Therefore, the representative token 322 and the role-based access control 324 are added to the corresponding attributes of the derived identifier attribute 320. Specifically, the value of the representative token attribute 352 is set to the representative token 322, and the value of the role-based access control attribute 354 is set to the role-based access control 324. In contrast, the organization ID 326 is found to be associated with a different identifier 382 and is therefore blocked from being added to the request container 202.

[0044] When the data access API of the cloud service 124 is called, any parameters specifying identification information are obtained directly or indirectly from one of the immutable attributes 210 or the derived identifier attributes 320. For example, the identifier 212 can be copied directly as a parameter of the data access API. Additionally or alternatively, the identifier and / or derived identifier obtained from the request container 202 can be combined or formatted before being provided as a parameter to the user data API. For example, a series of immutable attributes or derived identifier attributes can be combined into a single parameter of the data access API using string concatenation techniques. By obtaining identification information from the request container 202, the possibility of providing identifiers associated with different tenants is eliminated.

[0045] These particular types of derived identifiers and identifiers stored therein are examples selected for illustrative purposes. Any other types of derived identifiers and identifiers stored therein are similarly contemplated. Additionally, a technique for analyzing identifiers contained within a candidate derived identifier is one example of verifying that a derived identifier is associated with the correct tenant. Other techniques, such as providing the candidate derived identifier to a directory service for confirmation are similarly contemplated. In some techniques, the candidate derived identifier does not include an identifier that associates the candidate derived identifier with tenant 160.

[0046] Figure 4A The creation and initialization of a response container 402 is shown. The response container 402 can be initialized with the request container 202. For example, the constructor of the response container 402 can take the request container as a parameter. In other embodiments, the response container 402 is initialized with various properties of the request container 202. In other embodiments, the response container 402 can store a request identifier 220 instead of a complete copy of the request container 402. In either case, the response container 402 is immutably associated with the request container 202. When data is added to the request container 402, the request ID 220 can be used to confirm that the added data is associated with the correct tenant 160.

[0047] Other techniques for obtaining response container 402 are also contemplated. In addition to directly constructing and initializing response container 402, response container 402 can be obtained by calling a member function of request container 202 that returns a response container. In other configurations, response container 402 is part of the same class / structure / object as request container 202, i.e., the properties and methods of request container 202 and response container 402 are combined into a single container that is passed along the call path taken when generating a response. In some configurations, request container 202 is used to provide an identifier when calling a cloud service without storing the result in response container 402.

[0048] Figure 4BThe user data API is shown being called using the request container 202 and the response container 402. When processing the network request 208, the request container 202 and the response container 402 are passed along the call path of processing the request 208. Along the call path, the data access API of the cloud service 124 can be called to obtain data, files, or other information associated with the user 102 and / or the tenant 160. Figure 4B An example of how raw user data returned from the user data API is validated before being stored in the response container 402 is shown.

[0049] The raw user data 404 and 406 may be the result of calling a data access API, such as a file enumeration API, a database query, or other information retrieval mechanism. Figure 3 As discussed in B, identification information passed to the user data API is obtained from the request container 202.

[0050] Response portion storage request 420 illustrates a method being called to store raw user data 404 in response container 402. Request container 202 or a request identifier of request container 202 is also passed to the call to response portion storage request 420. Before storing raw user data 404 in response container 402, response portion validator 430 ensures that request container 202 matches request identifier 220. Similarly, response portion validator 430 prevents response portion storage request 422 from being added to response container 402 because request container 480 is not associated with response container 402. In this way, only data obtained in response to a correct request is allowed to be stored as response portion 414 of response container 402.

[0051] Figure 5A 570. Verification that the web response was generated with the correct response container is shown. The call path taken to process request 208 has resumed execution within request controller 206. Response container 402 now contains original user data 404. Before sending response 570 to request 208, request controller 206 first verifies that response container 402 is indeed associated with request 208. Specifically, response container origin verifier 530 confirms that request ID 220 of response container 402 matches request ID 220 of request container 202. If these request containers match, then response container 402 contains the original user data associated with request 208 and can be included in response 570.

[0052] Figure 5B It shows the verification that the web response is generated with the correct response container. Figure 5AAs discussed, request controller 206 is ready to generate a response to request 208. However, request controller 206 has already obtained response container 502 that includes request ID 280. Response container origin validator 530 determines that response container 502 is not associated with request container 202 because request identifier 280 does not match request identifier 220. Thus, cross-tenant data leakage is avoided by not returning original user data 404 to client device 104.

[0053] Figure 6 Static source code analysis of a user data API for consistent use of request containers and response containers is shown. The effectiveness of request container 202 and response container 402 in preventing cross-tenant data leakage depends only on the consistency of their use on the code path that processes request 208. In some configurations, user data API source code static analysis validator 630 analyzes source code 602 to determine whether request containers and response containers are consistently used. A list 640 of data access APIs with user input parameters that do not originate from the request context can be generated, while a list 650 of data access APIs that do not store results in the response context is generated.

[0054] List 640 and list 650 may be provided to software engineers as warnings or errors. User data API source code static analysis verifier 630 may be executed as part of a build process, source code inspection process, or pre-deployment process to ensure correct use of request containers and response containers.

[0055] In some configurations, the source code definition of the data access API is annotated with indications that it retrieves data for a specific user or tenant. The data access API can be annotated with comments, tags, attributes, specific data types, or any similar programming technique. Parameters of the data access API can also be annotated to indicate which parameters contain identification information. The user data API source code static analysis verifier 630 can analyze the call site that calls the data access API to ensure that the value passed to the identification information parameter originates from the request container. Similarly, the user data API source code static analysis verifier 630 can analyze the call site that calls the data access API to ensure that the data provided by the data access API is stored or directly stored in the response container 402. In some configurations, the user data API source code static analysis verifier 630 also verifies that the request container is initialized using data extracted from the web request 208.

[0056] An application that rarely leaks cross-tenant data stores identification information persistently in an immutable property of a request container, calls a data access API using identification information obtained from the request container, stores data returned from the data access API directly in a response container, and verifies the source of the response container when generating a web response.

[0057] Figure 6 Also shown is a way in which source code definitions of request containers and response containers can be automatically generated. Specifically, request / response source code generator 660 can apply one or more of request templates 662 to prototype request container 664 to generate source code for request container 202. Similarly, source code generator 660 can apply one or more of response templates 662 to prototype response container 666 to generate response container 402. Template 662 can include a base class, and the generated container is derived from the base class. The request and / or response container generated by source code generator 660 meets the requirements implemented by user data API source code static analysis verifier 630.

[0058] For example, the prototype request container 664 may include a list of properties intended to be included in the request container 202. Some properties may be marked as read-only. The source code generator 660 may generate corresponding immutable properties in the request container 202, i.e., by decorating the immutable properties with keywords (e.g., "read-only" or "constant"), attributes, or other techniques to indicate that the immutable properties cannot be changed once initialized. The code generator 660 may also generate a constructor or other initialization function that can be used to initialize the immutable properties directly from the arguments. Additionally or alternatively, the code generator 660 may generate a constructor or other initialization function to initialize the immutable properties based on values ​​extracted from the HTTP context or other data structures obtained from the request 208.

[0059] The source code generator 660 may also detect derived identifier properties associated with validators in the prototype request container 664. A validator (e.g., a derived user identifier validator 330) refers to a function or other source code that ensures that any derived identifier property value is associated with the correct identifier 212 before being added to the request container 202. The source code generator 660 may apply a validator by generating a property in the generated request container 202 that calls the validator before allowing the derived identifier property to be set. The validator may be a member function of a base class from which the generated request container 202 is derived. However, inline functions, free functions, or validator functions of any other type or location are also similarly contemplated.

[0060] Source code generator 660 may also be used to generate response container 402. Prototype response container 666 may include a list of properties that are available when generating response 570. Source code generator 660 may generate response container 402 to include a corresponding list of properties, each property list associated with a setter function that accepts a request container and a value. The setter function generated by source code generator 660 may include code to confirm that the request container parameters match the request container associated with the generated response container 402. If the request container matches, the generated source code allows the value of the property to be set, otherwise an error is raised.

[0061] Now turn to Figure 7 , various aspects of a routine for enabling a system to prevent data leakage in multi-tenant services through request and response containerization using source checking are shown and described. For ease of understanding, the processes discussed in this disclosure are depicted as separate operations represented by independent boxes. However, these separately depicted operations should not be interpreted as necessarily order-dependent in their performance. The order in which the processes are described is not intended to be interpreted as a limitation, and any number of the described process boxes may be combined in any order to implement the process or an alternative process. In addition, one or more of the provided operations may be modified or omitted.

[0062] The specific implementation of the technology disclosed herein is a matter of choice regarding the performance and other requirements of computing devices. Therefore, the logical operations described herein are variously referred to as states, operations, structural devices, actions, or modules. These states, operations, structural devices, actions, and modules can be implemented with hardware, software, firmware, dedicated digital logic, and any combination thereof. It should be understood that more or less operations than those shown in the accompanying drawings and described herein may be performed. These operations may also be performed in an order different from the order described herein.

[0063] It should also be understood that the method shown can be terminated at any time and need not be performed in its entirety. Some or all of the operations of the method and / or substantially equivalent operations can be performed by executing computer-readable instructions included on a computer storage medium, as described below. As used in the specification and claims, the term "computer-readable instructions" and its variants are widely used herein to include routines, applications, application modules, program modules, programs, components, data structures, algorithms, etc. Computer-readable instructions can be implemented on various system configurations, including single-processor or multi-processor systems, minicomputers, mainframe computers, personal computers, handheld computing devices, microprocessor-based programmable consumer electronics, and combinations thereof, etc.

[0064] Therefore, it should be understood that the logical operations described herein are implemented as (1) a sequence of computer-implemented actions or program modules running on a computing system and / or (2) interconnected machine logic circuits or circuit modules within the computing system. The implementation is a matter of choice depending on the performance and other requirements of the computing system. Therefore, the logical operations described herein are variously referred to as states, operations, structural devices, actions, or modules. These operations, structural devices, actions, and modules can be implemented in software, firmware, dedicated digital logic, and any combination thereof.

[0065] For example, the operation of routine 700 is described herein as being implemented at least in part by modules that run the functions disclosed herein, which modules may be dynamic link libraries (DLLs), static link libraries, functions generated by application programming interfaces (APIs), compiled programs, interpreted programs, scripts, or any other executable instruction sets. Data may be stored in data structures in one or more memory components. Data may be retrieved from a data structure by addressing a link or reference to the data structure.

[0066] Although the following description relates to the components of the accompanying drawings, it should be understood that the operation of routine 700 can also be implemented in many other ways. For example, routine 700 can be implemented at least in part by a processor or local circuit of another remote computer. In addition, one or more operations of routine 700 can be alternatively or additionally implemented by a chipset that works alone or in combination with other software modules. In the example described below, one or more modules of the computing system can receive and / or process the data disclosed herein. Any service, circuit or application suitable for providing the technology disclosed herein can be used for the operations described herein.

[0067] refer to Figure 7 , the routine 700 begins at operation 702 , where the system receives a web request 208 .

[0068] Next at operation 704 , the controller 206 creates the request container 402 using the identification information extracted from the request 208 .

[0069] Next at operation 706 , the controller 206 obtains the derived identifier 322 based on the data included in the received request 208 .

[0070] Next, at operation 708, the request container 202 verifies the derived identifier 322

[0071] Next at operation 710, the request container 202 stores the derived identifier 322 as a derived identifier attribute. The derived identifier attribute is immutable, but it is verified to be properly associated with the tenant 160 before being modified.

[0072] Next at operation 712 , the controller 206 creates a response container 402 associated with the request container 202 .

[0073] Next at operation 714 , the user data APIs are called using the identifier information obtained from the request container 402 along the call path they took when processing the request 208 .

[0074] Next at operation 716 , the results from the user data API are verified as being associated with the tenant 160 before being stored directly in the response container 402 .

[0075] Next at operation 718 , the controller 206 generates a response 570 including the original user data 404 for the my response portion 414 of the response container 402 .

[0076] Next at operation 720 , the controller 206 verifies that the response container 402 is associated with the request container 202 by comparing the request identifier 220 .

[0077] Next at operation 722 , the controller 206 sends the response 570 to the client device 104 .

[0078] Figure 8 Additional details of an example computer architecture 800 for a device (such as the computer or server shown in FIG. 1 ) capable of executing computer instructions (eg, modules or program components described herein) are shown. Figure 8 The computer architecture 800 shown in the figure includes (multiple) processing units 802, a system memory 804 (including random access memory 806 ("RAM") and read only memory ("ROM") 808), and a system bus 810 that couples the memory 804 to the processing unit(s) 802.

[0079] Processing unit(s) (such as processing unit(s) 802) may represent, for example, a CPU-type processing unit, a GPU-type processing unit, a field programmable gate array (FPGA), other types of digital signal processors (DSPs), or other hardware logic components that may be driven by a CPU in some instances. For example, and not limitation, exemplary types of hardware logic components that may be used include application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), complex programmable logic devices (CPLDs), and the like.

[0080] A basic input / output system, containing the basic routines that help to transfer information between elements within the computer architecture 800, such as during startup, is stored in ROM 808. The computer architecture 800 also includes a mass storage device 812 for storing an operating system 814, application(s) 816, modules 818, and other data described herein.

[0081] The mass storage device 812 is connected to the processing unit(s) 802 through a mass storage controller connected to the bus 810. The mass storage device 812 and its associated computer-readable media provide non-volatile storage for the computer architecture 800. Although the description of computer-readable media contained herein refers to mass storage devices, those skilled in the art will appreciate that computer-readable media may be any available computer-readable storage media or communication media that can be accessed by the computer architecture 800.

[0082] Computer-readable media may include computer-readable storage media and / or communication media. Computer-readable storage media may include one or more of volatile memory, non-volatile memory and / or other persistent and / or secondary computer storage media, removable and non-removable computer storage media, implemented in any method or technology for storing information such as computer-readable instructions, data structures, program modules or other data. Thus, computer storage media includes media in tangible and / or physical form that is included in a device and / or in a hardware component that is part of the device or external to the device, including but not limited to random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), phase change memory (PCM), read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, compact disk read-only memory (CD-ROM), digital versatile disks (DVD), optical cards or other optical storage media, magnetic cassettes, magnetic tape, magnetic disk storage, magnetic cards or other magnetic storage devices or media, solid-state memory devices, storage arrays, network attached storage devices, storage area networks, hosted computer storage devices, or any other storage memory, storage devices, and / or storage media that can be used to store and maintain information for access by a computing device.

[0083] In contrast to computer-readable storage media, communication media may embody computer-readable instructions, data structures, program modules, or other data in a modulated data signal (such as a carrier wave or other transmission mechanism). As defined herein, computer storage media does not include communication media. That is, computer-readable storage media itself does not include communication media consisting only of a modulated data signal, a carrier wave, or a propagation signal.

[0084] According to various configurations, the computer architecture 800 can operate in a networked environment using logical connections to remote computers via a network 820. The computer architecture 800 can be connected to the network 820 via a network interface unit 822 connected to the bus 810. The computer architecture 800 can also include an input / output controller 824 for receiving and processing input from a number of other devices, including a keyboard, a mouse, a touch or electronic stylus or pen. Similarly, the input / output controller 824 can provide output to a display screen, a printer, or other type of output device.

[0085] It should be understood that the software components described herein, when loaded into (multiple) processing units 802 and executed, can convert (multiple) processing units 802 and the entire computer architecture 800 from a general-purpose computing system to a special-purpose computing system customized to facilitate the functions presented herein. Processing unit 802 can be composed of any number of transistors or other discrete circuit elements, which can present any number of states individually or collectively. More specifically, in response to executable instructions contained in the software modules disclosed herein, (multiple) processing units 802 can operate as finite state machines. These computer executable instructions can convert (multiple) processing units 802 by specifying how (multiple) processing units 802 convert between states, thereby converting transistors or other discrete hardware elements that constitute (multiple) processing units 802.

[0086] Fig. 9 An exemplary distributed computing environment 900 capable of executing the software components described herein is depicted. Fig. 9 The distributed computing environment 900 shown in can be used to execute any aspects of the software components presented herein. For example, the distributed computing environment 900 can be used to execute various aspects of the software components described herein.

[0087] Thus, the distributed computing environment 900 may include a computing environment 902 operating on, communicating with, or being part of a network 904. The network 904 may include various access networks. One or more client devices 906A-906N (hereinafter collectively and / or generally referred to as "clients 906", and also referred to herein as computing devices 906) may communicate with the computing environment 902 via the network 904. In one illustrated configuration, the client 906 includes a computing device 906A, such as a laptop, desktop computer, or other computing device; a tablet or tablet computing device ("tablet computing device") 906B; a mobile computing device 906C, such as a mobile phone, smart phone, or other mobile computing device; a server computer 906D; and / or other devices 906N. It should be understood that any number of clients 906 may communicate with the computing environment 902.

[0088] In various examples, computing environment 902 includes server 908, data storage device 910, and one or more network interfaces 912. Server 908 can host various services, virtual machines, portals, and / or other resources. In the configuration shown, server 908 hosts virtual machine 914, web portal 916, mailbox service 918, storage service 920, and / or social network service 922. Fig. 9 As shown, server 908 may also host other services, applications, portals, and / or other resources (“other resources”) 924 .

[0089] As described above, the computing environment 902 may include a data store 910. According to various embodiments, the functionality of the data store 910 is provided by one or more databases operating on or in communication with the network 904. The functionality of the data store 910 may also be provided by one or more servers configured to host data for the computing environment 902. The data store 910 may include, host, or provide one or more real or virtual data stores 926A-926N (hereinafter collectively and / or collectively referred to as "data stores 926"). The data store 926 is configured to host data used or created by the server 708 and / or other data. That is, the data store 926 may also host or store web documents, word documents, presentation documents, data structures, algorithms executed by the recommendation engine, and / or other data used by any application. Various aspects of the data store 926 may be associated with a service for storing files.

[0090] The computing environment 902 can communicate with or be accessed by a network interface 912. The network interface 912 may include various types of network hardware and software for supporting communications between two or more computing devices (including, but not limited to, computing devices and servers). It should be understood that the network interface 912 may also be used to connect to other types of networks and / or computer systems.

[0091] It should be understood that the distributed computing environment 900 described herein can provide any number of virtual computing resources and / or can be configured to perform other distributed computing functions of any aspect of the software elements disclosed herein for any aspect of the software elements disclosed herein. According to various implementations of the concepts and technologies disclosed herein, the distributed computing environment 900 provides the software functions described herein as services to computing devices. It should be understood that computing devices may include real or virtual machines, including but not limited to server computers, web servers, personal computers, mobile computing devices, smart phones and / or other devices. Therefore, various configurations of the concepts and technologies disclosed herein enable any device configured to access the distributed computing environment 900 to utilize the functions described herein to provide the technology disclosed herein and other aspects.

[0092] This disclosure is supplemented by the following example clauses.

[0093] Example 1: A method comprising: receiving a web request; extracting an identifier of a tenant from the web request; initializing a read-only property of a request container using the identifier; creating a response container associated with the request container; calling a user data API using the request container and the response container, so that the user data API: calls a data access API using the identifier stored in the read-only property of the request container, and stores original user data returned from the data access API in the response container, wherein the response container verifies that the original user data is associated with the tenant; generating an http response, the http response including the original user data stored in the response container; and sending the http response.

[0094] Example 2: According to the method of Example 1, it also includes: obtaining a derived token; verifying that the derived token is associated with the tenant; and storing the derived token in a derived token attribute of the request container, wherein the user data API calls the data access API using the derived token stored in the derived token attribute.

[0095] Example 3: The method of Example 2, wherein the web request includes a user token, and wherein the derived token includes a representative token obtained using the user token.

[0096] Example 4: The method of example 2, wherein the association between the derived token and the tenant is verified by comparing the identifier to a separate identifier stored in the derived token.

[0097] Example 5: A method according to Example 1, wherein the original user data is stored in a response container by calling a function with the original user data and a request container, and wherein the association between the original user data and the tenant is verified by comparing a tenant identifier from the request container used to call the data access API and the request container associated with the response container.

[0098] Example 6: The method of example 1, wherein the response container is associated with the request container by storing a request identifier of the request container in the response container.

[0099] Example 7: The method according to Example 6 further includes: before sending the http response, verifying that the response container is associated with the request container by comparing the request identifier in the request container with the request identifier in the response container.

[0100] Example 8: The method according to Example 1 further includes: analyzing the source code of the user data API to verify that the data access API is called using the read-only property of the request container, and the original user data is directly stored in the response container.

[0101] Example 9: A computer-readable storage medium having computer-executable instructions stored thereon, which, when executed by a processing device, causes the processing device to: receive a request; extract an identifier from the request; initialize a read-only property of a request container using the identifier; call a data access API using the identifier stored in the read-only property of the request container; generate a response, the response including original user data received from the data access API; and send the response.

[0102] Example 10: Computer-readable storage medium according to Example 9, wherein the computer-executable instructions further cause the processing device to: obtain a derived token based on data included in the request; verify that the derived token is associated with the identifier; and store the derived token in a derived token attribute of the request container, wherein the data access API is called using the derived token stored in the derived token attribute.

[0103] Example 11: The computer-readable storage medium of example 10, wherein the request includes a user token, and wherein the derived token includes a role-based access control credential obtained using the user token.

[0104] Example 12: Computer-readable storage medium according to Example 11, wherein the computer-executable instructions further cause the processing device to: create a response container associated with the request container, wherein original user data returned from the data access API is verified to be associated with the identifier before being stored in the response container; and wherein the response is generated using the original user data stored in the response container.

[0105] Example 13: The computer-readable storage medium of Example 9, wherein the request comprises a web request, wherein the identifier is obtained from an http context generated when processing the web request, and wherein the request container is created prior to executing the user code.

[0106] Example 14: The computer-readable storage medium of Example 9, wherein the computer-executable instructions further cause the processing device to: analyze the source code of the data access API to identify parameters marked as user input; analyze the source code of the data access API call to verify that the value passed to the parameter marked as user input originates from the request container.

[0107] Example 15: A computing device, comprising: a computer-readable storage medium having computer-executable instructions stored thereon; and a processor that executes the computer-executable instructions, causing the computing device to: receive a request; extract an identifier from the request; initialize a read-only property of a request container using the identifier; create a response container associated with the request container; call a user data API using the request container and the response container, causing the user data API to: call a data access API using the identifier stored in the read-only property of the request container, and store original user data returned from the data access API in the response container, wherein the response container verifies that the original user data is associated with the identifier; generate an HTTP response, the HTTP response including the original user data obtained from the response container; and send the HTTP response.

[0108] Example 16: A computing device according to Example 15, wherein the computer executable instructions further cause the processing device to: obtain a derived token based on data in the request; verify that the derived token is associated with the identifier; and store the derived token in a derived token attribute of the request container, wherein the user data API calls the data access API using the derived token stored in the derived token attribute.

[0109] Example 17: The computing device of example 16, wherein the derived token includes an organization identifier obtained using the identifier.

[0110] Example 18: A computing device according to Example 15, wherein the computer executable instructions further cause the processing device to: analyze the source code of the data access API to identify parameters marked as user input; analyze the source code of the user data API to verify that the values ​​passed to the parameters marked as user input originate from the request container.

[0111] Example 19: The computing device of example 15, wherein the computer-executable instructions further cause the processing device to: analyze source code of the user data API to verify that a value returned from the data access API is directly stored in the response container.

[0112] Example 20: A computing device according to Example 15, wherein the computer executable instructions further cause the processing device to: analyze the source code of the data access API to identify parameters marked as user input; analyze the source code of the user data API to verify that values ​​passed to parameters marked as user input originate from immutable properties or derived identifier properties of the request container; and analyze the source code of the user data API to verify that only values ​​returned from the data access API are stored directly in the response container.

[0113] Although certain example embodiments have been described, these embodiments are presented only as examples and are not intended to limit the scope of the inventions disclosed herein. Therefore, nothing in the foregoing description is intended to imply that any particular feature, characteristic, step, module, or frame is necessary or indispensable. In fact, the novel methods and systems described herein may be embodied in a variety of other forms; moreover, various omissions, substitutions, and changes in the form of the methods and systems described herein may be made without departing from the spirit of the inventions disclosed herein. The attached claims and their equivalents are intended to cover such forms or modifications that fall within the scope and spirit of certain inventions disclosed herein.

[0114] It should be understood that any reference to "first", "second", etc. elements in the summary and / or detailed description is not intended to and should not be interpreted as necessarily corresponding to any reference to "first", "second", etc. elements in the claims. On the contrary, any use of "first" and "second" in the summary, detailed description, and / or claims can be used to distinguish two different instances of the same element.

[0115] Finally, although various techniques have been described in language specific to structural features and / or methodological acts, it should be understood that the subject matter defined in the accompanying representations is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as example forms of implementing the claimed subject matter.

Claims

1. A method comprising: Receive web requests; extracting an identifier of the tenant from the web request; Initializing a read-only attribute of a request container using the identifier; Creating a response container associated with the request container; The user data API is called by using the request container and the response container, so that the user data API: calling a data access API using the identifier stored in the read-only attribute of the request container, and storing the original user data returned from the data access API in the response container, wherein the response container verifies that the original user data is associated with a tenant; generating an http response, the http response including the original user data stored in the response container; and Send the http response.

2. The method according to claim 1, further comprising: Get a derived token; verifying that the derived token is associated with the tenant; as well as The derived token is stored in a derived token attribute of the request container, wherein the user data API calls the data access API using the derived token stored in the derived token attribute. 3 . The method of claim 2 , wherein the association between the derived token and the tenant is verified by comparing the identifier with a separate identifier stored in the derived token.

4. A method according to claim 1, wherein the original user data is stored in the response container by calling the original user data and a function of a request container for calling the data access API, and wherein the association between the original user data and the tenant is verified by comparing the tenant identifier from the request container for calling the data access API and the request container associated with the response container.

5. The method according to claim 4, further comprising: Before sending the http response, it is verified that the response container is associated with the request container by comparing the request identifier in the request container with the request identifier in the response container.

6. The method according to claim 1, further comprising: The source code of the user data API is analyzed to verify that the data access API is called using the read-only property of the request container and the original user data is directly stored in the response container.

7. A computer-readable storage medium having computer-executable instructions stored thereon, which, when executed by a processing device, cause the processing device to: Receive the request; extracting an identifier from the request; Initializing a read-only attribute of a request container using the identifier; Invoking a data access API using the identifier stored in the read-only attribute of the request container; generating a response including the raw user data received from the data access API; and The response is sent.

8. The computer-readable storage medium of claim 7, wherein the computer-executable instructions further cause the processing device to: obtaining a derived token based on data included in the request; verifying that the derived token is associated with the identifier; and The derived token is stored in a derived token attribute of the request container, wherein the data access API is called using the derived token stored in the derived token attribute.

9. The computer-readable storage medium of claim 8, wherein the request includes a user token, and wherein the derived token includes a role-based access control credential obtained using the user token.

10. The computer-readable storage medium of claim 9, wherein the computer-executable instructions further cause the processing device to: Creating a response container associated with the request container, wherein the original user data returned from the data access API is verified to be associated with the identifier before being stored in the response container; and wherein the response is generated using the original user data stored in the response container.

11. The computer-readable storage medium of claim 7, wherein the request comprises a web request, wherein the identifier is obtained from an http context generated when processing the web request, and wherein the request container is created before executing user code.

12. A computing device comprising: a computer-readable storage medium having computer-executable instructions stored thereon; as well as a processor that executes the computer-executable instructions to cause the computing device to: Receive the request; extracting an identifier from the request; Initializing a read-only attribute of a request container using the identifier; Creating a response container associated with the request container; The user data API is called by using the request container and the response container, so that the user data API: calling a data access API using the identifier stored in the read-only attribute of the request container, and storing raw user data returned from the data access API in the response container, wherein the response container verifies that the raw user data is associated with the identifier; generating an http response, the http response including the original user data obtained from the response container; and Send the http response.

13. The computing device of claim 12, wherein the computer executable instructions further cause the processing device to: analyzing source code of the data access API to identify parameters marked as user input; Source code of the user data API is analyzed to verify that values ​​passed to the parameters marked as user input originate from the request container.

14. The computing device of claim 12, wherein the computer executable instructions further cause the processing device to: The source code of the user data API is analyzed to verify that the values ​​returned from the data access API are directly stored in the response container.

15. The computing device of claim 12, wherein the computer-executable instructions further cause the processing device to: analyzing source code of the data access API to identify parameters marked as user input; analyzing source code of the user data API to verify that a value passed to the parameter marked as user input originates from an immutable property or a derived identifier property of the request container; as well as The source code of the user data API is analyzed to verify that only values ​​returned from the data access API are stored directly in the response container.

Images