Compound authorizations for entities within a domain

Abstract

A system and method for compound authorization for entities in a domain are described. One aspect relates to a method. The method can include receiving a request for a user to take an action in a first system, and determining a first authorization status of the action by the user with the first system. The method can include determining a second authorization status of the action by the user with a second system, determining a combination of the first authorization status and the second authorization status, and comparing the combination of the first authorization status and the second authorization status to an authorization criterion.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 63 / 250,805, entitled "Combined Authorization for Entities Within a Domain," filed September 30, 2021, the entirety of which is incorporated herein by reference. [Background technology]

[0002] background The adoption of cloud services has been increasing rapidly in recent years. Currently, various types of cloud services are offered by different cloud service providers (CSPs). The term cloud services is generally used to refer to services or functionality made available on demand by the CSP to subscribing customers, typically utilizing a subscription model, using systems and infrastructure (commonly referred to as cloud infrastructure) provided by the CSP. Typically, the servers and systems included in the cloud infrastructure provided by the CSP used to provide cloud services to subscribing customers are separate from the customers' own on-premise servers and systems. The infrastructure provided by the CSP may include computing, storage, and networking resources. Therefore, customers can utilize the cloud services provided by the CSP without needing to purchase their own hardware and software resources for the services. Cloud services are designed to provide subscribing customers with easy, scalable, on-demand access to applications and computing resources without the customer having to invest in procuring infrastructure to provide the services or functionality. Various types or models of cloud services may be offered, such as Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS), Infrastructure-as-a-Service (IaaS), and others. A customer may subscribe to one or more cloud services offered by a CSP. A customer can be any entity, such as an individual, an organization, a business, and the like.

[0003] Different services provided by a CSP may have different authorization processes and different permissions. In some cases, these different authorization processes and permissions may result in an unsatisfactory customer experience. Therefore, further improvements are desirable. Summary of the Invention [Means for solving the problem]

[0004] overview Aspects of the disclosure relate to systems and methods for combined authorization. One aspect relates to a method that can include receiving a request for a user to take an action in a first system, determining a first authorization status of the action by the user with the first system, determining a second authorization status of the action by the user with a second system, determining a combination of the first authorization status and the second authorization status, and comparing the combination of the first authorization status and the second authorization status to an authorization criterion.

[0005] In some embodiments, the method further includes authorizing an action by the user when a combination of the first authorization status and the second authorization status meets an authorization criterion. In some embodiments, the combination of the first authorization status and the second authorization status meets an authorization criterion when the combination of the first authorization status and the second authorization status includes authorization from each of the first system and the second system for the user to take the action. In some embodiments, the method further includes authorizing an action by the user when the combination of the first authorization status and the second authorization status includes authorization from at least one of the first system and the second system for the user to take the action.

[0006] In some embodiments, the method includes denying an action by the user when a combination of the first authorization status and the second authorization status does not meet an authorization criterion. In some embodiments, the combination of the first authorization status and the second authorization status does not meet an authorization criterion when the combination of the first authorization status and the second authorization status includes a denial of authorization from at least one of the first system and the second system.

[0007] In some embodiments, the first system is a role-based access control (RBAC) system and the second system is an attribute-based access control (ABAC) system. In some embodiments, receiving a request for a user to take an action in the first system includes receiving a signed request from a first application associated with the first system. In some embodiments, receiving a request for a user to take an action in the first system includes receiving information identifying the first application, the user, the action, and an endpoint that will be affected by the action.

[0008] In some embodiments, the first system verifies the validity of the signed request and derives the relationship principal with the second system based on at least one of the received signed request and the received information. In some embodiments, verifying the validity of the signed request includes the second system requesting and receiving a public key from the data plane and verifying the validity of the signed request with the public key. In some embodiments, determining a first authorization status of the action by the user with the first system includes determining a domain-specific authorization of the relationship principal. In some embodiments, the domain-specific authorization of the relationship principal is determined according to an authorization policy of the first system.

[0009] In some embodiments, determining a first authorization status of an action by the user using the first system includes evaluating a request to take an action according to an authorization policy of the first system. In some embodiments, determining a second authorization status of an action by the user using the second system includes mapping an authorization policy of the first system to a corresponding authorization policy of the second system based at least in part on the received information. In some embodiments, evaluating a request to take an action according to an authorization policy of the first system includes identifying a role of the user and a domain of the user, retrieving permissions associated with the role of the user and the domain of the user, and determining that the received information identifies an action permitted by the retrieved permissions. In some embodiments, determining a second authorization status of an action by the user using the second system further includes determining a principal of the user, retrieving an access policy associated with the received request, and determining that the received request identifies an action permitted by the retrieved access policy.

[0010] One aspect relates to a system. The system includes a first access control system including at least one first processor and a memory including a plurality of instructions executable by the at least one first processor. The system includes a second access control system capable of determining a second authorization status for a requested user action. The first access control system can receive a request for a user to take an action in the first access control system, determine a first authorization status of the action by the user, receive authorization information for the action from the second system, determine a combination of the first authorization status and the second authorization status, and compare the combination of the first authorization status and the second authorization status to an authorization criterion.

[0011] In some embodiments, receiving a request for the user to take an action in the first system includes receiving a signed request from a first application associated with the first system. In some embodiments, receiving a request for the user to take an action in the first system includes receiving information identifying the first application, the user, the action, and an endpoint that will be affected by the action. In some embodiments, the first system validates the signed request and derives a relationship principal with the second system based on at least one of the received signed request and the received information.

[0012] One aspect relates to a non-transitory computer-readable storage medium storing instructions executable by one or more processors, which when executed by the one or more processors cause the one or more processors to receive a request for a user to take an action in a first system, determine a first authorization status of the action by the user using the first system, determine a second authorization status of the action by the user using a second system, determine a combination of the first authorization status and the second authorization status, and compare the combination of the first authorization status and the second authorization status to an authorization criterion.

[0013] In some embodiments, receiving a request for the user to take an action in the first system includes receiving a signed request from a first application associated with the first system. In some embodiments, receiving a request for the user to take an action in the first system includes receiving information identifying the first application, the user, the action, and an endpoint that will be affected by the action. In some embodiments, the first system validates the signed request and derives a relationship principal with the second system based on at least one of the received signed request and the received information. [Brief description of the drawings]

[0014] [Figure 1] FIG. 1 is a schematic diagram of an embodiment of a system for compound authorization for entities within a domain. [Diagram 2] 1 is a flow diagram illustrating an embodiment of a process for compound authorization for entities within a domain. [Diagram 3] 11 is a flow diagram illustrating another embodiment of a process for compound authorization for entities within a domain. [Figure 4] FIG. 1 is a block diagram illustrating one pattern for implementing a cloud infrastructure-as-a-service system in accordance with at least one embodiment. [Diagram 5] FIG. 2 is a block diagram illustrating another pattern for implementing a cloud infrastructure-as-a-service system in accordance with at least one embodiment. [Figure 6] FIG. 2 is a block diagram illustrating another pattern for implementing a cloud infrastructure-as-a-service system in accordance with at least one embodiment. [Figure 7] FIG. 2 is a block diagram illustrating another pattern for implementing a cloud infrastructure-as-a-service system in accordance with at least one embodiment. [Figure 8] FIG. 1 is a block diagram illustrating an exemplary computer system according to at least one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] Detailed Description In the following description, for purposes of explanation, specific details are set forth in order to provide a thorough understanding of some embodiments. It will be apparent, however, that various embodiments may be practiced without these specific details. The figures and descriptions are not intended to be limiting. The word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or design described herein as "exemplary" should not necessarily be construed as preferred or advantageous over other embodiments or designs.

[0016] The present disclosure relates generally to cloud computing, and more particularly to authorization and permissions, and more particularly to compound authorization for entities within a domain.

[0017] A CSP provides infrastructure and resources used to provide cloud services to subscribing customers. The resources provided by a CSP can include hardware and software resources. These resources can include, for example, computational resources (e.g., computer systems, virtual machines, containers, applications, processors), memory resources (e.g., databases, data stores), networking resources (e.g., routers, load balancers), identity and access management resources, and other resources. The resources provided by a CSP to provide a set of cloud services to subscribing customers are typically organized into data centers, each data center comprising one or more computing systems or host machines. A data center can be configured to provide a particular set of cloud services. The CSP is tasked with configuring the data center with the computation, memory, and networking and resources used to provide that particular set of cloud services. A CSP can provide one or more data centers depending on the number of subscribing customers and based on the location of the customers.

[0018] Data centers provided by a CSP may be hosted in different geographic regions. A region may refer to a specific geographic area and may be identified by a region name. Regions are generally independent of one another and may be separated by vast distances, such as across countries or even continents. Examples of regions for a CSP may include US West, US East, Australia East, Australia Southeast, and the like. In some implementations, a collection of regions is referred to as a realm. A realm may include one or more regions. Thus, a CSP may provide a realm that includes one or more regions, each of which includes one or more data centers.

[0019] Therefore, each data center is associated with a region. A CSP may deploy one or more data centers within a region, where the data centers are located within some geographic area (e.g., city) within the region. For example, a particular CSP may have multiple regions, such as a US West region, a US East region, an Australia East region, an Australia Southeast region, and the like. A CSP may deploy one or more data centers within each region, such as within a city within the region. For example, one or more data centers for the US West region may be located in San Jose, California, a data center for the US East region may be located in Ashburn, Virginia, one or more data centers for the Australia East region may be located in Sydney, Australia, one or more data centers for the Australia Southeast region may be located in Melbourne, Australia, etc. Data centers in two different regions may offer the same or different sets of cloud services and resources to subscribing customers.

