Remote execution using global identity

Abstract

Embodiments of the present disclosure can provide a simplified process for performing operations such as data sharing and data replication using multiple accounts. A global identity (also referred to as an organization user) can be employed, where the global identity can have access to multiple accounts on the same or different deployments. The global identity can switch between accounts according to its login session and perform various tasks in the context of different accounts without requiring further authentication.

Description

[0001] Cross-reference to related applications

[0002] This application claims the benefit of priority to U.S. Patent Application Serial No. 16 / 931,808, filed July 17, 2020, the contents of which are incorporated herein by reference in their entirety. Technical Field

[0003] This disclosure generally relates to the remote execution of tasks associated with different accounts.

[0004] background

[0005] Databases and other data processing systems can be implemented in different configurations and deployments. For example, cloud database systems can be provided through a cloud platform that allows organizations and users to store, manage, and retrieve data from the cloud. In addition to using different types of deployments, organizations can also leverage deployments in different regions. For instance, a cloud database system can be implemented as a public deployment where multiple accounts can share processing resources and / or storage devices. A cloud database system can also be implemented as a private deployment where processing resources and / or storage devices are dedicated and isolated.

[0006] However, performing certain operations in such a system can be cumbersome. Some operations may involve the participation of multiple accounts. For example, an operation might include performing a first task using a first account, then performing a second task using a second account, and so on. Therefore, a user would have to log in to the first account to perform the first task, log out, then log in to the second account to perform the second task, and so on, leading to an inefficient process. Brief description of the attached diagram

[0008] The various accompanying drawings illustrate only exemplary embodiments of this disclosure and should not be construed as limiting its scope.

[0009] Figure 1 An example computing environment is shown according to some example embodiments, in which a network-based data warehouse system can implement streaming on shared database objects.

[0010] Figure 2 This is a block diagram illustrating components of a computing service manager according to some example embodiments.

[0011] Figure 3 This is a block diagram illustrating components of an execution platform according to some example embodiments.

[0012] Figure 4 This is a block diagram illustrating a multi-deployment environment according to some example embodiments.

[0013] Figure 5This is a block diagram illustrating a relational tree of global identity according to some example embodiments.

[0014] Figure 6 This is a block diagram illustrating a login session according to some example embodiments.

[0015] Figure 7 A flowchart for performing operations using global identity is shown, according to some example embodiments.

[0016] Figure 8 A flowchart for remote processing is shown according to some example embodiments.

[0017] Figures 9A-9B A flowchart for operating a login session is shown according to some example embodiments.

[0018] Figure 10 A schematic representation of a machine in the form of a computer system according to some embodiments of the present disclosure is shown, within which a set of instructions can be executed to cause the machine to perform any or more of the methods discussed herein.

[0019] Detailed description

[0020] The following description includes systems, methods, techniques, instruction sequences, and computer program products embodying illustrative embodiments of the present disclosure. In the following description, numerous specific details are set forth for purposes of explanation to provide an understanding of various embodiments of the subject matter of the invention. However, it will be apparent to those skilled in the art that embodiments of the subject matter of the invention can be practiced without these specific details. Generally, well-known examples of instructions, protocols, structures, and techniques need not be shown in detail.

[0021] Embodiments of this disclosure can provide a streamlined process for performing operations such as data sharing and data replication using multiple accounts. A global identity (also known as an organization user) can be employed, where the global identity can have access to multiple accounts on the same or different deployments. The global identity can switch between accounts based on its login session and perform various tasks in the context of different accounts without further authentication. From the user's perspective, task execution may appear the same regardless of which account the global identity uses, because the login session can be used for all task execution. However, in the backend, remote sessions and proxy users can be employed to perform tasks using different accounts. Therefore, these tasks can be executed in the context of other accounts from the login session.

[0022] Figure 1An example shared data processing platform 100 according to some embodiments of the present disclosure is illustrated. To avoid obscuring the subject matter of the invention with unnecessary detail, various functional components not closely related to conveying the understanding of the subject matter have been omitted from the figures. However, those skilled in the art will readily recognize that various additional functional components may be included as part of the shared data processing platform 100 to facilitate additional functionality not specifically described herein.

[0023] As shown in the figure, the shared data processing platform 100 includes a network-based data warehouse system 102 and a cloud computing storage platform 104 (e.g., a storage platform, ...). Services, Microsoft or Google Cloud The network-based data warehouse system 102 is a network-based system used for storing and accessing data in an integrated manner (e.g., storing data internally and accessing data located remotely externally), and reporting and analyzing integrated data from one or more different sources (e.g., cloud storage platform 104). The cloud storage platform 104 includes multiple computing machines and provides computing system resources, such as data storage and computing power, to the network-based data warehouse system 102 on demand. While in Figure 1 The illustrated embodiments depict a data warehouse, but other embodiments may include other types of databases or other data processing systems.

[0024] Remote computing device 106 (e.g., a user device such as a laptop computer) includes one or more computing machines (e.g., user devices such as laptop computers) that execute remote software component 108 (e.g., a cloud service accessed by a browser) to provide additional functionality to users of the web-based data warehouse system 102. Remote software component 108 includes a set of machine-readable instructions (e.g., code) that, when executed by remote computing device 106, enable remote computing device 106 to provide certain functionalities. Remote software component 108 can manipulate input data and generate resulting data based on processing, analyzing, or otherwise transforming the input data. As an example, as discussed in further detail below, remote software component 108 can be a data provider or data consumer that enables database tracing processes (e.g., streams on shared tables and views).

[0025] The network-based data warehouse system 102 includes an access management system 110, a computing service manager 112, an execution platform 114, and a database 116. The access management system 110 enables administrative users to manage access to resources and services provided by the network-based data warehouse system 102. Administrative users can create and manage users, roles, and groups, and use permissions to allow or deny access to resources and services. As discussed in further detail below, the access management system 110 can store shared data that securely manages shared access to storage resources of the cloud computing storage platform 104 among different users of the network-based data warehouse system 102.

[0026] The Compute Service Manager 112 coordinates and manages the operation of the network-based data warehouse system 102. The Compute Service Manager 112 also performs query optimization and compilation, and manages clusters of computing services (e.g., virtual warehouses, virtual machines, EC2 clusters) that provide computing resources. The Compute Service Manager 112 can support any number of client accounts, such as end users providing data storage and retrieval requests, system administrators managing the systems and methods described herein, and other components / devices interacting with the Compute Service Manager 112.

[0027] The computing service manager 112 is also coupled to a database 116, which is associated with all the data stored on the shared data processing platform 100. Database 116 stores data relating to various functions and aspects associated with the network-based data warehouse system 102 and its users.

[0028] In some embodiments, database 116 includes data stored in a remote data storage system and a summary of the data available from one or more local caches. Additionally, database 116 may include information about how the data is organized in the remote data storage system and local caches. Database 116 allows systems and services to determine whether a piece of data needs to be accessed without loading or accessing the actual data from storage devices. Compute service manager 112 is also coupled to execution platform 114, which provides multiple computing resources (e.g., virtual warehouses) for performing various data storage and data retrieval tasks, as discussed in more detail below.