[0020] In some implementations, to provide high availability to customers and for disaster recovery purposes, data centers within a region may be further organized into one or more availability domains, where an availability domain contains one or more data centers. The availability domains within a region are isolated from each other, fault tolerant, and designed in such a way that the likelihood of data centers in multiple availability domains within a region failing simultaneously is extremely low. For example, the availability domains within a region may be structured such that a failure in one availability domain within a region is unlikely to affect the availability of data centers in other availability domains in the same region.

[0021] A cloud service provider (CSP) may offer multiple cloud services to subscribing customers. These services may be offered under different models, including Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS) models, and others.

[0022] Within a cloud environment, an identity management system is generally provided by a CSP to control user access to resources provided or used by the cloud service. Typical services or functions provided by an identity management system include, but are not limited to, single sign-on capabilities for users, authentication and authorization services, and other identity-based services.

[0023] The resources protected by the identity management system can be of different types, such as compute instances, block storage volumes, virtual cloud networks (VCNs), subnets, route tables, various callable APIs, internal or legacy applications, and the like. These resources include resources stored in the cloud and / or customer on-premise resources. Each resource is typically identified by a unique identifier (e.g., ID) that is assigned to the resource when the resource is created.

[0024] A CSP may provide two or more separate and independent identity management systems for their cloud offerings. This may be done, for example, where a first identity management system or platform (e.g., Infrastructure Identity and Access Management (IAM)) may be provided to control access to cloud resources for IaaS applications and services offered by the CSP. Separately, a second identity management system or platform (e.g., Identity Cloud Service (IDCS)) may be provided for security and identity management for SaaS and PaaS services offered by the CSP.

[0025] As a result of providing such two separate platforms, if a CSP's customer subscribes to both SaaS or PaaS and IaaS services offered by the CSP, the customer now has two separate accounts -- one account with IAM for the IaaS subscription, and a separate account with IDCS for the PaaS / SaaS subscription. Each account has its own credentials, such as user login, password, etc. Thus, the same customer has two separate sets of credentials. This creates an unsatisfactory customer experience and potentially increases security risks, because the customer must maintain two different sets of credentials, and the credentials are maintained in two systems. In addition, having two separate identity management systems also creates obstacles for interactions between SaaS / PaaS and IaaS services.

[0026] For purposes of this application, and as an example, the two platforms are referred to as IAM and IDCS. These names and terms are not intended to be limiting in any manner. The disclosure described herein applies to any two (or more) identity management systems to be integrated. The identity management systems or platforms may be provided by one or more CSPs.

[0027] In some embodiments, a unified identity management platform is provided that integrates multiple identity management platforms (e.g., IAM and IDCS platforms) offered by a CSP in a manner that is transparent to users or customers of the cloud service, while retaining and providing various features and functionality provided by the two separate (e.g., IAM and IDCS) platforms. The integration therefore provides a more seamless and improved user experience.

[0028] However, this integration is technically very challenging since the two platforms may use different procedures and protocols for implementing identity-related functions. IAM can be, for example, an Attribute-Based Access Control (ABAC) system, also known as a Policy-Based Access Control system, which defines an access control paradigm in which access rights are granted to users through the use of policies expressing complex Boolean rule sets that can evaluate many different attributes. The purpose of ABAC is to protect objects such as data, network devices, and IT resources from unauthorized users and actions - those that do not have the "approved" characteristics as defined by the organization's security policy. On the other hand, IDCS can be a Role-Based Access Control (RBAC) system, which is a policy-neutral access control mechanism defined around roles and privileges. Components of RBAC such as role permissions, user-role and role-role relationships simplify the fulfillment of user assignments. As yet another example, the authentication and authorization frameworks or workflows used by the two platforms (e.g., types of tokens used, different authentication frameworks such as OAUTH, etc.) may be different. Thus, providing an integrated solution is technically very challenging.

[0029] To solve this problem, a compound authorization for entities in a domain was developed. This compound authorization for entities in a domain can compound the IAM authorization and the IDCS authorization. The compound authorization for entities in a domain avoids the problem that occurs when there is a mismatch in the authorizations for users in different systems. This can include, for example, when a user in a first system is assigned to a role with certain privileges in the first system, whereas the user is also a principal in a second system and is given certain privileges in the second system. The compound authorization for entities in a domain receives a request from a user to perform some action, then determines by the first system whether the user is authorized to perform the action, and then determines in the second system whether the user is authorized to perform the action. Upon receiving the authorization information for the first system and the second system, a combination of the authorization information can be determined and then compared to one or several authorization criteria. Based on this comparison with one or several authorization criteria, the user is allowed to take the requested action or is prevented from taking the requested action.

[0030] The composite authorization for an entity within a domain utilizes authorizations from both the first and second systems and determines the union of those authorizations, thereby remedying problems associated with multiple separate authorizations and discrepancies in those authorizations.

[0031] The term "data center," as used in this disclosure, refers to one or more computer systems used in cooperation to implement a data center. For example, a home region data center refers to one or more computer systems used to implement a data center in a home region. For example, a global region data center refers to one or more computer systems used to implement a global region data center. The computer systems that make up a data center can include one or more processors and one or more memories capable of storing instructions executed by the one or more processors. An example of such a computer system is shown in FIG. 8 and described below.

[0032] Referring now to FIG. 1, a schematic diagram of one embodiment of a system 100 for compound authorization for entities in a domain, also referred to herein as compound authorization system 100, is shown. The system 100 includes a user device 102, one or several IAM servers 104, and one or several IDCS servers 106. In some embodiments, the user device 102 may include a computing device such as a laptop, a desktop, a mobile device, and the like. The one or several IAM servers 104 and / or the one or several IDCS servers 106 may each include one or several computing resources including, for example, one or several servers or server racks. The one or several IAM servers 104 and / or the one or several ICDS servers 106 may be located within one or several of the global region 102, the home region 112, and / or the non-home region 122.

[0033] A user can use a user device 102 to request authorization to take an action via one or more IAM applications running on one or more IAM servers 104 or via one or more IDCS applications running on one or more IDCS servers 106. In some embodiments, the user device 102 can be directly connected to one or both of the at least one IAM server 104 and the at least one IDCS server 106, for example, via a wired or wireless connection, for example, via a communications network 130. In some embodiments, the user device 102 can be directly connected to one or both of the at least one IAM server 104 and the at least one IDCS server 106, for example, via one or more communications networks and / or one or more computer networks. In some embodiments, the user device 102 can be directly connected to one or both of the at least one IAM server 104 and the at least one IDCS server 106, for example, via the Internet.

[0034] In some embodiments, some or all of the IAM server 104 and the IDCS server 106 may be located in the same location or in different locations. In some embodiments, some or all of the IAM server 104 and the IDCS server 106 may be located within different computing networks, different data centers, different regions, or the like. In some embodiments, and applying the decoy compound authorization system 100 disclosed herein, when a user receives authorization to take an action from the IDCS server 106, it may receive authorization from the IAM server 104.

[0035] 2, a flow chart illustrating one embodiment of a process 200 for compound authorization for entities in a domain is shown. The process 200 may be performed by all or part of the compound authorization system 100, and in particular, by one or more of the IDCS servers 106 and / or by one or more of the IAM servers 104. In some embodiments, one or more of the IDCS servers 106 may be a first system and one or more of the IAM servers 104 may be a second system, and in some embodiments, one or more of the IAM servers 104 may be a first system and one or more of the IDCS servers 106 may be a second system. Thus, in some embodiments, the first system may be an RBAC system and the second system may be an ABAC system, whereas in other embodiments, the first system may be an ABAC system and the second system may be an RBAC system.

[0036] In some embodiments, process 200 begins at block 202 where the first system receives a request from a user. The request may be made by requesting that the user take a particular action within a domain and on a particular endpoint. In some embodiments, the user may access an application, and specifically an Application Programming Interface (API) within the first system. In some embodiments, this may include the user accessing an application, and specifically an API within the domain of the IDCS system 106. In such an embodiment, the IDCS system 106 may receive a request from the user device 102, and specifically from the application, and more specifically from the API. In some embodiments, the request may include a signed request and / or may include one or several tokens for use in identifying the user and / or authenticating the request.

[0037] At block 204, identification information is received from the user at the first system. This identification information may be part of the request received at block 202 or may be separate from the request received at block 202. In some embodiments, this information may be generated by the application, and specifically through an API, from which the request is generated. This information may identify, for example, the user requesting to take an action, the user's current domain, the action requested by the user, and the endpoints affected by the action. In some embodiments, the information may include a signed request and / or one or more tokens for use in identifying the user and / or authenticating the request.

[0038] At block 206, the first system evaluates the request according to the authorization policy of the first system. In some embodiments, this may include receiving a signed request and verifying the validity of the signed request and / or determining a related principal associated with the request. In some embodiments, the related principal may be the principal of the user making the request. In some embodiments, this principal may be a principal in the first system that may be associated with one or several roles and / or a principal in the second system that is associated with one or several attributes. In some embodiments, the user's principal may actually be a first principal in the first system and a second principal in the second system.

[0039] In some embodiments, the first system can verify the validity of the signed request based on information contained within the received request and / or based on information available in other manners. In some embodiments, for example, the request can be signed using a private key. In such embodiments, a public key can be utilized to verify the validity of the signed request. In some embodiments, the first system can, for example, request a public key from the data plane and, upon receiving the public key, can verify the validity of the signed request. In some embodiments, the first system can send the signed request to a second system, which can request and receive a public key from the data plane. Upon receiving the public key from the data plane, the second system can verify the validity of the signed request using the received public key.

[0040] In some embodiments, the first system may determine a principal for the user, and / or in some embodiments, the second system may determine a principal for the user. For example, the principal includes a first principal of the first system and a second principal of the second system. In some embodiments, the first system may determine a first principal and the second system may determine a second principal. In some embodiments, the principal may include one or both of the first principal and the second principal, and may be determined based on the request and / or on the received information.

[0041] In some embodiments, evaluating the request by the first system according to an authorization policy of the first system can include determining a first authorization status of the received request. In some embodiments, determining the first authorization status can include determining a domain-specific authorization for the received request. In some embodiments, the domain-specific authorization can be based on the determined principal.

[0042] A domain-specific authorization of the principal may be determined by the first system. In some embodiments, this domain-specific authorization of the principal may be determined by the first system according to an authorization policy of the first system, and may include, for example, evaluating a request to take an action according to an authorization policy of the first system. In some embodiments, this may include identifying a role of the user and a domain of the user. The first system may retrieve permissions associated with the user's role and / or with the user's domain. The first system may determine, based on the retrieved permissions, and based on the request, and attributes of the request, whether the requested action is an allowed action. In some embodiments, this may include determining, based on the retrieved permissions, and based on the user, the user role, the user domain, the affected endpoint, and the requested action, whether the requested action is allowed by the retrieved permissions. If the request is determined to be allowed by one or more permissions, authorization policies, and / or access policies, then the first system indicates that the action is allowed. If the request is determined to be prohibited by one or more permissions, authorization policies, and / or access policies, then the first system indicates that the action is prohibited. In some embodiments, if the request is determined to be neither allowed nor prohibited by one or more permissions, authorization policies, and / or access policies, then no authorization indication is generated by the first system.

[0043] At block 208, the first system requests authorization for the received request from the second system. In some embodiments, this may include the IDCS requesting authorization for the received request from the IAM. In some embodiments, this may include determining an authorization and / or authorization policy in the second system that corresponds to an authorization and / or authorization policy in the first system associated with the received request, or in other words, mapping one or more authorization and / or authorization policies in the first system to one or more corresponding authorization and / or authorization policies in the second system. In some embodiments, the first system may include a database that links one or more authorization and / or authorization policies of the first system to one or more authorization and / or authorization policies of the second system. In some embodiments, the first system requesting authorization for the received request from the second system may include the first system querying a database for an identification of one or more authorization and / or authorization policies of the second system based on the received request and / or the received information.

[0044] In some embodiments, upon identifying one or more permissions and / or authorization policies in the second system that are associated with the received request, the first system can query the second system for an authorization decision for the received request. In some embodiments, the first system can send an authorization request to the second system, which can identify one or more associated permissions and / or authorization policies and can include the request received in block 202 and / or information related to the request received in block 202. This information can include, for example, the user, the user role, the user domain, the affected endpoints, and / or the requested action.

[0045] In block 210, the second system evaluates the request of block 202 according to the authorization policies of the second system. In some embodiments, this may include determining a second authorization status for the requested action of block 202. This may include, for example, determining and / or identifying a principal of the user for the request, retrieving one or more permissions, authorization policies, and / or access policies associated with the received request and / or the identified principal of the user, and determining whether the received request of block 202 is permitted by the retrieved one or more permissions, authorization policies, and / or access policies and / or whether the action identified by the request of block 202 is permitted by the one or more permissions, authorization policies, and / or access policies. In some embodiments, the one or more permissions, authorization policies, and / or access policies may be identified based on information received from the first system in block 208. If the request is determined to be allowed by one or more permissions, authorization policies, and / or access policies, then the second system indicates that the action is allowed. If the request is determined to be prohibited by one or more permissions, authorization policies, and / or access policies, then the second system indicates that the action is prohibited. In some embodiments, if the request is determined to be neither allowed nor prohibited by one or more permissions, authorization policies, and / or access policies, then no indication of authorization is generated.

[0046] At block 212, authorization information from the second system is received. In some embodiments, this may include receiving authorization information from the second system at the first system. At block 214, a combination of the first system authorization and the second system authorization of the request received at block 202 is determined, in other words, a combination of the first authorization status and the second authorization status is determined.

[0047] In block 216, the combination of the first system authorization and the second system authorization is compared to one or several authorization criteria. In some embodiments, the authorization criteria can delineate between a combination sufficient to authorize the request of block 202 and one that is insufficient to authorize the request of block 202. In some embodiments, the authorization criteria can identify a combination as sufficient to authorize the request of block 202 when both the first authorization status and the second authorization status authorize the request, or when one of the first authorization status and the second authorization status authorizes the request and the other prohibits the request. In some embodiments, the authorization criteria can identify a combination as insufficient to authorize the request of block 202 when at least one of the first authorization status and the second authorization status prohibits the authorization of the request.

[0048] In block 218, the request of block 202 is granted or denied based on the result of the comparison of the combination of the first and second system authorizations to the authorization criteria. Thus, in some embodiments, the request, and specifically the action requested by the user, may be authorized when the combination of the first and second authorization statuses meets the authorization criteria. In some embodiments, the combination of the first and second authorization statuses meets the authorization criteria when the combination of the first and second authorization statuses includes authorization from each of the first and second systems for the user to take the action. In some embodiments, the request, and specifically the action requested by the user may be authorized and / or granted when the combination of the first and second authorization statuses includes authorization from at least one of the first and second systems for the user to take the action. In some embodiments, the request, and specifically the action requested by the user may be denied and / or prohibited when the combination of the first and second authorization statuses does not meet the authorization criteria. In some embodiments, a combination of the first authorization status and the second authorization status does not meet the authorization criteria when the combination of the first authorization status and the second authorization status includes at least one denial of authorization from at least one of the first system and the second system.

[0049] 3, a flow chart is shown illustrating another embodiment of a process 300 for compound authorization for entities in a domain. The process 300 may be performed by all or part of the compound authorization system 100, and in particular, by one or more of the IDCS servers 106 and / or by one or more of the IAM servers 104.

[0050] Process 300 begins at step 302 where a user makes a request to take an action in IDCS via an IDCS application, and specifically, via an IDCS API. The user may be a principal, depending on the embodiment. The request may be, for example, a signed request. The request may include information such as, for example: an identification of a user principal, including an API key, a native token or identity, a federated token or identity, or the like; an identification of an instance, service, and / or resource principal; an identification of an instance principal and / or an Oauth OBO flow.

[0051] In step 304, the IDCS determines the identity of the principal and / or user and determines the identity of the requested IDCS API. In some embodiments, this may include verifying the validity of the signed request and deriving the associated principal. In some embodiments, the IDCS may use the IAM to verify the validity of the signed request and derive the associated principal. In such an embodiment, and as part of verifying the validity of the signed request, the IAM may request and / or receive a public key corresponding to the signed request from the data plane, as indicated in step 306. In step 308, the public key is received and used to verify the validity of the signed request. In some embodiments, the public key may be used by the IAM to verify the validity of the signed request.

[0052] In step 310, and if the principal is a user principal, then the IDCS performs domain-specific authorization based on the IDCS authorization policy. In step 312, the IDCS requests that the IAM evaluate the request. In some embodiments, the IDCS requests that the IAM evaluate the request according to the IAM authorization policy. The IAM evaluates the request according to the IAM's authorization policy. In step 314, the IDCS receives authorization from the IAM. In some embodiments, this may include receiving a result of evaluating the request of step 302 according to the IAM's authorization policy. In step 316, the authorization is evaluated. This may include determining a combination of the authorization received from the IAM and the result of the evaluation in step 310. In step 318, a response is provided to the user. The response indicates either that the request of step 302 is authorized or that the request is not authorized.

[0053] Exemplary embodiments As mentioned above, Infrastructure as a Service (IaaS) is one particular type of cloud computing. IaaS may be configured to provide virtualized computing resources over a public network (e.g., the Internet). In an IaaS model, a cloud computing provider may host infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., hypervisor layer), or the like). In some cases, an IaaS provider may also provide various services (e.g., billing, monitoring, logging, load balancing, clustering, etc.) that accompany those infrastructure components. Hence, these services may be policy-driven, so that users of IaaS may be able to implement policies to drive load balancing to maintain application availability and performance.

[0054] In some cases, IaaS customers may access resources and services over a wide area network (WAN), such as the Internet, and can use the cloud provider's services to install the remaining elements of the application stack. For example, a user can log into an IaaS platform, create virtual machines (VMs), install an operating system (OS) on each VM, deploy middleware such as databases, create storage buckets for workloads and backups, and install enterprise software within the VMs. The customer can then use the provider's services to perform a variety of functions, including balancing network traffic, troubleshooting application problems, monitoring performance, managing disaster recovery, etc.

[0055] In most cases, the cloud computing model will require the involvement of a cloud provider, which can be, but need not be, a third-party service that specializes in delivering (e.g., providing, renting, selling) IaaS. An entity could also choose to deploy a private cloud and become its own provider of infrastructure services.