[0029] The execution platform 114 is coupled to multiple data storage devices 124-1 to 124-n, which are part of a cloud storage platform 104. In some embodiments, data storage devices 124-1 to 124-n are cloud-based storage devices located in one or more geographical locations. For example, data storage devices 124-1 to 124-n may be part of a public cloud infrastructure or a private cloud infrastructure. Data storage devices 124-1 to 124-n may be hard disk drives (HDDs), solid-state drives (SSDs), storage device clusters, Amazon S3 storage systems, or any other data storage technology. Additionally, the cloud storage platform 104 may include a distributed file system (e.g., Hadoop Distributed File System (HDFS)), an object storage system, etc.

[0030] Execution platform 114 includes multiple compute nodes (e.g., virtual repositories). A set of processes on the compute nodes executes a query plan compiled by compute service manager 112. This set of processes may include: a first process executing the query plan; a second process that uses a least recently used (LRU) policy to monitor and delete micro-partition files and implements an out-of-memory (OOM) error mitigation process; a third process that extracts health information from process logs and status information to send back to compute service manager 112; a fourth process that establishes communication with compute service manager 112 after system boot; and a fifth process that handles all communication with the compute cluster for a given job provided by compute service manager 112 and transmits information back to compute service manager 112 and other compute nodes of execution platform 114.

[0031] The cloud storage platform 104 also includes an access management system 118 and a web proxy 120. Like the access management system 110, the access management system 118 allows users to create and manage users, roles, and groups, and uses permissions to allow or deny access to cloud services and resources. The access management system 110 of the network-based data warehouse system 102 and the access management system 118 of the cloud storage platform 104 can communicate and share information to enable access to and management of resources and services shared by users of both the network-based data warehouse system 102 and the cloud storage platform 104. The web proxy 120 handles tasks involved in accepting and processing concurrent API calls, including traffic management, authorization and access control, monitoring, and API version management. The web proxy 120 provides HTTP proxy services for creating, publishing, maintaining, securing, and monitoring APIs (such as REST APIs).

[0032] In some embodiments, communication links between components of the shared data processing platform 100 are implemented via one or more data communication networks. These data communication networks can utilize any communication protocol and any type of communication medium. In some embodiments, the data communication network is a combination of two or more data communication networks (or subnetworks) coupled to each other. In alternative embodiments, these communication links are implemented using any type of communication medium and any communication protocol.

[0033] like Figure 1 As shown, data storage devices 124-1 to 124-N are decoupled from the computing resources associated with execution platform 114. That is, new virtual repositories can be created and terminated within execution platform 114, and additional data storage devices can be created and terminated independently on cloud storage platform 104. This architecture supports dynamic changes to the network-based data warehouse system 102 based on changing data storage / retrieval needs and changing user and system access requirements to the shared data processing platform 100. Support for dynamic changes allows the network-based data warehouse system 102 to scale rapidly in response to evolving needs for systems and components within the network-based data warehouse system 102. The decoupling of computing resources from data storage devices 124-1 to 124-n supports the storage of large amounts of data without requiring correspondingly large amounts of computing resources. Similarly, this decoupling of resources supports a significant increase in computing resources used at a given time without requiring a corresponding increase in available data storage resources. Furthermore, the decoupling of resources allows different accounts to handle the creation of additional computing resources to process data shared by other users without impacting those users' systems. For example, a data provider may have three computing resources and share data with a data consumer, and the data consumer may generate new computing resources to perform queries on the shared data, wherein the new computing resources are managed by the data consumer without affecting or interacting with the data provider's computing resources.

[0034] The computing service manager 112, database 116, execution platform 114, cloud computing storage platform 104, and remote computing device 106 are in Figure 1The components are shown as separate parts. However, each of the compute service manager 112, database 116, execution platform 114, cloud storage platform 104, and remote computing environment can be implemented as a distributed system (e.g., multiple systems / platforms distributed across multiple geographical locations) connected via APIs and access information (e.g., tokens, login data). Furthermore, each of the compute service manager 112, database 116, execution platform 114, and cloud storage platform 104 can scale up or down (independently) according to the needs of changes in received requests and changes in the shared data processing platform 100. Therefore, in the described embodiment, the network-based data warehouse system 102 is dynamic and supports periodic changes to meet current data processing needs.

[0035] During typical operation, the network-based data warehouse system 102 processes multiple jobs (e.g., queries) determined by the compute service manager 112. These jobs are scheduled and managed by the compute service manager 112 to determine when and how to execute them. For example, the compute service manager 112 may divide the jobs into multiple discrete tasks and determine what data is needed to execute each of the multiple discrete tasks. The compute service manager 112 may assign each of the multiple discrete tasks to one or more nodes of the execution platform 114 to process the task. The compute service manager 112 may determine what data is needed to process the task and further determine which nodes within the execution platform 114 are best suited to process the task. Some nodes may have already cached the data required to process the task (since these nodes have recently downloaded data from the cloud storage platform 104 for previous jobs), making them good candidates for processing the task. Metadata stored in the database 116 helps the compute service manager 112 determine which nodes in the execution platform 114 have cached at least a portion of the data required to process the task. One or more nodes in execution platform 114 use data cached by these nodes, as well as data retrieved from cloud storage platform 104 when necessary, to process tasks. It is desirable to retrieve as much data as possible from the cache within execution platform 114, as retrieval is typically much faster than retrieving data from cloud storage platform 104.

[0036] like Figure 1As shown, the shared data processing platform 100 separates the execution platform 114 from the cloud storage platform 104. In this arrangement, the processing resources and cache resources in the execution platform 114 operate independently of the data storage devices 124-1 to 124-n in the cloud storage platform 104. Therefore, the computing resources and cache resources are not limited to specific data storage devices 124-1 to 124-n. Instead, all computing resources and all cache resources can retrieve data from any data storage resource in the cloud storage platform 104 and store data in any data storage resource in the cloud storage platform 104.

[0037] Figure 2 This is a block diagram illustrating components of a computing service manager 112 according to some embodiments of the present disclosure. Figure 2 As shown, request processing service 202 manages received data storage requests and data retrieval requests (e.g., jobs to be performed on database data). For example, request processing service 202 can determine the data required to process a received query (e.g., a data storage request or a data retrieval request). This data may be stored in a cache within execution platform 114 or in a data storage device within cloud storage platform 104. Management console service 204 supports access to various systems and processes by administrators and other system administrators. Additionally, management console service 204 can receive requests to execute jobs and monitor workloads on the system. According to some example embodiments, and discussed in further detail below, streaming sharing engine 225 manages change tracking of database objects (e.g., data sharing (e.g., shared tables) or shared views).

[0038] The compute service manager 112 also includes a job compiler 206, a job optimizer 208, and a job executor 210. The job compiler 206 parses a job into multiple discrete tasks and generates execution code for each of these tasks. The job optimizer 208 determines the optimal method for executing the multiple discrete tasks based on the data to be processed. The job optimizer 208 also handles various data pruning operations and other data optimization techniques to improve the speed and efficiency of job execution. The job executor 210 executes the execution code of jobs received from the queue or determined by the compute service manager 112.