[0056] In some examples, IaaS deployment is the process of putting a new application, or a new version of an application, onto a prepared application server or the like. It may also include the process of preparing the server (e.g., installing libraries, daemons, etc.). This is often managed below the hypervisor layer (e.g., servers, storage, network hardware, and virtualization) by the cloud provider. Therefore, the customer may be responsible for handling the (OS), middleware, and / or application deployment (e.g., on top of self-service virtual machines (which may be spun up on demand, etc.).

[0057] In some examples, IaaS provisioning may refer to acquiring computers or virtual hosts for use, as well as installing required libraries or services on them. In most cases, deployment does not include provisioning, which may need to be performed first.

[0058] In some cases, there are two distinct challenges for IaaS provisioning. First, there is the initial challenge of provisioning an initial set of infrastructure before any of it is running. Second, there is the challenge of evolving the existing infrastructure (e.g., adding new services, modifying services, removing services, etc.) after everything is provisioned. In some cases, these two challenges can be addressed by allowing the configuration of the infrastructure to be specified declaratively. In other words, the infrastructure (e.g., what components are needed and how they interact) can be specified by one or more configuration files. Hence, the overall topology of the infrastructure (e.g., which resources depend on which and how they each work together) can be described declaratively. In some cases, once the topology is specified, workflows can be generated that create and / or manage the different components described in the configuration files.

[0059] In some examples, the infrastructure may have many interconnected elements. For example, there may be one or more virtual private clouds (VPCs) (e.g., a potentially on-demand pool of configurable and / or shared computing resources), also known as a core network. In some examples, there may also be one or more inbound / outbound traffic group rules and one or more virtual machines (VMs) that are provisioned to define how the network's inbound and / or outbound traffic is to be set up. Other infrastructure elements, such as load balancers, databases, or the like, may also be provisioned. The infrastructure may evolve over time as more infrastructure elements are desired and / or added.

[0060] In some cases, continuous deployment techniques may be employed to enable deployment of infrastructure code across various virtual computing environments. Additionally, the above-mentioned techniques may enable infrastructure management within these environments. In some examples, a service team may write code that is desired to be deployed to one or more, but often many, different production environments (e.g., across a variety of different geographic locations, sometimes spanning the globe). However, in some examples, the infrastructure into which the code will be deployed must first be set up. In some cases, provisioning may be done manually, provisioning tools may be utilized to provision the resources, and / or deployment tools may be utilized to deploy the code once the infrastructure is provisioned.

[0061] 4 is a block diagram 400 illustrating an example pattern of an IaaS architecture according to at least one embodiment. A service operator 402 may be communicatively coupled to a secure host tenancy 404, which may include a virtual cloud network (VCN) 406 and a secure host subnet 408. In some examples, the service operator 402 may employ one or more client computing devices, which may be portable handheld devices (e.g., iPhone, cellular telephone, iPad, computing tablet, personal digital assistant (PDA)) or wearable devices (e.g., Google Glass head-mounted display) running software such as Microsoft Windows Mobile and / or various mobile operating systems such as iOS, Windows Phone, Android, BlackBerry 8, Palm OS, and the like, and enabled for Internet, email, short message service (SMS), Blackberry, or other communications protocols. Alternatively, the client computing devices can be general purpose personal computers including, by way of example, personal and / or laptop computers running various versions of Microsoft Windows, Apple Macintosh, and / or Linux operating systems. The client computing devices can be workstation computers running any of a variety of commercially available UNIX or UNIX-like operating systems including, but not limited to, various GNU / Linux operating systems such as the Google Chrome OS.Alternatively, or in addition, the client computing device may be any other electronic device, such as a thin-client computer, an Internet-enabled gaming system (e.g., a Microsoft Xbox gaming console with or without a Kinect® gesture input device), and / or a personal messaging device, that has the capability to communicate over a network that can access the VCN 406 and / or the Internet.

[0062] VCN 406 may include a local peering gateway (LPG) 410 that may be communicatively coupled to a secure shell (SSH) VCN 412 via an LPG 410 that is contained within the SSH VCN 412. The SSH VCN 412 may include an SSH subnet 414, which may be communicatively coupled to a control plane VCN 416 via an LPG 410 that is contained within the control plane VCN 416. The SSH VCN 412 may also be communicatively coupled to a data plane VCN 418 via the LPG 410. The control plane VCN 416 and the data plane VCN 418 may be contained within a service tenancy 419, which may be owned and / or operated by the IaaS provider.

[0063] The control plane VCN 416 can include a control plane demilitarized zone (DMZ) tier 420 that serves as a perimeter network (e.g., a portion of an enterprise network between the enterprise intranet and an external network). DMZ-based servers have limited responsibility and can help contain breaches. Additionally, the DMZ tier 420 can include one or more load balancer (LB) subnets 422, a control plane app tier 424 that can include app subnets 426, a control plane data tier 428 that can include database (DB) subnets 430 (e.g., a front-end DB subnet and / or a back-end DB subnet). The LB subnet 422 contained within the control plane DMZ layer 420 may be communicatively coupled to an app subnet 426 contained within the control plane app layer 424 and an Internet gateway 434 that may be contained within the control plane VCN 416, which may be communicatively coupled to a DB subnet 430 contained within the control plane data layer 428, as well as a service gateway 436 and a network address translation (NAT) gateway 438. The control plane VCN 416 may include the service gateway 436 and the NAT gateway 438.

[0064] The control plane VCN 416 can include a data plane mirror app layer 440 that can include an app subnet 426. The app subnet 426 contained within the data plane mirror app layer 440 can include a virtual network interface controller (VNIC) 442 on which a compute instance 444 can run. The compute instance 444 can communicatively couple the app subnet 426 of the data plane mirror app layer 440 to the app subnet 426, which can be contained within the data plane app layer 446.

[0065] The data plane VCN 418 can include a data plane app layer 446, a data plane DMZ layer 448, and a data plane data layer 450. The data plane DMZ layer 448 can include a LB subnet 422, which can be communicatively coupled to an app subnet 426 of the data plane app layer 446 and an Internet gateway 434 of the data plane VCN 418. The app subnet 426 can be communicatively coupled to a service gateway 436 of the data plane VCN 418 and a NAT gateway 438 of the data plane VCN 418. The data plane data layer 450 can also include a DB subnet 430, which can be communicatively coupled to the app subnet 426 of the data plane app layer 446.

[0066] The Internet gateways 434 of the control plane VCNs 416 and of the data plane VCNs 418 may be communicatively coupled to a metadata management service 452, which may be communicatively coupled to the public Internet 454. The public Internet 454 may be communicatively coupled to NAT gateways 438 of the control plane VCNs 416 and of the data plane VCNs 418. The service gateways 436 of the control plane VCNs 416 and of the data plane VCNs 418 may be communicatively coupled to cloud services 456.

[0067] In some examples, a service gateway 436 in the control plane VCN 416 or in the data plane VCN 418 can make application programming interface (API) calls to cloud services 456 without traversing the public Internet 454. API calls from the service gateway 436 to the cloud services 456 can be one-way: the service gateway 436 can make an API call to the cloud services 456 and the cloud services 456 can send the requested data to the service gateway 436. However, the cloud services 456 cannot initiate the API call to the service gateway 436.

[0068] In some examples, secure host tenancy 404 may be directly connected to service tenancy 419, which may otherwise be isolated. Secure host subnet 408 may communicate with SSH subnet 414 through LPG 410, which may allow bidirectional communication through otherwise isolated systems. Connecting secure host subnet 408 to SSH subnet 414 may give secure host subnet 408 access to other entities within service tenancy 419.

[0069] Control plane VCN 416 may enable users of service tenancy 419 to set up or otherwise provision desired resources. The desired resources provisioned in control plane VCN 416 may be deployed or otherwise used in data plane VCN 418. In some examples, control plane VCN 416 may be isolated from data plane VCN 418, and data plane mirror app layer 440 of control plane VCN 416 may communicate with data plane app layer 446 of data plane VCN 418 via VNIC 442, which may be contained within data plane mirror app layer 440 and data plane app layer 446.

[0070] In some examples, a user, or customer, of the system may make a request, such as a create, read, update, or delete (CRUD) operation, over the public Internet 454, which may communicate the request to a metadata management service 452. The metadata management service 452 may communicate the request to the control plane VCN 416 through an Internet gateway 434. The request may be received by a LB subnet 422 contained within the control plane DMZ layer 420. The LB subnet 422 may determine that the request is valid, and in response to this determination, the LB subnet 422 may transmit the request to an app subnet 426 contained within the control plane app layer 424. If the validity of the request is verified and requires a call to the public Internet 454, the call to the public Internet 454 may be transmitted to a NAT gateway 438 that may make the call to the public Internet 454. Metadata that may be desired to be stored by the request may be stored in the DB subnet 430.

[0071] In some examples, data plane mirror app layer 440 can facilitate direct communication between control plane VCN 416 and data plane VCN 418. For example, it may be desired that configuration modifications, updates, or other suitable changes be applied to resources contained within data plane VCN 418. Through VNIC 442, control plane VCN 416 can communicate directly with resources contained within data plane VCN 418, thereby performing configuration modifications, updates, or other suitable changes thereon.

[0072] In some embodiments, the control plane VCN 416 and the data plane VCN 418 may be subsumed within the service tenancy 419. In this case, the user or customer of the system may not own or operate either the control plane VCN 416 or the data plane VCN 418. Instead, the IaaS provider may own or operate the control plane VCN 416 and the data plane VCN 418, both of which may be subsumed within the service tenancy 419. This embodiment may allow for network isolation that may prevent users or customers from interacting with other users' or customers' resources. This embodiment may also allow the user or customer of the system to store databases privately without having to rely on the public internet 454 for storage, which may not have the desired level of threat protection.

[0073] In other embodiments, LB subnet 422 contained within control plane VCN 416 may be configured to receive signals from service gateway 436. In this embodiment, control plane VCN 416 and data plane VCN 418 may be configured to be called by customers of the IaaS provider without calling the public Internet 454. Customers of the IaaS provider may desire this embodiment because databases used by the customers may be stored on service tenancy 419, which may be controlled by the IaaS provider and isolated from the public Internet 454.

[0074] 5 is a block diagram 500 illustrating another example pattern of an IaaS architecture according to at least one embodiment. A service operator 502 (e.g., service operator 402 of FIG. 4) may be communicatively coupled to a secure host tenancy 504 (e.g., secure host tenancy 404 of FIG. 4) that may include a virtual cloud network (VCN) 506 (e.g., VCN 406 of FIG. 4) and a secure host subnet 508 (e.g., secure host subnet 408 of FIG. 4). The VCN 506 may include a local peering gateway (LPG) 510 (e.g., LPG 410 of FIG. 4) that may be communicatively coupled to a secure shell (SSH) VCN 512 (e.g., SSH VCN 412 of FIG. 4) via an LPG 410 contained within the SSH VCN 512. SSH VCN 512 can include an SSH subnet 514 (e.g., SSH subnet 414 in FIG. 4), which can be communicatively coupled to a control plane VCN 516 (e.g., control plane VCN 416 in FIG. 4) via an LPG 510 that is contained within the control plane VCN 516. The control plane VCN 516 can be contained within a service tenancy 519 (e.g., service tenancy 419 in FIG. 4), and the data plane VCN 518 (e.g., data plane VCN 418 in FIG. 4) can be contained within a customer tenancy 521, which can be owned or operated by a user, or customer, of the system.

[0075] The control plane VCN 516 may include a control plane DMZ layer 520 (e.g., control plane DMZ layer 420 of FIG. 4) that may include a LB subnet 522 (e.g., LB subnet 422 of FIG. 4), a control plane app layer 524 (e.g., control plane app layer 424 of FIG. 4) that may include an app subnet 526 (e.g., app subnet 426 of FIG. 4), and a control plane data layer 528 (e.g., control plane data layer 428 of FIG. 4) that may include a database (DB) subnet 530 (e.g., similar to DB subnet 430 of FIG. 4). The LB subnet 522 contained within the control plane DMZ layer 520 may be communicatively coupled to an app subnet 526 contained within the control plane app layer 524 and to an Internet gateway 534 (e.g., Internet gateway 434 of FIG. 4 ) that may be contained within the control plane VCN 516, and the app subnet 526 may be communicatively coupled to a DB subnet 530 contained within the control plane data layer 528, as well as to a service gateway 536 (e.g., service gateway 436 of FIG. 4 ) and a network address translation (NAT) gateway 538 (e.g., NAT gateway 438 of FIG. 4 ). The control plane VCN 516 may include the service gateway 536 and the NAT gateway 538.

[0076] The control plane VCN 516 can include a data plane mirror app layer 540 (e.g., data plane mirror app layer 440 of FIG. 4 ), which can include an app subnet 526. The app subnet 526 contained within the data plane mirror app layer 540 can include a virtual network interface controller (VNIC) 542 (e.g., VNIC 442) on which a compute instance 544 (e.g., similar to compute instance 444 of FIG. 4 ) can run. The compute instance 544 can facilitate communication between the app subnet 526 of the data plane mirror app layer 540 and the app subnet 526, which can be contained within the data plane app layer 546 (e.g., data plane app layer 446 of FIG. 4 ), via the VNIC 542 contained within the data plane mirror app layer 540 and the VNIC 542 contained within the data plane app layer 546.

[0077] The Internet gateway 534 contained within the control plane VCN 516 may be communicatively coupled to a metadata management service 552 (e.g., metadata management service 452 of FIG. 4), which may be communicatively coupled to a public Internet 554 (e.g., public Internet 454 of FIG. 4). The public Internet 554 may be communicatively coupled to a NAT gateway 538 contained within the control plane VCN 516. The service gateway 536 contained within the control plane VCN 516 may be communicatively coupled to cloud services 556 (e.g., cloud services 456 of FIG. 4).

[0078] In some examples, the data plane VCN 518 may be subsumed within the customer tenancy 521. In this case, the IaaS provider may provide a control plane VCN 516 per customer, and the IaaS provider may set up a unique compute instance 544 subsumed within the service tenancy 519 for each customer. Each compute instance 544 may enable communication between the control plane VCN 516 subsumed within the service tenancy 519 and the data plane VCN 518 subsumed within the customer tenancy 521. The compute instance 544 may enable resources provisioned within the control plane VCN 516 subsumed within the service tenancy 519 to be deployed or otherwise used within the data plane VCN 518 subsumed within the customer tenancy 521.

[0079] In another example, an IaaS provider customer may have a database based within customer tenancy 521. In this example, control plane VCN 516 may include data plane mirror app layer 540, which may include app subnet 526. Data plane mirror app layer 540 may reside within data plane VCN 518, but data plane mirror app layer 540 may not be based within data plane VCN 518. That is, data plane mirror app layer 540 may have access to customer tenancy 521, but data plane mirror app layer 540 may not reside within data plane VCN 518 or be owned or operated by an IaaS provider customer. Data plane mirror app layer 540 may be configured to make calls to data plane VCN 518, but may not be configured to make calls to any entities contained within control plane VCN 516. A customer may desire to deploy or otherwise use resources in the data plane VCN 518 provisioned in the control plane VCN 516, and the data plane mirror app layer 540 can facilitate the customer's desired deployment or other use of the resources.

[0080] In some embodiments, the IaaS provider's customer can apply filters to the data plane VCN 518. In this embodiment, the customer can determine what the data plane VCN 518 can access, and the customer can limit access from the data plane VCN 518 to the public Internet 554. The IaaS provider may not be able to apply filters or otherwise control the access of the data plane VCN 518 to any external networks or databases. Applying filters and controls by the customer to the data plane VCN 518, which is contained within the customer tenancy 521, can help isolate the data plane VCN 518 from other customers and from the public Internet 554.

[0081] In some embodiments, cloud services 556 may be called by service gateway 536 to access services that may not be on the public internet 554, on the control plane VCN 516, or on the data plane VCN 518. The connection between cloud services 556 and the control plane VCN 516 or the data plane VCN 518 may not be live or continuous. Cloud services 556 may be on different networks owned or operated by an IaaS provider. Cloud services 556 may be configured to receive calls from service gateway 536 and may be configured not to receive calls from the public internet 554. Some cloud services 556 may be isolated from other cloud services 556, and control plane VCN 516 may be isolated from cloud services 556 that may not be in the same region as control plane VCN 516. For example, control plane VCN 516 may be located in “Region 1” and cloud service “Deployment 4” may be located in Region 1 and in “Region 2.” If a call is made to deployment 4 by way of a service gateway 536 contained within a control plane VCN 516 located in region 1, the call may be routed to deployment 4 in region 1. In this example, control plane VCN 516, or deployment 4 in region 1, may not be communicatively coupled to or otherwise in communication with deployment 4 in region 2.

[0082] 6 is a block diagram 600 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 602 (e.g., service operator 402 of FIG. 4) may be communicatively coupled to a secure host tenancy 604 (e.g., secure host tenancy 404 of FIG. 4) that may include a virtual cloud network (VCN) 606 (e.g., VCN 406 of FIG. 4) and a secure host subnet 608 (e.g., secure host subnet 408 of FIG. 4). The VCN 606 may include an LPG 610 (e.g., LPG 410 of FIG. 4) that may be communicatively coupled to an SSH VCN 612 (e.g., SSH VCN 412 of FIG. 4) via an LPG 610 contained within the SSH VCN 612. SSH VCN 612 can include an SSH subnet 614 (e.g., SSH subnet 414 in FIG. 4), which can be communicatively coupled to a control plane VCN 616 (e.g., control plane VCN 416 in FIG. 4) via an LPG 610 contained within the control plane VCN 616, and to a data plane VCN 618 (e.g., data plane 418 in FIG. 4) via an LPG 610 contained within the data plane VCN 618. The control plane VCN 616 and the data plane VCN 618 can be contained within a service tenancy 619 (e.g., service tenancy 419 in FIG. 4).

[0083] The control plane VCN 616 may include a control plane DMZ layer 620 (e.g., control plane DMZ layer 420 of FIG. 4) that may include a load balancer (LB) subnet 622 (e.g., LB subnet 422 of FIG. 4), a control plane app layer 624 (e.g., control plane app layer 424 of FIG. 4) that may include an app subnet 626 (e.g., similar to app subnet 426 of FIG. 4), and a control plane data layer 628 (e.g., control plane data layer 428 of FIG. 4) that may include a DB subnet 630. The LB subnet 622 contained within the control plane DMZ layer 620 may be communicatively coupled to an app subnet 626 contained within the control plane app layer 624 and to an Internet gateway 634 (e.g., Internet gateway 434 of FIG. 4 ) that may be contained within the control plane VCN 616, which may be communicatively coupled to a DB subnet 630 contained within the control plane data layer 628, as well as to a service gateway 636 (e.g., service gateway of FIG. 4 ), and a network address translation (NAT) gateway 638 (e.g., NAT gateway 438 of FIG. 4 ). The control plane VCN 616 may include the service gateway 636 and the NAT gateway 638.

[0084] The data plane VCN 618 may include a data plane app layer 646 (e.g., data plane app layer 446 of FIG. 4), a data plane DMZ layer 648 (e.g., data plane DMZ layer 448 of FIG. 4), and a data plane data layer 650 (e.g., data plane data layer 450 of FIG. 4). The data plane DMZ layer 648 may include a trusted app subnet 660 and an untrusted app subnet 662 of the data plane app layer 646, as well as a LB subnet 622 that may be communicatively coupled to an Internet gateway 634 contained within the data plane VCN 618. The trusted app subnet 660 may be communicatively coupled to a service gateway 636 contained within the data plane VCN 618, a NAT gateway 638 contained within the data plane VCN 618, and a DB subnet 630 contained within the data plane data layer 650. The untrusted app subnet 662 may be communicatively coupled to a service gateway 636 contained within the data plane VCN 618 and to a DB subnet 630 contained within the data plane data layer 650. The data plane data layer 650 may include a DB subnet 630 that may be communicatively coupled to a service gateway 636 contained within the data plane VCN 618.

[0085] The untrusted app subnet 662 may include one or more primary VNICs 664(1)-(N), which may be communicatively coupled to tenant virtual machines (VMs) 666(1)-(N). Each tenant VM 666(1)-(N) may be communicatively coupled to a respective app subnet 667(1)-(N), which may be contained within a respective container egress VCN 668(1)-(N), which may be contained within a respective customer tenancy 670(1)-(N). Each secondary VNIC 672(1)-(N) may facilitate communication between the untrusted app subnet 662 contained within the data plane VCN 618 and the app subnet contained within the container egress VCN 668(1)-(N). Each container egress VCN 668(1)-(N) may include a NAT gateway 638, which may be communicatively coupled to the public Internet 654 (e.g., public Internet 454 of FIG. 4).

[0086] An Internet gateway 634 contained within the control plane VCN 616 and contained within the data plane VCN 618 may be communicatively coupled to a metadata management service 652 (e.g., metadata management system 452 of FIG. 4), which may be communicatively coupled to the public Internet 654. The public Internet 654 may be communicatively coupled to a NAT gateway 638 contained within the control plane VCN 616 and contained within the data plane VCN 618. A service gateway 636 contained within the control plane VCN 616 and contained within the data plane VCN 618 may be communicatively coupled to cloud services 656.

[0087] In some embodiments, data plane VCN 618 may be integrated with customer tenancies 670. This integration may be useful or desirable for an IaaS provider's customers in some cases, such as when they may want support in executing code. The customers may provide code for execution that may be disruptive, communicate with other customer resources, or otherwise cause undesirable effects. In response, the IaaS provider may determine whether to execute code provided to the IaaS provider by the customer.

[0088] In some examples, an IaaS provider's customer may grant temporary network access to the IaaS provider and request that a function be attached to the data plane app layer 646. The code to perform the function may be executed within a VM 666(1)-(N), and the code may not be configured to run anywhere else on the data plane VCN 618. Each VM 666(1)-(N) may be connected to one customer tenancy 670. Each container 671(1)-(N) contained within a VM 666(1)-(N) may be configured to execute code. In this case, there may be double isolation (e.g., container 671(1)-(N) may execute code, and container 671(1)-(N) may be contained within a VM 666(1)-(N) that is contained within at least an untrusted app subnet 662), which may help prevent erroneous or otherwise undesirable code from damaging the IaaS provider's network or from damaging a different customer's network. Containers 671(1)-(N) may be communicatively coupled to customer tenancy 670 and may be configured to transmit or receive data from customer tenancy 670. Containers 671(1)-(N) may not be configured to transmit or receive data from any other entity in data plane VCN 618. Upon completing execution of the code, the IaaS provider may kill or otherwise dispose of containers 671(1)-(N).

[0089] In some embodiments, trusted app subnet 660 may execute code that may be owned or operated by the IaaS provider. In this embodiment, trusted app subnet 660 may be communicatively coupled to DB subnet 630 and configured to perform CRUD operations in DB subnet 630. Untrusted app subnet 662 may be communicatively coupled to DB subnet 630, but in this embodiment, untrusted app subnet 662 may be configured to perform read operations in DB subnet 630. Containers 671(1)-(N) that may be contained within each customer's VMs 666(1)-(N) and may execute code from the customer may not be communicatively coupled to DB subnet 630.

[0090] In other embodiments, the control plane VCN 616 and the data plane VCN 618 may not be directly communicatively coupled. In this embodiment, there may be no direct communication between the control plane VCN 616 and the data plane VCN 618. However, communication may occur indirectly through at least one method. An LPG 610 may be established by an IaaS provider that can facilitate communication between the control plane VCN 616 and the data plane VCN 618. In another example, the control plane VCN 616 or the data plane VCN 618 may make a call to a cloud service 656 through a service gateway 636. For example, a call from the control plane VCN 616 to the cloud service 656 may include a request for a service that can communicate with the data plane VCN 618.

[0091] 7 is a block diagram 700 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 702 (e.g., service operator 402 of FIG. 4) may be communicatively coupled to a secure host tenancy 704 (e.g., secure host tenancy 404 of FIG. 4) that may include a virtual cloud network (VCN) 706 (e.g., VCN 406 of FIG. 4) and a secure host subnet 708 (e.g., secure host subnet 408 of FIG. 4). The VCN 706 may include an LPG 710 (e.g., LPG 410 of FIG. 4) that may be communicatively coupled to an SSH VCN 712 (e.g., SSH VCN 412 of FIG. 4) via an LPG 710 contained within the SSH VCN 712. SSH VCN 712 can include an SSH subnet 714 (e.g., SSH subnet 414 of FIG. 4), which can be communicatively coupled to a control plane VCN 716 (e.g., control plane VCN 416 of FIG. 4) via an LPG 710 contained within the control plane VCN 716, and to a data plane VCN 718 (e.g., data plane 418 of FIG. 4) via an LPG 710 contained within the data plane VCN 718. The control plane VCN 716 and the data plane VCN 718 can be contained within a service tenancy 719 (e.g., service tenancy 419 of FIG. 4).

[0092] The control plane VCN 716 may include a control plane DMZ layer 720 (e.g., control plane DMZ layer 420 of FIG. 4) that may include a LB subnet 722 (e.g., LB subnet 422 of FIG. 4), a control plane app layer 724 (e.g., control plane app layer 424 of FIG. 4) that may include an app subnet 726 (e.g., app subnet 426 of FIG. 4), and a control plane data layer 728 (e.g., control plane data layer 428 of FIG. 4) that may include a DB subnet 730 (e.g., DB subnet 630 of FIG. 6). The LB subnet 722 contained within the control plane DMZ layer 720 may be communicatively coupled to an app subnet 726 contained within the control plane app layer 724 and to an Internet gateway 734 (e.g., Internet gateway 434 of FIG. 4 ) that may be contained within the control plane VCN 716, which may be communicatively coupled to a DB subnet 730 contained within the control plane data layer 728, as well as to a service gateway 736 (e.g., service gateway of FIG. 4 ), and a network address translation (NAT) gateway 738 (e.g., NAT gateway 438 of FIG. 4 ). The control plane VCN 716 may include the service gateway 736 and the NAT gateway 738.

[0093] The data plane VCN 718 may include a data plane app layer 746 (e.g., data plane app layer 446 of FIG. 4), a data plane DMZ layer 748 (e.g., data plane DMZ layer 448 of FIG. 4), and a data plane data layer 750 (e.g., data plane data layer 450 of FIG. 4). The data plane DMZ layer 748 may include a trusted app subnet 760 (e.g., trusted app subnet 660 of FIG. 6) and an untrusted app subnet 762 (e.g., untrusted app subnet 662 of FIG. 6) of the data plane app layer 746, as well as a LB subnet 722 that may be communicatively coupled to an Internet gateway 734 contained within the data plane VCN 718. The trusted app subnet 760 may be communicatively coupled to a service gateway 736 contained within the data plane VCN 718, a NAT gateway 738 contained within the data plane VCN 718, and a DB subnet 730 contained within the data plane data layer 750. The untrusted app subnet 762 may be communicatively coupled to a service gateway 736 contained within the data plane VCN 718 and to a DB subnet 730 contained within the data plane data layer 750. The data plane data layer 750 may include a DB subnet 730 that may be communicatively coupled to a service gateway 736 contained within the data plane VCN 718.

[0094] The untrusted app subnet 762 may include primary VNICs 764(1)-(N), which may be communicatively coupled to tenant virtual machines (VMs) 766(1)-(N) residing within the untrusted app subnet 762. Each tenant VM 766(1)-(N) executes code within a respective container 767(1)-(N), which may be communicatively coupled to an app subnet 726, which may be contained within a data plane app layer 746, which may be contained within a container egress VCN 768. Each secondary VNIC 772(1)-(N) may facilitate communication between the untrusted app subnet 762, which is contained within the data plane VCN 718, and the app subnet, which is contained within the container egress VCN 768. The container egress VCN may include a NAT gateway 738, which may be communicatively coupled to the public Internet 754 (e.g., public Internet 454 of FIG. 4).

[0095] An Internet gateway 734 contained within the control plane VCN 716 and contained within the data plane VCN 718 may be communicatively coupled to a metadata management service 752 (e.g., metadata management system 452 of FIG. 4), which may be communicatively coupled to the public Internet 754. The public Internet 754 may be communicatively coupled to a NAT gateway 738 contained within the control plane VCN 716 and contained within the data plane VCN 718. A service gateway 736 contained within the control plane VCN 716 and contained within the data plane VCN 718 may be communicatively coupled to cloud services 756.

[0096] In some examples, the pattern illustrated by the architecture of block diagram 700 of FIG. 7 may be considered an exception to the pattern illustrated by the architecture of block diagram 600 of FIG. 6 and may be desirable for an IaaS provider's customer when the IaaS provider cannot communicate directly with the customer (e.g., disconnected region). Each container 767(1)-(N) contained within a per-customer VM 766(1)-(N) may be accessed in real time by the customer. The containers 767(1)-(N) may be configured to make calls to a respective secondary VNIC 772(1)-(N) contained within an app subnet 726 of the data plane app layer 746, which may be contained within a container egress VCN 768. The secondary VNIC 772(1)-(N) may route the call to a NAT gateway 738, which may route the call to the public Internet 754. In this example, containers 767(1)-(N) that may be accessed in real time by customers may be isolated from control plane VCN 716 and may be isolated from other entities contained within data plane VCN 718. Containers 767(1)-(N) may also be isolated from resources from other customers.

[0097] In another example, a customer may call cloud service 756 using container 767(1)-(N). In this example, the customer may execute code within container 767(1)-(N) that requests a service from cloud service 756. Container 767(1)-(N) may transmit the request to secondary VNIC 772(1)-(N), which may transmit the request to a NAT gateway, which may transmit the request to public Internet 754. Public Internet 754 may transmit the request via Internet gateway 734 to LB subnet 722 contained within control plane VCN 716. In response to determining that the request is valid, the LB subnet may transmit the request to app subnet 726, which may transmit the request to cloud service 756 via service gateway 736.

[0098] It should be understood that the IaaS architectures 400, 500, 600, 700 depicted in the figures may have other components than those depicted. Additionally, the illustrated embodiments are merely examples of some of the cloud infrastructure systems that may incorporate an embodiment of the present disclosure. In some other embodiments, the IaaS system may have more or fewer components than depicted in the figures, may combine two or more components, or may have a different configuration or arrangement of components.

[0099] In some embodiments, the IaaS system described herein may include a suite of applications, middleware, and database service offerings that are delivered to customers in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner. One example of such an IaaS system is Oracle Cloud Infrastructure (OCI), offered by the present assignee.

[0100] 8 illustrates an exemplary computer system 800 upon which various embodiments may be implemented. System 800 may be used to implement any of the computer systems described above. As shown in the figure, computer system 800 includes a processing unit 804 that communicates with a number of peripheral subsystems via a bus subsystem 802. These peripheral subsystems may include a processing acceleration unit 806, an I / O subsystem 808, a storage subsystem 818, and a communications subsystem 824. The storage subsystem 818 includes a tangible computer-readable storage medium 822 and a system memory 810.

[0101] Bus subsystem 802 provides a mechanism for allowing the various components and subsystems of computer system 800 to communicate with each other as intended. Although bus subsystem 802 is shown diagrammatically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. Bus subsystem 802 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. For example, such architectures may include a Peripheral Component Interconnect (PCI) bus, which may be implemented as an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a mezzanine bus manufactured to the IEEE P1386.1 standard.

[0102]

[0001] Processing unit 804, which may be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers), controls the operation of computer system 800. One or more processors may be included within processing unit 804. These processors may include single-core or multi-core processors. In some embodiments, processing unit 804 may be implemented as one or more independent processing units 832 and / or 834, with single or multi-core processors included within each processing unit. In other embodiments, processing unit 804 may also be implemented as a quad-core processing unit formed by integrating two dual-core processors into a single chip.

[0103] In various embodiments, the processing unit 804 may execute various programs according to program code and may maintain multiple simultaneously executing programs or processes. At any one time, some or all of the program code to be executed may reside within the processor 804 and / or within the storage subsystem 818. Through suitable programming, the processor 804 may provide various functionality as described above. The computer system 800 may additionally include a processing acceleration unit 806, which may include a digital signal processor (DSP), a special purpose processor, and / or the like.

[0104] The / O subsystem 808 may include user interface input devices and user interface output devices. User interface input devices may include pointing devices such as keyboards, mice or trackballs, touchpads or touchscreens built into displays, scroll wheels, click wheels, dials, buttons, switches, keypads, voice command recognition systems, audio input devices using microphones, and other types of input devices. User interface input devices may include motion sensing and / or gesture recognition devices such as Microsoft Kinect® motion sensors that allow a user to control and interact with an input device, such as a Microsoft Xbox® 360 game controller, through a natural user interface using gestures and spoken commands. User interface input devices may also include eye gesture recognition devices such as the Google Glass® blink detector that detects eye activity from a user (e.g., "blinking" while taking a picture and / or making a menu selection) and translates the eye gesture as input into the input device (e.g., Google Glass®). Additionally, the user interface input devices may include a voice recognition sensing device that allows a user to interact with a voice recognition system (e.g., the Siri® navigator) through voice commands.