[0039] The job scheduler and coordinator 212 sends received jobs to appropriate services or systems for compilation, optimization, and dispatch to execution platform 114. For example, jobs can be prioritized and processed in that order of priority. In embodiments, the job scheduler and coordinator 212 determines priorities for internal jobs scheduled by the compute service manager 112 and other “external” jobs (e.g., user queries) that can be scheduled by other systems in the database but can utilize the same processing resources in execution platform 114. In some embodiments, the job scheduler and coordinator 212 identifies or assigns specific nodes in execution platform 114 to handle specific tasks. The virtual repository manager 214 manages the operation of multiple virtual repositories implemented in execution platform 114. As discussed below, each virtual repository includes multiple execution nodes, and each execution node includes a cache and processor (e.g., a virtual machine, an operating system-level container execution environment).

[0040] Additionally, the compute service manager 112 includes a configuration and metadata manager 216, which manages information related to data stored in remote data storage devices and local caches (i.e., caches within the execution platform 114). The configuration and metadata manager 216 uses metadata to determine which data micro-partitions need to be accessed to retrieve data for processing specific tasks or jobs. A monitor and workload analyzer 218 monitors the processes executed by the compute service manager 112 and manages task (e.g., workload) allocation across virtual warehouses and execution nodes within the execution platform 114. The monitor and workload analyzer 218 also reallocates tasks as needed, based on the changing workload throughout the network-based data warehouse system 102, and can also reallocate tasks based on workload queries from users (e.g., "external") that can also be processed by the execution platform 114. The configuration and metadata manager 216 and the monitor and workload analyzer 218 are coupled to the data storage device 220. Figure 2 Data storage device 220 in the context refers to any data storage device within the network-based data warehouse system 102. For example, data storage device 220 could represent a cache in execution platform 114, a storage device in cloud storage platform 104, or any other storage device.

[0041] Figure 3 This is a block diagram illustrating components of an execution platform 114 according to some embodiments of the present disclosure. Figure 3As shown, execution platform 114 includes multiple virtual repositories, which are elastic clusters of compute instances such as virtual machines. In the example shown, the virtual repositories include virtual repository 1, virtual repository 2, and virtual repository n. Each virtual repository (e.g., an EC2 cluster) includes multiple execution nodes (e.g., virtual machines), and each execution node includes a data cache and a processor. Virtual repositories can execute multiple tasks in parallel by using multiple execution nodes. As discussed herein, execution platform 114 can add new virtual repositories and discard existing ones in real time based on the current processing needs of the system and users. This flexibility allows execution platform 114 to quickly deploy large amounts of computing resources when needed, without being forced to continue paying for them when they are no longer needed. All virtual repositories can access data from any data storage device (e.g., any storage device in cloud storage platform 104).

[0042] although Figure 3 Each virtual repository shown includes three execution nodes, but a particular virtual repository can include any number of execution nodes. Furthermore, the number of execution nodes in a virtual repository is dynamic, allowing new execution nodes to be created when there is additional demand and existing execution nodes to be deleted when they are no longer needed (e.g., upon querying or completion of a task).

[0043] Each virtual repository can access Figure 1 The data storage devices 124-1 to 124-n shown are all of these. Therefore, the virtual warehouse does not need to be assigned to a specific data storage device 124-1 to 124-n, but can access data from any of the data storage devices 124-1 to 124-n within the cloud computing storage platform 104. Similarly, Figure 3 Each execution node shown can access data from any of the data storage devices 124-1 to 124-n. For example, storage device 124-1 for a first user (e.g., a provider account user) can be shared with worker nodes in a virtual repository for another user (e.g., a consumer account user), allowing that other user to create databases (e.g., read-only databases) and directly use data in storage device 124-1 without needing to copy the data (e.g., copy it to a new disk managed by the consumer account user). In some embodiments, a particular virtual repository or execution node can be temporarily assigned to a particular data storage device, but that virtual repository or execution node can later access data from any other data storage device.

[0044] exist Figure 3In the example, virtual repository 1 includes three execution nodes 302-1, 302-2, and 302-n. Execution node 302-1 includes a cache 304-1 and a processor 306-1. Execution node 302-2 includes a cache 304-2 and a processor 306-2. Execution node 302-n includes a cache 304-n and a processor 306-n. Each execution node 302-1, 302-2, and 302-n is associated with processing one or more data storage and / or data retrieval tasks. For example, a virtual repository may process data storage and data retrieval tasks associated with internal services (e.g., clustering services, materialized view refresh services, file compression services, stored procedure services, or file upgrade services). In other embodiments, a particular virtual repository may process data storage and data retrieval tasks associated with a particular data storage system or a particular category of data.

[0045] Similar to Virtual Repository 1 discussed above, Virtual Repository 2 includes three execution nodes: 312-1, 312-2, and 312-n. Execution node 312-1 includes cache 314-1 and processor 316-1. Execution node 312-2 includes cache 314-2 and processor 316-2. Execution node 312-n includes cache 314-n and processor 316-n. Additionally, Virtual Repository 3 includes three execution nodes: 322-1, 322-2, and 322-n. Execution node 322-1 includes cache 324-1 and processor 326-1. Execution node 322-2 includes cache 324-2 and processor 326-2. Execution node 322-n includes cache 324-n and processor 326-n.

[0046] In some embodiments, relative to the data being cached by the execution node Figure 3 The execution nodes shown are stateless. For example, these execution nodes do not store or otherwise maintain state information about the execution node, or the data is cached by the specific execution node. Therefore, in the event of an execution node failure, it can be transparently replaced by another node. Because there is no state information associated with the failed execution node, a new (replacement) execution node can easily replace the failed node without considering the need to recreate specific state.

[0047] although Figure 3 Each of the execution nodes shown includes a data cache and a processor; however, alternative embodiments may include execution nodes containing any number of processors and any number of caches. Furthermore, the size of the cache may vary between different execution nodes. Figure 3The cache shown stores data retrieved from one or more data storage devices in the cloud storage platform 104 (e.g., S3 objects recently accessed by a given node) on the local execution node (e.g., a local disk). In some example embodiments, the cache stores the file header and individual columns of the file when a query only downloads the columns required by the query.

[0048] To improve cache hit rates and avoid overlapping redundant data being stored in node caches, job optimizer 208 uses a consistent hashing scheme to distribute the input file set to nodes, hashing the table filenames of the accessed data (e.g., data in database 116 or database 122). According to some example embodiments, subsequent or concurrent queries accessing the same table file will therefore be executed on the same node.

[0049] As discussed, nodes and virtual repositories can dynamically change in response to environmental conditions (e.g., disaster scenarios), hardware / software issues (e.g., failures), or management changes (e.g., moving from a large cluster to a smaller cluster to reduce costs). In some example embodiments, when the node set changes, no data is immediately reshuffled. Instead, a least recently used replacement strategy is implemented to eventually replace cached content lost across multiple jobs. Therefore, caching reduces or eliminates bottlenecks that occur in platforms that continuously retrieve data from remote storage systems. Instead of repeatedly accessing data from remote storage devices, the systems and methods described herein access data from caches within execution nodes, which is significantly faster and avoids the bottlenecks discussed above. In some embodiments, the cache is implemented using a high-speed storage device that provides fast access to the cached data. Each cache can store data from any storage device in the cloud storage platform 104.