[0105] User interface input devices may also include, but are not limited to, three-dimensional (3D) mice, joysticks or pointing sticks, game pads and graphic tablets, as well as audio / visual devices such as speakers, digital cameras, digital camcorders, portable media players, webcams, image scanners, fingerprint scanners, barcode readers 3D scanners, 3D printers, laser range finders, and eye-tracking devices. In addition, user interface input devices may include medical imaging input devices, such as, for example, computed tomography, magnetic resonance imaging, position emission tomography, medical ultrasound devices, etc. User interface input devices may also include audio input devices, such as, for example, MIDI keyboards, digital musical instruments, and the like.

[0106] User interface output devices may include non-visual displays such as a display subsystem, indicator lights, or audio output devices. Display subsystems may be flat panel devices, such as those using cathode ray tubes (CRTs), liquid crystal displays (LCDs) or plasma displays, projection devices, touch screens, and the like. In general, use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from computer system 800 to a user or to another computer. For example, user interface output devices may include various display devices that visually convey text, graphics, and audio / video information, such as, but not limited to, monitors, printers, speakers, headphones, automobile navigation systems, plotters, audio output devices, and modems.

[0107] Computer system 800 may include a storage subsystem 818 that provides a tangible, non-transitory computer-readable storage medium for storing software and data structures that provide the functionality of embodiments described in this disclosure. The software may include programs, code modules, instructions, scripts, etc. that, when executed by one or more cores or processors of processing unit 804, provide the functionality described above. Storage subsystem 818 may also provide a repository for storing data used in accordance with the present disclosure.

[0108] 8, storage subsystem 818 may include various components including a system memory 810, a computer readable storage medium 822, and a computer readable storage medium reader 820. The system memory 810 may store program instructions that are loadable and executable by the processing unit 804. The system memory 810 may also store data used during execution of the instructions and / or data generated during execution of the program instructions. A variety of different types of programs may be loaded into the system memory 810, including, but not limited to, client applications, web browsers, mid-tier applications, relational database management systems (RDBMS), virtual machines, containers, and the like.

[0109] System memory 810 may also store operating system 816. Examples of operating system 816 may include various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux operating systems, various commercially available UNIX® or UNIX-like operating systems (including, but not limited to, various GNU / Linux operating systems, Google Chrome® OS, and the like), and / or mobile operating systems such as iOS, Windows® Phone, Android® OS, BlackBerry® OS, and Palm® OS operating systems. In some implementations in which computer system 800 runs one or more virtual machines, the virtual machines along with their guest operating systems (GOS) may be loaded into system memory 810 and executed by one or more processors or cores of processing unit 804.

[0110] The system memory 810 can be of different configurations depending on the type of computer system 800. For example, the system memory 810 can be volatile memory (such as random access memory (RAM)) and / or non-volatile memory (such as read-only memory (ROM), flash memory, etc.). Different types of RAM configurations can be provided, including static random access memory (SRAM), dynamic random access memory (DRAM), and others. In some implementations, the system memory 810 can include a basic input / output system (BIOS), which contains the basic routines to help transfer information between elements within the computer system 800, such as during start-up.

[0111] Computer-readable storage medium 822 may represent a remote, local, fixed, and / or removable storage device-plus-storage medium for temporarily and / or more permanently containing and storing computer-readable information for use by computer system 800, including instructions executable by processing unit 804 of computer system 800.

[0112] The computer readable storage medium 822 may also include any suitable medium known or used in the art, including, but not limited to, storage media and communication media, such as volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage and / or transmission of information. This may include tangible computer readable storage media, such as RAM, ROM, electronically erasable programmable ROM (EEPROM), flash memory, or other memory technology, CD-ROM, digital versatile disk (DVD), or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage, or other magnetic storage devices, or other tangible computer readable media.

[0113] By way of example, the computer readable storage medium 822 may include hard disk drives that read from or write to non-removable, non-volatile magnetic media, magnetic disk drives that read from or write to removable, non-volatile magnetic disks, and optical disk drives that read from or write to removable, non-volatile optical disks, such as CD ROMs, DVDs, and Blu-Ray® disks or other optical media. The computer readable storage medium 822 may include, but is not limited to, Zip® drives, flash memory cards, universal serial bus (USB) flash drives, secure digital (SD) cards, DVD disks, digital video tape, and the like. The computer-readable storage media 822 may also include solid-state drives (SSDs) based on non-volatile memory, such as flash memory-based SSDs, enterprise flash drives, solid-state ROM, and the like, SSDs based on volatile memory, such as solid-state RAM, dynamic RAM, static RAM, DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, and hybrid SSDs employing a combination of DRAM and flash memory-based SSDs. Disk drives and their associated computer-readable media may provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computer system 800.

[0114] Machine-readable instructions executable by one or more processors or cores of the processing unit 804 may be stored on a non-transitory computer-readable storage medium. The non-transitory computer-readable storage medium may include physically tangible memory or storage devices, including volatile memory storage devices and / or non-volatile storage devices. Examples of non-transitory computer-readable storage media include magnetic storage media (e.g., disks or tapes), optical storage media (e.g., DVDs, CDs), various types of RAM, ROM, or flash memory, hard drives, floppy drives, removable memory drives (e.g., USB drives), or other types of storage devices.