[0050] Furthermore, cache resources and compute resources can vary across different execution nodes. For example, one execution node may contain a large amount of compute resources and a minimal amount of cache resources, making it useful for tasks requiring significant compute resources. Another execution node may contain a large amount of cache resources and a minimal amount of compute resources, making it useful for tasks requiring the caching of large amounts of data. Yet another execution node may contain cache resources that provide faster input-output operations, which is useful for tasks requiring the rapid scanning of large amounts of data. In some embodiments, execution platform 114 implements skew handling to distribute work among cache resources and compute resources associated with a particular execution, where this distribution can be further based on the expected tasks to be performed by the execution nodes. For example, if the task performed by an execution node becomes more processor-intensive, more processing resources can be allocated to the execution node. Similarly, if the task performed by an execution node requires a larger cache capacity, more cache resources can be allocated to the execution node. Additionally, due to various issues (e.g., virtualization problems, network overhead), some nodes may execute much slower than others. In some example embodiments, a file-stealing scheme is used to address the imbalance at the scan level. Specifically, whenever a node process completes scanning its set of input files, it requests additional files from other nodes. If one of the other nodes receives such a request, that node analyzes its own set (e.g., how many files remain in the set of input files when the request is received) and then transfers ownership of one or more remaining files over the duration of the current job (e.g., a query). The requesting node (e.g., a file-stealing node) then receives the data (e.g., header data) and downloads the files from the cloud storage platform 104 (e.g., from data storage device 124-1) instead of from the transferring node. In this way, the lagging node can transfer files via file theft in a manner that does not worsen the load on the lagging node.

[0051] Although virtual repositories 1, 2, and n are associated with the same execution platform 114, they can be implemented using multiple computing systems located in multiple geographical locations. For example, virtual repository 1 may be implemented by a computing system located in a first geographical location, while virtual repository 2 and virtual repository n may be implemented by another computing system located in a second geographical location. In some embodiments, these different computing systems are cloud-based computing systems maintained by one or more different entities.

[0052] In addition, each virtual repository in Figure 3The virtual repository is shown as having multiple execution nodes. Multiple computing systems located in multiple geographic locations can be used to implement multiple execution nodes associated with each virtual repository. For example, an instance of virtual repository 1 implements execution nodes 302-1 and 302-2 on a computing platform in one geographic location, while implementing execution node 302-n on a different computing platform in another geographic location. The selection of a specific computing system to implement execution nodes can depend on various factors, such as the resource level required for a particular execution node (e.g., processing resource requirements and cache requirements), the resources available at the specific computing system, the communication capabilities of networks within or between geographic locations, and which computing systems have already implemented other execution nodes in the virtual repository.

[0053] The execution platform 114 is also fault-tolerant. For example, if a virtual repository fails, it will be quickly replaced by a different virtual repository located in a different geographical location.

[0054] The specific execution platform 114 may include any number of virtual repositories. Furthermore, the number of virtual repositories in the specific execution platform is dynamic, allowing the creation of new virtual repositories when additional processing and / or caching resources are needed. Similarly, existing virtual repositories can be deleted when the resources associated with them are no longer necessary.

[0055] In some embodiments, virtual repositories can operate on the same data in the cloud storage platform 104, but each virtual repository has its own execution node with independent processing and caching resources. This configuration allows requests on different virtual repositories to be processed independently without interference between them. This independent processing, combined with the ability to dynamically add and remove virtual repositories, supports adding new processing power for new users without impacting the performance observed by existing users.

[0056] Figure 4 This illustrates an example multi-deployment environment based on some example embodiments. A deployment may include multiple components, such as a metadata store, a front-end layer, a load balancing layer, a data warehouse, etc., as described above. Figure 1-3 The discussion focuses on providing multi-deployment environments for one or more organizations, which can include multiple public and private deployments. Public deployments can be implemented as multi-tenant environments where each tenant or account shares processing and / or storage resources. For example, in a public deployment, multiple accounts can share metadata storage, front-end tiers, load balancing tiers, data warehouses, etc. On the other hand, private deployments can be implemented as dedicated, isolated environments where processing and / or storage resources can be dedicated. Therefore, in some configurations, private deployments can provide better security and better performance.

[0057] exist Figure 4 In this example, Private Deployment 1 (PRD1) 410 can be provided in Cloud Provider Region A, and Public Deployment 1 (PUD1) 420 can also be provided in Cloud Provider Region A. Private Deployment 2 (PRD2) 430 can be provided in another Cloud Provider Region B, and Public Deployment 2 (PUD2) 440 can also be provided in Cloud Provider Region B. For example, Cloud Provider Regions A and B can be different geographic regions.

[0058] In this example, different deployments 410, 420, 430, and 440 are configured to communicate with each other. For example, they can each send / receive messages to / from each other in a global messaging layer. To this end, each deployment can include a deployment object corresponding to other communicationally coupled deployments, representing a link to the target deployment. For example, PRD1 410 can include PUD1 deployment object 412, PUD2 deployment object 414, and PRD2 deployment object 416. PUD1 420 can include PRD1 deployment object 422, PRD2 deployment object 424, and PUD2 deployment object 426. PRD2 430 can include PRD1 deployment object 432, PUD1 deployment object 434, and PUD2 deployment object 436. PUD2 440 can include PRD1 deployment object 442, PUD1 deployment object 444, and PRD2 deployment object 446. In this embodiment, a metadata store can be used to perform communication between deployments. For example, one deployment can write a message to the metadata store, while another deployment can read the message from the metadata store.

[0059] Furthermore, each deployment can have a different account associated with it. For example, PRD1 410 can have an associated account AF; PUD1 420 can have an associated account GL; PRD2 430 can have an associated account MR; and PUD2 440 can have an associated account SX. Certain operations (such as copying or sharing data) may involve tasks to be performed by different accounts within the same or different deployments.

[0060] Global identities (also known as organization users) and remoting, as described in this article, can be used to simplify the execution of such operations. A global identity can be an identity that is known and has access rights to multiple accounts. These accounts can be within an organization and can be associated with the same or different deployments.

[0061] Figure 5Example relationships of a global identity (GI1) 502 according to some example embodiments are shown. A global identity (GI1) 502 can be associated with multiple selected accounts and can access these accounts without further authentication. Once the global identity is authenticated, it can access the different accounts associated with that global identity and perform tasks within the context of those accounts without requiring further authentication for those different accounts. This is because the global identity can be authenticated using a global authentication mechanism, which is a trusted authentication mechanism across the organization. The global authentication mechanism can create one-way trust relationships (also called trust domains or trusted domains) where organizational accounts can trust identity assertions made by the global authentication mechanism. Therefore, each mapped account can be allowed to perform tasks and statements based on trusted identity assertions from the global authentication mechanism without further authentication.

[0062] GI 1 502 can be mapped to different accounts across different deployments, cloud providers, and / or regions. For example, refer back... Figure 4 Account GI 1 502 can be mapped to accounts A and B from PRD1 410, accounts G and H from PUD1 420, accounts M and N from PRD2 430, and accounts S and T from PUD2 440. The mapping accounts for global identities can be set by an administrator, who is a user authorized to manage organizational entities and metadata. Additionally or alternatively, the mapping accounts for global identities can be set based on a set of policy rules. For example, policy rules can be set so that certain types of accounts are automatically mapped to certain global identities. For instance, a policy rule can automatically map all development type accounts in the organization to a selected global identity, regardless of region or deployment. Therefore, a user can log in as the selected global identity, have access to all development accounts in the organization, and perform tasks in the context of any of these development accounts. Furthermore, if a new development account is created within the organization, that new development account can be automatically mapped to the selected global identity.