[0115] The communications subsystem 824 provides an interface to other computer systems and networks. The communications subsystem 824 serves as an interface for receiving data from other systems and transmitting data from the computer system 800 to other systems. For example, the communications subsystem 824 may enable the computer system 800 to connect to one or more devices via the Internet. In some embodiments, the communications subsystem 824 may include a radio frequency (RF) transceiver component for accessing wireless voice and / or data networks (e.g., using advanced data network technologies such as cellular telephone technologies, 3G, 4G, or EDGE (enhanced data rates for global evolution), WiFi (IEEE 802.11 family of standards, or other mobile communications technologies, or any combination thereof), a global positioning system (GPS) receiver component, and / or other components. In some embodiments, the communications subsystem 824 may provide wired network connectivity (e.g., Ethernet) in addition to or instead of a wireless interface.

[0116] In some embodiments, the communications subsystem 824 may also receive incoming communications in the form of structured and / or unstructured data feeds 826, event streams 828, event updates 830, and the like for one or more users who may be using the computer system 800.

[0117] As an example, the communications subsystem 824 may be configured to receive data feeds 826 in real time from users of social networks and / or other communications services, such as web feeds such as Twitter® feeds, Facebook® updates, Rich Site Summary (RSS) feeds, and / or real-time updates from one or more third party sources.

[0118] In addition, the communications subsystem 824 may also be configured to receive data in the form of a continuous data stream, which may include an event stream 828 of real-time events, which may be continuous or bounded, essentially without a clear end, and / or event updates 830. Examples of applications that generate continuous data may include, for example, sensor data applications, financial stock ticker boards, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automotive traffic monitoring, and the like.

[0119] The communications subsystem 824 may also be configured to output structured and / or unstructured data feeds 826, event streams 828, event updates 830, and the like to one or more databases that may be in communication with one or more streaming data source computers coupled to the computer system 800.

[0120] The computer system 800 can be one of a variety of types, including a handheld portable device (e.g., an iPhone® cellular phone, an iPad® computing tablet, a PDA), a wearable device (e.g., a Google Glass® head mounted display), a PC, a workstation, a mainframe, a kiosk, a server rack, or any other data processing system.

[0121] Due to the ever-changing nature of computers and networks, the description of the computer system 800 shown in the figure is intended to be merely illustrative. Many other configurations are possible having more or fewer components than the system shown in the figure. For example, customized hardware could also be used and / or particular elements could be implemented in hardware, firmware, software (including applets), or a combination. Furthermore, connections to other computing devices, such as network input / output devices, could be employed. Based on the disclosure and teachings provided herein, one of ordinary skill in the art will appreciate other ways and / or methods for implementing the various embodiments.

[0122] Although specific embodiments have been described, various changes, modifications, alternative constructions, and equivalents are encompassed within the scope of the present disclosure. The embodiments are not limited to operation in some particular data processing environment, but can freely operate in multiple data processing environments. In addition, while the embodiments have been described using a particular sequence of transactions and steps, it should be apparent to one skilled in the art that the scope of the present disclosure is not limited to the sequence of transactions and steps described. Various features and aspects of the above-described embodiments may be used individually or jointly.

[0123] Furthermore, although the embodiments have been described using a particular combination of hardware and software, it should be appreciated that other combinations of hardware and software are within the scope of the present disclosure. The embodiments may be implemented in hardware only, or in software only, or using a combination thereof. The various processes described herein may be implemented in any combination on the same processor or different processors. Thus, when a component or module is described as being configured to perform a certain operation, such configuration may be achieved, for example, by designing an electronic circuit to perform the operation, by programming a programmable electronic circuit (such as a microprocessor) to perform the operation, or any combination thereof. Processes may communicate using a variety of techniques, including, but not limited to, conventional techniques for inter-process communication, and different pairs of processes may use different techniques, or the same pair of processes may use different techniques at different times.

[0124] Accordingly, the specification and drawings are to be regarded in an illustrative and not a restrictive sense. It will be apparent, however, that additions, subtractions, deletions, and other changes and modifications may be made thereto without departing from the broader spirit and scope as set forth in the claims. Thus, while specific disclosed embodiments have been described, these are not intended to be limiting. Various modifications and equivalents are intended to be within the scope of the appended claims.

[0125] Use of the terms "a," "an," and "the" and similar referents in the context of describing embodiments of the present disclosure (particularly in the context of the appended claims) should be construed to encompass both the singular and the plural, unless otherwise stated herein or clearly contradicted by context. The terms "comprising," "having," "including," and "containing" should be construed as open-ended terms (i.e., meaning "including, but not limited to"), unless otherwise noted. The term "connected" should be construed as partially or wholly contained within, attached to, or joined together, even if there is some intervening material. The recitation of ranges of values ​​herein is merely intended to serve as a shorthand method of individually referring to each separate value included in the range, unless otherwise stated herein, and each separate value is incorporated into the specification as if it were individually stated herein. All methods described herein can be performed in any suitable order, unless otherwise stated herein or otherwise clearly contradicted by context. The use of any and all examples or exemplary language (e.g., "such as") provided herein is merely intended to facilitate easier understanding of the embodiments, and does not impose limitations on the scope of the disclosure, unless otherwise stated. No language in the specification should be construed as indicating any non-claim element as essential to the practice of the disclosure.

[0126] Disjunctive language, such as the phrase "at least one of X, Y, or Z," is generally intended to be understood in context as being used to indicate that an item, term, etc. may be either X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z), unless specifically noted otherwise. Thus, such disjunctive language is generally not intended to, and should not, imply that some embodiments require that at least one of X, at least one of Y, or at least one of Z, respectively, be present.

[0127] Preferred embodiments of the present disclosure are described herein, including the best mode known for carrying out the present disclosure. Variations of these preferred embodiments may become apparent to those skilled in the art upon reading the above description. Those skilled in the art should be able to adopt such variations as necessary, and the present disclosure may be carried out in ways other than those specifically described herein. Accordingly, the present disclosure includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Moreover, unless otherwise indicated herein, any combination of the above-described elements in all possible variations thereof is encompassed by the present disclosure.

[0128] All references cited herein, including publications, patent applications, and patents, are hereby incorporated by reference to the same extent as if each reference was individually and specifically indicated to be incorporated by reference and was set forth in its entirety herein.

[0129] In the above specification, aspects of the disclosure are described with reference to specific embodiments thereof, but those skilled in the art will recognize that the disclosure is not limited thereto. Various features and aspects of the above disclosure may be used individually or jointly. Moreover, the embodiments may be utilized in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of the specification. Thus, the specification and drawings should be regarded as illustrative and not restrictive.

Claims

1. Receiving a request from a user to take an action in a first system; determining a first authorization status of the action by the user using the first system; determining a second authorization status of the action by the user using a second system; determining a combination of the first authorization status and the second authorization status; and comparing the combination of the first authorization status and the second authorization status to an authorization criterion.

2. The method of claim 1 , further comprising authorizing the action by the user when the combination of the first authorization status and the second authorization status meets the authorization criteria.

3. 3. The method of claim 2, wherein the combination of the first authorization status and the second authorization status meets the authorization criteria when the combination of the first authorization status and the second authorization status includes authorization from each of the first system and the second system for the user to take the action.

4. 3. The method of claim 2, further comprising authorizing the action by the user when the combination of the first authorization status and the second authorization status includes authorization from at least one of the first system and the second system for the user to take the action.

5. The method of claim 1 , further comprising: rejecting the action by the user when the combination of the first authorization status and the second authorization status does not meet the authorization criteria.

6. 6. The method of claim 5, wherein the combination of the first authorization status and the second authorization status does not meet the authorization criteria when the combination of the first authorization status and the second authorization status includes a denial of authorization from at least one of the first system and the second system.

7. The method of any one of claims 1 to 4, wherein the first system comprises a Role-Based Access Control (RBAC) system and the second system comprises an Attribute-Based Access Control (ABAC) system.

8. 8. The method of claim 7, wherein receiving the request for the user to take the action in the first system comprises receiving a signed request from a first application associated with the first system.

9. 9. The method of claim 8, wherein receiving the request for the user to take the action in the first system includes receiving information identifying the first application, the user, the action, and an endpoint that will be affected by the action.

10. 10. The method of claim 9, wherein the first system verifies the validity of the signed request and derives a relationship principal with the second system based on at least one of the received signed request and the received information.

11. 11. The method of claim 10, wherein verifying the validity of the signed request includes the second system requesting and receiving a public key from a data plane and verifying the validity of the signed request using the public key.

12. The method of claim 11 , wherein determining the first authorization status of the action by the user with the first system comprises determining a domain-specific authorization of the related principal.

13. The method of claim 12 , wherein the domain-specific authorization of the related principal is determined according to an authorization policy of the first system.

14. 11. The method of claim 10, wherein determining the first authorization status of the action by the user using the first system includes evaluating the request to take an action according to an authorization policy of the first system, and determining the second authorization status of the action by the user using the second system includes matching the authorization policy of the first system to a corresponding authorization policy of the second system based at least in part on the received information.

15. 15. The method of claim 14, wherein evaluating the request to take an action in accordance with an authorization policy of the first system includes identifying a role of the user and a domain of the user, retrieving permissions associated with the role of the user and the domain of the user, and determining that the received information identifies an action permitted by the retrieved permissions.

16. 16. The method of claim 15, wherein determining the second authorization status of the action by the user using the second system further comprises determining a principal of the user, retrieving an access policy associated with the received request, and determining that the received request identifies an action permitted by the retrieved access policy.

17. 1. A system comprising: A first access control system, the first access control system comprising: at least one first processor; a memory containing a plurality of instructions executable by the at least one first processor; The system comprises: and a second access control system configured to determine a second authorization status for the requested user action; The first access control system comprises: receiving a request for a user to take an action within the first access control system; determining a first authorization status of the action by the user; receiving authorization information for the action from the second access control system; determining a combination of the first authorization status and the second authorization status; comparing the combination of the first authorization status and the second authorization status to an authorization criterion.

18. 20. The system of claim 17, wherein receiving the request for the user to take the action in the first access control system includes receiving a signed request from a first application associated with the first access control system and receiving information identifying the first application, the user, the action, and an endpoint that will be affected by the action, and the first access control system verifies the validity of the signed request and derives a relationship principal with the second access control system based on at least one of the received signed request and the received information.

19. 1. A computer readable program storing a plurality of instructions executable by one or more processors, the plurality of instructions, when executed by the one or more processors, causing the one or more processors to: Receiving a request from a user to take an action in a first system; determining a first authorization status of the action by the user using the first system; determining a second authorization status of the action by the user using a second system; determining a combination of the first authorization status and the second authorization status; and comparing the combination of the first and second authorization statuses to an authorization criterion.

20. 20. The computer readable program of claim 19, wherein receiving the request for the user to take the action in the first system includes receiving a signed request from a first application associated with the first system and receiving information identifying the first application, the user, the action, and endpoints that will be affected by the action, and the first system verifies the validity of the signed request and derives a relationship principal with the second system based on at least one of the received signed request and the received information.

Images