[0063] After global identity is authenticated, a login session can be established. For example, a login session can be associated with an account and a user ID. The login session can provide access to the mapped account associated with the global identity. Figure 6 A login session 600 with global identity is shown according to some example embodiments. The login session 600 can provide information about the mapped account 602.

[0064] Next, we will describe the different actions that can be performed by the global identity. Figure 7A flowchart of a method 700 for performing operations using a global identity, according to some example embodiments, is shown. At operation 705, login information about a user within the organization can be received. The login information can be associated with a global identity defined by the organization. At operation 710, as described herein, a global authentication mechanism can be used to authenticate the login information about the global identity (or the organization user). For example, two-factor authentication can be used to authenticate the global identity. At operation 715, a login session can be established. The login session can provide access to a mapped account of the global identity without further authentication. That is, due to the trust relationship established by the global authentication mechanism, the user can access and perform tasks in the context of the mapped account without having to provide further authentication for those accounts.

[0065] At operation 720, based on the login session, the first task can be executed within the context of the first mapped account in the global identity's mapped account set. As explained in further detail below, the deployment associated with the first account can employ remote processing to execute the first task.

[0066] At operation 725, also based on the login session, the second task can be performed in the context of a second mapped account within the global identity's mapped account set. As explained in further detail below, the deployment associated with the second account can employ remote processing to perform the second task. In this embodiment, the deployment associated with the first account and the deployment associated with the second account can be the same deployment or different deployments. Therefore, a single user can perform multiple tasks using different accounts from a single login session. Thus, global identity and remote processing provide a simplified interface for users to perform multiple tasks across different accounts.

[0067] In this embodiment, different tasks can be part of a larger operation (such as data replication or data sharing). For example, using global identity, a database can be replicated using a single login session. First, a first mapped account using global identity can create a master database and enable replication of that database. Next, a second mapped account using global identity can create a database, link it to the master database, and make it a copy of the master database.

[0068] The above description focuses primarily on the front end (e.g., what the user sees). Next, the backend operations are described. Based on the login session, an organization can allow users to request the execution of certain statements within the context of a mapped account. In the backend, this is accomplished using the "use account" statement, which instructs the login session that subsequent statements should be executed within the context of the identified account. Remote sessions can be created and then used to execute these subsequent statements. Remote sessions can be persistent. Remote sessions can be maintained by a session pool that stores information about active remote sessions. Remote sessions can be served in parallel within the session pool of the login session, allowing users to switch from one account to another.

[0069] Figure 8 A flowchart of a method 800 for remote processing according to some example embodiments is shown. As described above, method 800 can be executed after authenticating a global identity and establishing a login session. At operation 805, an instruction from an organization user (logged in as a global identity) is received in the login session at the source deployment (e.g., Global Service (GS)). The instruction may include a command or execution statement associated with one of the mapped accounts (e.g., account A). For example, the instruction may be an SQL statement.

[0070] At operation 810, the source deployment can transmit a request to establish a remote session to the deployment associated with account A. The target deployment can be the same as the source deployment or it can be a different deployment. A remote session can refer to a remote session within a context using another account. The request can be sent at the global messaging layer. The request can include one or more parameters, including the account name (for organization users), the organization username, session parameters, and / or an authentication token. The authentication token can be a single sign-on (SSO) token used to verify the identity of organization users.

[0071] At operation 815, the deployment associated with account A can receive requests and establish a remote session. A remote session ID can be assigned to the remote session. The deployment associated with account A can also establish a proxy user associated with the organization user. The proxy user can act similarly to a local user of the deployment. In this embodiment, the proxy user's username can be the organization user's username. However, at least one attribute value can be associated with the proxy user indicating that the proxy user is acting on behalf of the organization user.

[0072] At operation 820, the deployment associated with account A can transmit confirmation of the establishment of a remote session to the source deployment. This confirmation may include the status of the remote session (e.g., established / failed) and the remote session ID. At operation 825, the remote session ID may be stored in a session pool associated with the login session. The session pool may maintain data about the set of remote sessions already established for the login session. For example, the session pool may include information about other remote sessions associated with other mapped accounts. The session pool may be maintained in the backend, and the user may not be aware of it.

[0073] At operation 830, the source deployment can transmit execution requests to the deployment associated with account A. For example, the execution request may include a request to execute a statement and / or query execution task. The request may include one or more parameters, including the remote session ID and the statement / execution task ID.

[0074] At operation 835, in response to receiving an execution request, the deployment associated with account A can execute the request using an established remote session and agent user. If the execution generates results, these result sets can be stored, for example, in cloud storage.

[0075] At operation 840, the deployment associated with the account can send a response to the execution request to the source deployment. The response can include the result of the execution or an indication of the result. For the execution statement example, the response can include a status (e.g., started / failed) and the execution task ID. For querying the execution task, the response can include the task status (e.g., in progress / completed), the task return code, and the task result set ID. The task result set ID can be used, for example, to retrieve the result set from cloud storage.

[0076] Additional remote sessions can be established for other mapped accounts with global identities, and further tasks can be performed on these established remote sessions based on user requests. Information about these remote sessions can be stored and maintained in the session pool of the login session. For example, operations 805-840 can be performed to initially establish a remote session and perform the first task within that session. Furthermore, once a remote session is established, it can be used to perform other tasks by retrieving information from the session pool. For example, operations 825-840 can be performed for additional tasks associated with an established remote session.

[0077] In one embodiment, an organization user can cancel the execution of a task. For example, in response to an instruction from an organization user to cancel the execution of a task, the source deployment can transmit a cancellation request to the deployment associated with the account used for execution. The cancellation request may include one or more parameters, including a remote session ID and an execution task ID. In response to the cancellation request, the deployment can use the identified remote session to cancel the identified execution task. The deployment can transmit a response that may include the status of the request (e.g., canceled / failed). In another embodiment, a response to the cancellation request may not be sent.

[0078] Users can also create / use session-local state information, such as temporary tables, session variables, and session parameters. For example, a user can create one or more temporary tables during a login session. These temporary tables are available for the duration of the login session. Temporary tables can be created in a login session (e.g., for tasks executed locally) and / or in a remote session. Even if the backend switches from one account to another, the organization's users can still see the temporary tables. When switching between different mapped accounts previously used, using session pooling to reuse established remote sessions for other tasks ensures that temporary tables created in remote sessions will continue to exist for the duration of the login session.

[0079] Consistency can be maintained between the login session and one or more remote sessions in the session pool. Session state information can be maintained across different remote sessions. This can include session parameter information as well as state information (such as query results), making them available across different sessions. For example, changes made to the login session can be replicated to all active remote sessions in the session pool. An alter session can be executed in the login session and can also be sent to every active remote session for execution, ensuring that all remote sessions reflect the changes indicated in the alter session command. Furthermore, new remote sessions created after an alter session command can be created and initialized in a manner that reflects the alter session command.

[0080] A login session can maintain an established remote session as an active session in the session pool. In one embodiment, the login session can perform a refresh operation to keep the established remote session active. In another embodiment, a remote session may time out and may be removed from the list of active sessions in the session pool.

[0081] Remote sessions can be terminated. For example, a login session might wish to terminate a remote session. To terminate a remote session, the login session can transmit a termination request to the deployment associated with the account used for execution. The termination request may include one or more parameters, including the remote session ID. In response to the termination request, the deployment can terminate the remote session. The deployment may transmit a response that may include the status of the request (e.g., terminated / failed). In another embodiment, a response to the termination request may not be sent.

[0082] In addition, all active remote sessions can be terminated when the login session terminates. The login session can transmit a termination request to all active remote sessions when it terminates itself.

[0083] Figures 9A-9B A flowchart of a method 900 for operating a login session for an organizational user, according to some example embodiments, is shown. At operation 902, the user issues a request to connect to an account (connection acct 1), and the source deployment can receive the request and authenticate the user's credentials. As described herein, the source deployment can use a global authentication mechanism to authenticate the user as an organizational user (global identity).

[0084] At operation 904, a login session can be created for "acct 1". Since the login session has just been created, there may be no active remote sessions. Therefore, the value of the remote session is set to null, "remote_session = null", and the session pool is empty, "session_pool = <empty pool>". At operation 906, the user can submit statements for execution, such as SQL statements. At operation 908, the statement can be parsed to create a parse tree.

[0085] Next, the source deployment can determine the tasks associated with the statement. In operation 910, the source deployment can check whether the statement includes a request to disconnect or terminate the login session, i.e., "DISCONNECT". At operation 912, if the statement includes a disconnect / termination request, the login session can send a disconnect / termination request to each remote session in the session pool (if any). At operation 914, the login session can be terminated and cleanup operations can be performed. For example, cleanup operations can include deleting any temporary tables created during the login session as described herein.

[0086] If the statement does not include a disconnect / termination request, then at operation 916, the source deployment can check if the statement includes a request for a mapped account using global identity, i.e., "USE ACCOUNT". At operation 918, if the statement includes a "USE ACCOUNT" request, the login session checks if the target account is the login session account, such as acct1. At operation 920, if the target account is the login session account, the remote session register can be set to null (login_session.remote_session = null). Then, method 900 can move to the next user statement (e.g., operation 906). However, if the target account is not the login session account, then at operation 922, the login session can then check if the target account is already in the session pool. At operation 924, if the target account is already in the session pool (and therefore can have a remote session ID), then login_session.remote_session can be set to the target account ("session_pool[target]"). Then, method 900 can move to the next user statement (e.g., operation 906).

[0087] If the target account is not in the session pool, a new remote session can be created for the target account at operation 926, as described herein. At operation 928, the "Session_Pool[Target]" register can then be set to the newly created remote session, and then method 900 can proceed to operation 924.

[0088] If the statement does not include a request to use an account (Operation 916), then at Operation 930, the source deployment can check whether the statement includes a request to change the login session, i.e., "ALTER SESSION". At Operation 932, if the statement includes a request to change the login session, a local execution task can be created to execute the ALTER SESSION request. At Operation 934, a proxy task can be created for each active remote session in the session to modify all active remote sessions based on the ALTER SESSION request.

[0089] If the statement does not include a session modification request, the source deployment can then determine that the request is for task execution. The login session can then check whether the task is for the login session or the remote session by examining the value of "login_session.remote_session" at operation 936. If the register is empty (e.g., the task is for the login session), a local execution task can be created for the statement at operation 938. If the register is not empty, a proxy task can be created for the identified remote session at operation 940. Method 900 can then move to the next user statement (e.g., operation 906).

[0090] Figure 10A schematic representation of a machine 1000 in the form of a computer system according to an example embodiment is shown, within which a set of instructions can be executed to cause the machine 1000 to perform any or more of the methods discussed herein. Specifically, Figure 10 A schematic representation of machine 1000 is shown as an example of a computer system, within which instructions 1016 (e.g., software, programs, applications, applets, or other executable code) for causing machine 1000 to perform any or more of the methods discussed herein can be executed. For example, instructions 1016 may cause machine 1000 to perform any or more of the operations described herein. As another example, instructions 1016 may cause machine 1000 to implement portions of the data flow described herein. In this way, instructions 1016 transform a general, unprogrammed machine into a specific machine 1000 (e.g., remote computing device 106, access management system 110, computing service manager 112, execution platform 114, access management system 118, web agent 120, remote computing device 106), which is specifically configured to perform any of the described and illustrated functions in the manner described herein.

[0091] In alternative embodiments, machine 1000 operates as a standalone device or may be coupled (e.g., networked) to other machines. In a networked deployment, machine 1000 may operate as a server machine or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. Machine 1000 may include, but is not limited to, server computers, client computers, personal computers (PCs), tablet computers, laptop computers, netbooks, smartphones, mobile devices, network routers, network switches, network bridges, or any machine capable of sequentially or otherwise executing instructions 1016, which specify actions to be taken by machine 1000. Furthermore, although only a single machine 1000 is shown, the term "machine" should also be understood to include a collection of machines 1000 that individually or jointly execute instructions 1016 to perform any or more of the methods discussed herein.

[0092] Machine 1000 includes a processor 1010, a memory 1030, and input / output (I / O) components 1050, which are configured to communicate with each other, for example, via a bus 1002. In an example embodiment, processor 1010 (e.g., a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a radio frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, processors 1012 and 1014 capable of executing instructions 1016. The term "processor" is intended to include multi-core processor 1010, which may include two or more independent processors (sometimes referred to as "cores") capable of executing instructions 1016 simultaneously. Although Figure 10 Multiple processors 1010 are shown, but machine 1000 may include a single processor with a single core, a single processor with multiple cores (e.g., a multi-core processor), multiple processors with a single core, multiple processors with multiple cores, or any combination thereof.

[0093] Memory 1030 may include main memory 1032, static memory 1034, and memory cell 1036, all of which can be accessed by processor 1010, for example, via bus 1002. Main memory 1032, static memory 1034, and memory cell 1036 store instructions 1016, which embody any one or more of the methods or functions described herein. During execution by machine 1000, instructions 1016 may also reside wholly or partially in main memory 1032, static memory 1034, memory cell 1036, at least one processor 1010 (e.g., in the processor's cache memory), or any suitable combination thereof.

[0094] I / O component 1050 includes components for receiving input, providing output, generating output, transmitting information, exchanging information, capturing measurement values, etc. The specific I / O component 1050 included in a particular machine 1000 will depend on the type of machine. For example, a portable machine such as a mobile phone may include a touch input device or other such input mechanism, while a headless server machine is unlikely to include such a touch input device. It will be appreciated that I / O component 1050 may include... Figure 10Many other components are not shown. The grouping of I / O components 1050 according to function is merely for the purpose of simplifying the discussion below, and such grouping is by no means limiting. In various example embodiments, I / O components 1050 may include output components 1052 and input components 1054. Output components 1052 may include visual components (e.g., displays such as plasma display panels (PDPs), light-emitting diode (LED) displays, liquid crystal displays (LCDs), projectors, or cathode ray tube (CRT) displays), acoustic components (e.g., speakers), other signal generators, etc. Input components 1054 may include alphanumeric input components (e.g., keyboards, touchscreens configured to receive alphanumeric input, photoelectric keyboards, or other alphanumeric input components), pointing-based input components (e.g., mice, touchpads, trackballs, joysticks, motion sensors, or other pointing instruments), haptic input components (e.g., physical buttons, touchscreens or other haptic input components that provide positioning and / or force for touch or touch gestures), audio input components (e.g., microphones), etc.

[0095] Communication can be implemented using a variety of technologies. I / O component 1050 may include communication component 1064, operable to couple machine 1000 to network 1080 or device 1070 via couplings 1082 and 1072, respectively. For example, communication component 1064 may include a network interface component or another suitable device interfaced with network 1080. In a further example, communication component 1064 may include wired communication components, wireless communication components, cellular communication components, and other communication components providing communication via other modalities. Device 1070 may be another machine or any of a variety of peripheral devices (e.g., peripheral devices coupled via Universal Serial Bus (USB)). For example, as described above, machine 1000 may correspond to any of remote computing device 106, access management system 110, computing service manager 112, execution platform 114, access management system 118, and web agent 120, and device 1070 may include any other systems and devices among these systems and devices.

[0096] Various memories (e.g., 1030, 1032, 1034 and / or the memory of processor 1010 and / or memory of storage unit 1036) may store one or more sets of instructions 1016 and data structures (e.g., software) that embody or are utilized by any or more of the methods or functions described herein. When executed by processor 1010, these instructions 1016 cause various operations to implement the disclosed embodiments.

[0097] As used herein, the terms “machine storage medium,” “device storage medium,” and “computer storage medium” have the same meaning and may be used interchangeably in this disclosure. These terms refer to one or more storage devices and / or media (e.g., centralized or distributed databases and / or associated caches and servers) that store executable instructions and / or data. Accordingly, these terms should be considered to include, but are not limited to, solid-state memory, as well as optical and magnetic media, including memory internal or external to a processor. Specific examples of machine storage media, computer storage media, and / or device storage media include non-volatile memory, including, for example: semiconductor memory devices such as erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), field-programmable gate arrays (FPGAs), and flash memory devices; disks, such as internal hard disks and removable disks; magneto-optical disks; and CD-ROMs and DVD-ROMs. The terms “machine storage medium,” “computer storage medium,” and “device storage medium” specifically exclude carrier waves, modulated data signals, and other such media (at least some of which are included in the term “signal medium” discussed below).

[0098] In various example embodiments, one or more portions of network 1080 may be an ad hoc network, intranet, extranet, virtual private network (VPN), local area network (LAN), wireless LAN (WLAN), wide area network (WAN), wireless WAN (WWAN), metropolitan area network (MAN), the Internet, a portion of the Internet, a portion of the public switched telephone network (PSTN), a common old-style telephone service (POTS) network, a cellular telephone network, a wireless network, etc. A network, another type of network, or a combination of two or more such networks. For example, network 1080 or a portion thereof may include a wireless or cellular network, and coupling 1082 may be a Code Division Multiple Access (CDMA) connection, a Global System for Mobile Communications (GSM) connection, or another type of cellular or wireless coupling. In this example, coupling 1082 may implement any of a variety of data transmission technologies, such as Single Carrier Radio Transmission (1xRTT), Evolved Data Optimization (EVDO), General Packet Radio Service (GPRS), Enhanced Data Rate Evolution of GSM (EDGE), including 3G, fourth-generation wireless (4G) networks, Universal Mobile Telecommunications System (UMTS), High-Speed ​​Packet Access (HSPA), Global Microwave Access Interoperability (WiMAX), the 3rd Generation Partnership Project (3GPP) for Long Term Evolution (LTE) standards, other technologies defined by various standards-setting organizations, other long-range protocols, or other data transmission technologies.

[0099] Instruction 1016 can be transmitted or received on network 1080 using a transmission medium via a network interface device (e.g., a network interface component included in communication component 1064) and utilizing any of a variety of well-known transmission protocols (e.g., Hypertext Transfer Protocol (HTTP)). Similarly, instruction 1016 can be transmitted or received on device 1070 using a transmission medium via coupling 1072 (e.g., peer-to-peer coupling). The terms "transmission medium" and "signal medium" have the same meaning and are used interchangeably in this disclosure. The terms "transmission medium" and "signal medium" should be understood to include any intangible medium capable of storing, encoding, or carrying instructions 1016 for execution by machine 1000, and include digital or analog communication signals or other intangible media facilitating communication of such software. Therefore, the terms "transmission medium" and "signal medium" should be understood to include any form of modulated data signal, carrier wave, etc. The term "modulated data signal" means a signal that has one or more characteristics set or modified in such a way as to encode information in the signal.

[0100] The terms “machine-readable medium,” “computer-readable medium,” and “device-readable medium” have the same meaning and are used interchangeably in this disclosure. These terms are defined to include both machine storage media and transmission media. Therefore, these terms include storage devices / media and carrier / modulated data signals.

[0101] Various operations of the example methods described herein can be performed, at least in part, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Similarly, the methods described herein can be implemented, at least in part, by processors. For example, at least some operations of the methods described herein can be performed by one or more processors. The execution of certain operations can be distributed among one or more processors, which not only reside within a single machine but are deployed across multiple machines. In some example embodiments, one or more processors may reside in a single location (e.g., in a home environment, office environment, or server farm), while in other embodiments, the processors may be distributed across multiple locations.

[0102] Although embodiments of the present disclosure have been described with reference to specific example examples, it will be apparent that various modifications and changes can be made to these embodiments without departing from the broader scope of the subject matter of the invention. Therefore, the specification and drawings are to be considered illustrative rather than restrictive. The accompanying drawings, which form a part of this application, illustrate specific embodiments in which the subject matter can be practiced by way of illustration rather than limitation. The illustrated embodiments are described in sufficient detail to enable those skilled in the art to implement the teachings disclosed herein. Other embodiments and embodiments derived therefrom may be used, such that structural or logical substitutions and changes can be made without departing from the scope of the present disclosure. Therefore, this detailed description should not be construed as limiting, and the scope of the various embodiments is defined only by the appended claims together with their equivalents, which enjoy the full scope of the claims.

[0103] Such embodiments of the subject matter of this invention may be referred to herein, individually and / or collectively, by the term "invention," merely for convenience and not intended to voluntarily limit the scope of this application to any single invention or inventive concept (if more than one invention or inventive concept is actually disclosed). Therefore, while specific embodiments have been illustrated and described herein, it should be understood that the specific embodiments shown may be replaced by any arrangement calculated to achieve the same purpose. This disclosure is intended to cover any and all adaptations or variations of the various embodiments. After reading the above description, combinations of the above embodiments, as well as other embodiments not specifically described herein, will be apparent to those skilled in the art.

[0104] In this document, the terms “a” or “an”, as is common in patent documents, are used to include one or more, and are not related to any other instance or use of “at least one” or “one or more”. In this document, the term “or” is used to mean a non-exclusive “or”, so unless otherwise stated, “A or B” includes “A but not B”, “B but not A”, and “A and B”. In the appended claims, the terms “including” and “in which” are used as their plain English equivalents to the corresponding terms “comprising” and “wherein”. Furthermore, in the appended claims, the terms “including” and “comprising” are open-ended; that is, a system, apparatus, article, or process that includes elements other than those listed after such terms in the claims is still considered to fall within the scope of the claims.

[0105] The following numbered examples are implementation examples:

[0106] Example 1. A method comprising: receiving login information for a global identity by one or more processors; authenticating the global identity based on the login information; establishing a login session that provides access to multiple accounts; performing a first task using a first account from the multiple accounts, based on the login session; and performing a second task using a second account from the multiple accounts, based on the login session.

[0107] Example 2. Following the method of Example 1, where the login session provides access to multiple accounts without further authentication.

[0108] Example 3. According to any one of Examples 1-2, performing the first task using the first account includes: establishing a remote session with the deployment associated with the first account; sending a request to the deployment associated with the first account to perform the first task, wherein the task is performed in the remote session and a result is generated; and receiving the result.

[0109] Example 4. The method according to any of Examples 1-3 further includes: creating a proxy user for the remote session, which is associated with a global identity.

[0110] Example 5. The method according to any one of Examples 1-4 further includes: establishing a second remote session with the deployment associated with the second account; sending a second request to the deployment associated with the second account to perform a second task, wherein the task is performed in the second remote session to generate a second result; and receiving the second result.

[0111] Example 6. The method according to any one of Examples 1-5 further includes: providing a session pool of active remote sessions in parallel, allowing the global identity to switch between active remote sessions.

[0112] Example 7. Based on any of the methods in Examples 1-6, where multiple accounts are selected based on policy rules related to account type.

[0113] Example 8. According to any of Examples 1-7, wherein a first account is associated with a first deployment and a second account is associated with a second deployment.

[0114] Example 9. The method according to any of Examples 1-8 further includes: creating a table associated with the login session; and deleting the table in response to the termination of the login session.

[0115] Example 10. A system comprising: one or more processors of a machine; and a memory storing instructions that, when executed by one or more processors, cause the machine to perform operations implementing any one of Example Methods 1 to 9.

[0116] Example 11. A machine-readable storage device embodying instructions that, when executed by a machine, cause the machine to perform an operation implementing any one of Example Methods 1 to 9.

Claims

1. A method comprising: Based on a single login session: The first task among multiple tasks is performed by establishing a first remote session with a first remote session ID using a deployment associated with a first account from multiple accounts, and using a first mapped account associated with a global identity. The second task among the plurality of tasks is performed using the second account by establishing a second remote session with a second remote session ID associated with a deployment from the second account among the plurality of accounts and using a second mapped account associated with the global identity; as well as Receive results from the first remote session and the second remote session; The first task and the second task are part of the operation, and the second task is associated with the first task.

2. The method according to claim 1, further comprising: The authentication is a one-way trust relationship associated with the global identity. The single login session provides access to the multiple accounts without further authentication.

3. The method according to claim 1, wherein, Using the first account to perform the first task includes: A request is transmitted to the deployment associated with the first account to execute the first task with a first task ID, wherein the first task is executed in the first remote session to generate a first result; and Receive the first result.

4. The method according to claim 3, further comprising: Create a proxy user for the first remote session with at least one attribute value, the attribute value indicating that the proxy user represents the global identity.

5. The method according to claim 3, further comprising: A second request is transmitted to the deployment associated with the second account to execute the second task with the second task ID, wherein the second task is executed in the second remote session to generate a second result; as well as Receive the second result.

6. The method according to claim 1, further comprising: A session pool of active remote sessions is provided in parallel, allowing the global identity to switch between the active remote sessions.

7. The method according to claim 1, wherein, The first account is associated with the first deployment, and the second account is associated with the second deployment.

8. A system comprising: One or more processors in a machine; as well as At least one memory storing instructions that, when executed by the one or more processors, cause the machine to perform operations including: Based on a single login session: The first task among multiple tasks is performed by establishing a first remote session with a first remote session ID using a deployment associated with a first account from multiple accounts, and using a first mapped account associated with a global identity. The second task among the plurality of tasks is performed using the second account by establishing a second remote session with a second remote session ID associated with a deployment from the second account among the plurality of accounts and using a second mapped account associated with the global identity; as well as Receive results from the first remote session and the second remote session; The first task and the second task are part of the operation, and the second task is associated with the first task.

9. The system according to claim 8, wherein the operation further comprises: The authentication is a one-way trust relationship associated with the global identity. The single login session provides access to the multiple accounts without further authentication.

10. The system according to claim 8, wherein, Using the first account to perform the first task includes: A request is transmitted to the deployment associated with the first account to execute the first task with a first task ID, wherein the first task is executed in the first remote session to generate a first result; and Receive the first result.

11. The system of claim 10, further comprising: Create a proxy user for the first remote session with at least one attribute value, the attribute value indicating that the proxy user represents the global identity.

12. The system according to claim 10, wherein the operation further comprises: A second request is transmitted to the deployment associated with the second account to execute the second task with the second task ID, wherein the second task is executed in the second remote session to generate a second result; as well as Receive the second result.

13. The system according to claim 8, wherein the operation further comprises: A session pool of active remote sessions is provided in parallel, allowing the global identity to switch between the active remote sessions.

14. The system according to claim 8, wherein, The first account is associated with the first deployment, and the second account is associated with the second deployment.

15. A non-transitory computer-readable storage medium storing instructions that, when executed by one or more processors, cause the one or more processors to: Based on a single login session: The first task among multiple tasks is performed by establishing a first remote session with a first remote session ID using a deployment associated with a first account from multiple accounts, and using a first mapped account associated with a global identity. The second task among the plurality of tasks is performed using the second account by establishing a second remote session with a second remote session ID associated with a deployment from the second account among the plurality of accounts and using a second mapped account associated with the global identity; as well as Receive results from the first remote session and the second remote session; The first task and the second task are part of the operation, and the second task is associated with the first task.

16. The non-transitory computer-readable storage medium of claim 15, further comprising: The authentication is a one-way trust relationship associated with the global identity. The single login session provides access to the multiple accounts without further authentication.

17. The non-transitory computer-readable storage medium according to claim 15, wherein, Using the first account to perform the first task includes: A request is transmitted to the deployment associated with the first account to execute the first task with a first task ID, wherein the first task is executed in the first remote session to generate a first result; and Receive the first result.

18. The non-transitory computer-readable storage medium of claim 17, further comprising: Create a proxy user for the first remote session with at least one attribute value, the attribute value indicating that the proxy user represents the global identity.

19. The non-transitory computer-readable storage medium of claim 17, further comprising: A second request is transmitted to the deployment associated with the second account to execute the second task with the second task ID, wherein the second task is executed in the second remote session to generate a second result; as well as Receive the second result.

20. The non-transitory computer-readable storage medium of claim 15, further comprising: A session pool of active remote sessions is provided in parallel, allowing the global identity to switch between the active remote sessions.

21. The non-transitory computer-readable storage medium according to claim 15, wherein, The first account is associated with the first deployment, and the second account is associated with the second deployment.

Images