External identity providers as domain resources

Abstract

Described herein is a framework for generating a federated IAM system from a first identity and access management (IAM) system and a second IAM system that is different from the first IAM system. The federated IAM system is generated by (i) creating a domain in a customer tenant associated with the first IAM system and (ii) embedding an identity provider of the second IAM system in the domain. The federated IAM system receives a request from a user to perform an operation with respect to a resource associated with the second IAM system. The request is executed once the user is successfully authenticated by the federated IAM system.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Provisional Application No. 63 / 250,598, filed September 30, 2021, and U.S. Provisional Application No. 17 / 934,846, filed September 23, 2022. The entire contents of the foregoing applications are incorporated herein by reference in their entirety for all purposes.

[0002] Field The present disclosure relates to a framework for integrating two or more separate identity and access management systems in a seamless manner. [Background technology]

[0003] background Cloud service providers (CSPs) offer services under different models, including Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS) models. In a cloud environment, an identity and access management (IAM) system is typically provided by the CSP to control user access to resources provided or used by the cloud service. Typical services or functions provided by an IAM system include, but are not limited to, single sign-on capabilities for users, authentication and authorization services, and other identity-based services. Summary of the Invention [Problem to be solved by the invention]

[0004] The resources protected by the IAM system can be of different types, such as computing instances, block storage volumes, virtual cloud networks (VCNs), subnets, route tables, various callable APIs, and / or internal or legacy applications. These resources include resources stored in the cloud and / or customer on-premise resources. Each resource is identified by a unique identifier that is assigned to the resource upon creation of the resource. In a typical CSP operation, a first IAM system is provided to control user access to a first type of service (e.g., IaaS). Separately, a second IAM system is provided for security and identity management of a second type of application, such as SaaS and PaaS services. As a result, if a customer subscribes to both the first and second type of services, the customer needs to have two separate accounts (i.e., separate accounts associated with each IAM system).

[0005] To alleviate the burden on end users of remembering multiple sets of credentials associated with each individual account, identity federation has been proposed between a first IAM system and a second IAM system, but the identity provider federation process is complex and time-consuming, resulting in a poor user experience.

[0006] The embodiments described herein address the above problems individually and collectively. [Means for solving the problem]

[0007] Quick Overview

[0005] Embodiments of the present disclosure provide for generating a unified identity and access management (IAM) system from a first IAM system and a second IAM system. In some cases, the first IAM system can correspond to an Oracle Cloud Infrastructure (OCI) Infrastructure Identity and Access Management (IAM) system, and the second IAM system can correspond to an Identity Cloud Services (IDCS) system. Thus, this integration provides a unified IAM system, where requests to perform operations on resources associated with the second IAM system can be seamlessly authenticated / authorized by the unified IAM system without the need to federate the first IAM system with the second IAM system.

[0008] One aspect of the disclosure provides a method that includes generating a federated IAM system from a first identity and access management (IAM) system and a second IAM system, different from the first IAM system, by (i) creating a domain in a customer tenant associated with the first IAM system and (ii) embedding an identity provider of the second IAM system within the domain; receiving, by the federated IAM system, a request from a user to perform an operation with respect to a resource associated with the second IAM system; and performing the request in response to the user being successfully authenticated by the federated IAM system.

[0009] Another aspect of the present disclosure provides a non-transitory computer-readable medium storing certain computer-executable instructions that, when executed by a processor, cause a computer system to perform a method, the method including generating a federated IAM system from a first identity and access management (IAM) system and a second IAM system, different from the first IAM system, by (i) creating a domain in a customer tenant associated with the first IAM system and (ii) embedding an identity provider of the second IAM system in the domain, the federated IAM system receiving a request from a user to perform an operation with respect to a resource associated with the second IAM system, and executing the request in response to the user being successfully authenticated by the federated IAM system.

[0010] According to one embodiment of the present disclosure, a computing device is provided having a processor and a memory having instructions stored thereon that, when executed on the processor, cause the computing device to generate a federated IAM system from at least a first identity and access management (IAM) system and a second IAM system different from the first IAM system by (i) creating a domain in a customer tenant associated with the first IAM system and (ii) embedding an identity provider of the second IAM system in the domain, receive by the federated IAM system a request from a user to perform an operation with respect to a resource associated with the second IAM system, and perform the request in response to the user being successfully authenticated by the federated IAM system.

[0011] The foregoing, together with other features and embodiments, will become more apparent with reference to the following specification, claims, and accompanying drawings. [Brief description of the drawings]

[0012] [Figure 1] FIG. 1 illustrates a block diagram showing an ID domain in accordance with various embodiments. [Diagram 2] FIG. 1 illustrates a block diagram illustrating an example customer tenant in accordance with various embodiments. [Diagram 3] FIG. 1 illustrates a block diagram illustrating the architecture of a unified identity management system according to some embodiments. [Figure 4A] FIG. 1 illustrates a flowchart illustrating a process for creating a unified identity management system according to some embodiments. [Figure 4B] FIG. 1 illustrates a flowchart illustrating a process for authorizing a user request by a unified identity management system according to some embodiments. [Diagram 5] FIG. 1 is a block diagram illustrating one pattern for implementing a cloud infrastructure as a service system, according to at least one embodiment. [Figure 6] FIG. 1 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. 1 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 another pattern for implementing a cloud infrastructure as a service system in accordance with at least one embodiment. [Figure 9] FIG. 1 is a block diagram illustrating an example computer system in accordance with at least one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] Detailed Description In the following description, various embodiments are described. For purposes of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the embodiments. However, it will be apparent to one skilled in the art that the embodiments may be practiced without the specific details. Furthermore, well-known features may be omitted or simplified in order not to obscure the described embodiments.

[0014] Introduction A Cloud Service Provider (CSP) may offer multiple cloud services to its subscribing customers. These services may be delivered in various models, such as Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS) models.

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

[0016] Resources protected by an IAM system can be of various types, such as computing instances, block storage volumes, virtual cloud networks (VCNs), subnets, route tables, various callable APIs, internal or legacy applications, etc. 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.

[0017] A CSP may provide two or more separate and independent IAM systems for its cloud offerings. This may be done, for example, where a first IAM system (e.g., OCI's Infrastructure Identity and Access Management) may be provided to control access to cloud resources for IaaS applications and services provided by the CSP. Separately, a second IAM system (e.g., Identity Cloud Services (IDCS), which may be different from the first system) may be provided for security and identity management for SaaS and PaaS services provided by the CSP.

[0018] By offering such two separate systems / platforms, when a CSP's customer subscribes to both SaaS or PaaS and IaaS services offered by the CSP, the customer typically has two separate accounts: one with OCI's IAM for IaaS subscriptions, and another with IDCS for PaaS / SaaS subscriptions. Each account has its own credentials, such as user login and / or password. Thus, the same customer has two separate sets of credentials for the two accounts. The result is a less than satisfactory customer experience. Moreover, having two separate identity management systems also creates obstacles for interactions between SaaS / PaaS and IaaS services.

[0019] For purposes of this application, and by way of example, the two exemplary platforms are referred to as IAM and IDCS, respectively. However, these names and terms are not intended to be limiting in any way. The teachings of this disclosure apply to any situation in which two (or more) different identity management systems are integrated. The identity management systems or platforms being integrated may be provided by one or more CSPs.

[0020] In certain embodiments, a unified IAM system is provided that integrates multiple identity and access management systems / platforms (e.g., IAM and IDCS platforms) in a manner that is transparent to users or customers of the cloud services, while retaining and providing various features and functionality provided by the two separate platforms. Thus, the integration provides a more seamless and enhanced user experience.

[0021] However, this integration is technically very challenging for several reasons. Two or more platforms may use different procedures and protocols to implement identity-related functions. For example, IAM may be an Attribute-Based Access Control (ABAC) system, also known as a Policy-Based Access Control system, that defines an access control paradigm, whereby access is granted to users using policies that represent 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 that do not have the "authorized" characteristics defined by the organization's security policy. On the other hand, IDCS may be a Role-Based Access Control (RBAC) system, a policy-neutral access control mechanism defined around roles and privileges. RBAC building blocks such as roles and privileges, users and roles, and role-role relationships make it easier to perform user assignments. Yet another reason is that the authentication and authorization frameworks or workflows used by the two platforms (e.g., types of tokens used, different authentication frameworks such as OAUTH) may be different. This is just one example of why providing an integrated solution is technically very challenging.

[0022] For simplicity and explanation, the first identity and access management system is considered herein to be an IAM system (providing access control for cloud resources such as IaaS applications), and the second identity and access management system is considered herein to be an IDCS system (providing security and identity management for services such as SaaS and PaaS). Typically, integration between two or more IAM systems is performed through a process called federation. For example, the first IAM system provides a native service (referred to herein as an identity provider service) that allows a user of the IAM system to federate with an external identity provider (IDP), e.g., IDCS. In operation, the user utilizes the native service (in the first identity and access management system, e.g., IAM) to perform a login operation at the external IDP, e.g., IDCS system. The external IDP generates a response, which is sent back to the IAM system. In other words, a certificate exchange is performed between the IAM and IDCS systems to validate the user. Once the user is validated, the IAM system generates a token that contains information about the IDP groups of which the user is a member. The token is used to perform a mapping operation that includes mapping an identifier of a user group in the external system to another identifier of a user group in the IAM system. As a result, the process of integrating two or more separate (independent) identity and access management systems is a cumbersome and resource-intensive process that leads to reduced user satisfaction.

[0023] In the following, a framework is provided for integrating two separate (independent) IAM systems in a seamless manner. As mentioned above, for ease of explanation, it is considered that the first IAM system corresponds to the OCI IAM system and the second IAM system corresponds to the IDCS system. However, it is understood that the framework for integrating two separate identity and access management systems is equally applicable to other types of identity management systems.

[0024] In an IAM system, when a customer (e.g., an organization) signs up for an account to utilize the services offered by the IAM system, a customer tenant is created. A tenant is defined herein as a secure and isolated division in the cloud infrastructure where a customer can create, organize, and manage cloud resources. A tenant may contain one or more compartments. Compartments allow a customer to organize and control access to its cloud resources. A compartment is a collection of related resources (e.g., instances, virtual cloud networks, block volumes, etc.) that can only be accessed by a specific group, for example, as allowed by an administrator. When a customer signs up for a cloud service, the CSP creates a customer tenant. This is the root compartment that holds all the customer's cloud resources. The customer can create additional compartments (root compartments) and corresponding policies within the tenant to control access to resources in each compartment. In contrast, in the IDCS system, the isolation unit of users and groups is referred to herein as a stripe. Specifically, a stripe is a container where a user or group of users can access its cloud resources.

[0025] According to some embodiments, in generating a federated IAM system from a first IAM system and a second IAM system (different from the first IAM system), resources are created in a customer tenant associated with the first IAM system. The resources are referred to herein as domains. As described later, domains provide a way for customers to directly manage their resources, such as IDCS stripes in an IDCS system, from within their tenant in the IAM system. A domain encompasses the full feature set of an IDCS stripe. Policies can be established in the IAM system to authorize access to resources with reference to IDCS stripe identities. To avoid the requirement to perform the federation process described above, embodiments of the present disclosure provide a technique to import identity providers (IDPs), for example, from an IDCS system, and provide the imported IDPs as resources in the customer tenant of the IAM system. It is understood that the above-described approach can be utilized in generating a federated identity and access management system from any two separate identity systems.

[0026] According to some embodiments, an identity domain (i.e., a domain that includes an embedded identity provider of the second IAM system) is incorporated into each customer tenant, and existing users and groups are moved to the identity domain. For example, users / groups included in Stripe in the IDCS system can be moved to an identity domain created in the customer's tenant associated with OCI IAM. Additionally, the customer can create additional domains (i.e., secondary domains); that is, the customer account is provisioned with a default domain and is provided with a public API to manage the additional domains. Thus, the customer account is no longer provisioned with IDCS federation (i.e., the customer account does not need to go through the federation process), and the customer exists as a single entity in the integrated IAM system.

[0027] In creating a unified IAM system, it provides user / group isolation at the domain level, which allows customers to isolate their users / groups. Specifically, the identity domain delivers a single unified identity that can be used across all cloud products of the CSP. Customers can reuse the same identity across different applications (e.g., IaaS, PaaS, and SaaS) and create simple yet powerful authorization controls to manage all cloud applications across the enterprise. In other words, customers get the full featured cloud identity provider capabilities for all their users and groups. Customers can also create multiple identity domains to manage and isolate their IaaS, PaaS, and SaaS users and implement disaster recovery systems.

[0028] FIG. 1 illustrates a block diagram illustrating an identity domain according to various embodiments. According to some embodiments, a federated identity and access management (IAM) system is generated from a first IAM system and a second IAM system. For example, an identity provider (and its associated functionality) associated with the second IAM system, e.g., an IDCS system, is embedded within the first IAM system to generate the federated IAM system. To generate the federated IAM system, resources are created within a customer tenant associated with the first IAM system. The created resources are referred to herein as domains. Further, the identity provider of the second IAM system is embedded within a domain created in the first IAM system. The domain that includes the embedded identity provider (of the second IAM system) is referred to herein as an identity domain. Thus, the federated IAM system provides an identity framework that can be used across both systems, i.e., the first IAM system and the second IAM system, without the need for the first IAM system to interface with the second IAM system.

[0029] As shown in FIG. 1, the customer tenant 101 associated with the first IAM system includes a default identity domain 102, a network source determiner 104, a default policy 103, and a compartment 105. According to some embodiments, the compartment 105 corresponds to a logical container instantiated to organize and control access to resources (e.g., compute, storage, network, load balancer) created in that compartment. In some embodiments, the compartment 105 includes a domain (i.e., resources) created to host an external identity provider. In other words, the identity provider of the second IAM system is embedded in the created domain to form the identity domain 106. Furthermore, the identity domain 106 is associated with a policy 107 that may include one or more rules governing access rights (of users included in the domain) to resources in the domain or resources included in the customer tenant. It should be noted that the components 108 included in the identity domain 106 represent an exemplary list of components that may be included in the identity domain 106. Each of these components will now be described in more detail.

[0030] According to some embodiments, each customer tenant 101 includes a default identity domain 102 that is provisioned when the customer tenant is created. Initially, upon creation of the customer tenant 101, the default identity domain 102 includes a group that includes a single user (e.g., the administrator who created the customer tenant). The default identity domain 102 is associated with a default policy 103. The default policy 103 grants the user (e.g., the administrator included in the default identity domain 102) full access to all resources within the customer tenant 101. It is understood that each of the default identity domain 102 and the default policy 103 may include other additional information regarding users, access rights, etc. Details of the other additional information are described below with reference to FIG. 2.

[0031] The customer tenant 101 includes a network source determiner 104. The network source determiner 104 is configured to qualify a source issuing a request directed to the customer tenant 101. In other words, the network source determiner 104 checks information related to the entity issuing the request (e.g., a user) and grants access to the user based on the information related to the user satisfying some conditions, e.g., the IP address of the request originates from a pre-determined set of IP addresses. It should be noted that a policy 107 included in a compartment of the customer tenant 101 can reference the network source determiner 104 when processing a request directed to the compartment 105.

[0032] As shown in Fig. 1, components 108 included in the identity domain include applications 111, authorization modules 112, user groups 113, users 114, application roles 115, dynamic groups 116, sign-in policies 117, identity providers 118, and sets of credentials 119. Components 108 are understood to belong to an identity provider (e.g., an Azure Active Directory instance or an Okta identity provider instance) of a second IAM system currently embedded within a domain in a customer tenant of a first IAM system. The identity provider 118 provisions the creation of users 114 or groups of users 113, management of user credentials 119, and authorizes users (or groups of users) to access resources of the cloud infrastructure.

[0033] According to some embodiments, an application 111, e.g., a web application, can be constructed and further registered with the identity domain 106. That is, the application 111 relies on the identity domain 106 for authorization and authentication requirements. The application 111 can include various application roles 115 (e.g., a first role with permission for only read operations, a second role with permission to modify aspects of the application) that can be maintained in the authorization module 112. Such roles can be monitored and assigned to different users for the application by the identity domain 106.

[0034] According to some embodiments, resources included in the cloud infrastructure may include resources such as computing instances, block storage volumes, virtual cloud networks (VCNs), subnets, and / or route tables. Each resource may be assigned unique credentials. Such credentials associated with a resource are referred to herein as resource principals or instance principals. Such groups of resource (or instance) principals are referred to herein as dynamic groups 116. It is understood that dynamic groups 116 provide grouping of resources as principal actors (e.g., based on some resource attribute matching policy) in a manner similar to grouping users into user groups. Dynamic groups 116 may be assigned to applications 111. In some embodiments, sign-in policies 117 may establish different sign-in rules for different users based on the user's location, i.e., the user's network source. For example, one sign-in rule may require a user to perform multi-factor authentication to access resources in a customer tenant based on the user's network source (e.g., IP address) from which the request to access the customer tenant originates.

[0035] In this manner, importing the identity provider of the second IAM system (e.g., IDCS) and embedding it within the domain of the customer tenant associated with the first IAM system provides a federated IAM system that can be used by both systems. Thus, rather than federating an IAM system (e.g., the first IAM system) with an identity provider of a different system (e.g., the second IAM system), aspects of the present disclosure provide a mechanism for creating a federated IAM system to avoid the previously required federation process, allowing a user to access resources provided by another system.

[0036] Referring now to FIG. 2, a block diagram illustrating an exemplary customer tenant according to various embodiments is shown. As shown in FIG. 2, customer tenant 200 includes a default identity domain 202, a default policy 203, a network source determiner 204, and multiple compartments, such as compartments 205, 215, and 225. The default identity domain 202 is provisioned when customer tenant 200 is created. Initially, upon creation of customer tenant 200, default identity domain 202 includes a group that includes a single user (e.g., an administrator who created the customer tenant). Default identity domain 202 is associated with default policy 203. Default policy 203 allows users (e.g., an administrator included in default identity domain 202) full access to all resources within customer tenant 101. As previously mentioned, the default identity domain (and default policy) may include additional information. For example, according to some embodiments, upon creation of customer tenant 200, one or more other users may be added to default identity domain 202. Similarly, various new policies can be included in the default policy 203 to allow users from other domains to access resources within the customer tenant.

[0037] According to some embodiments, the integrated IAM system provisions for creating separate domains within a customer tenant to manage the customer's users. For example, as shown in FIG. 2, customer tenant 200 includes multiple compartments, each compartment includes an identity domain and a policy associated therewith. For example, compartment 205 includes identity domain 206 and policy 207, while compartment 215 includes identity domain 216 and policy 217, and compartment 225 includes identity domain 226 and policy 227. Note that the configuration of compartments as shown in FIG. 2 is in no way limiting to the scope of the present disclosure. Rather, modifications to the configuration are well within the scope of the present disclosure. For example, a particular compartment (e.g., compartment 205) is not limited to having a single identity domain (i.e., identity domain 206) within that compartment. Rather, a compartment can include multiple identity domains. For example, two (or more) domains can be created within a compartment. Users in each of these domains may then have different access rights with respect to resources within those domains or other resources within customer tenant 200.

[0038] It will further be appreciated that each identity provider of the multiple identity providers with which the first IAM system interacts may be imported and provisioned as a resource having a domain (contained in a compartment) within the customer's tenant 200. In this manner, rather than the first IAM system integrating with different types of identity providers (IDPs), such as third-party IDPs, the various IDPs may be imported and provisioned as resources within the customer's tenant. In this manner, the first IAM system may avoid the need to individually integrate with different identity providers.

[0039] FIG. 3 illustrates a block diagram showing an architecture of a unified IAM system according to some embodiments. The unified IAM system architecture includes a control plane 310 and a data plane 320. The control plane 310 includes a first endpoint 303 associated with an IAM control plane 301 and a plurality of second endpoints 305 associated with an IDCS instance 302 (i.e., corresponding to domains created in a customer tenant). It is understood that the IAM control plane 301 includes a key-value database (e.g., KievDB), and the IDCS instance 302 is associated with a domain shard. The data plane 320 includes a load balancer 321, a plurality of data plane hosts 323, a routing layer 325, and a plurality of domain cache shards 327. The plurality of data plane hosts 323 include data plane hosts 323A, 323B, and 323C. Each data plane host is associated with a corresponding database (DB). The plurality of domain cache shards 327 include domain cache shards 327A, 327B, 327C, and 327D. It should be noted that the number of data plane hosts and the number of domain cache shards as shown in Figure 3 are for illustrative purposes only and are not intended to limit the scope of the present disclosure. The number of data plane hosts and domain cache shards may be more or less than those shown in Figure 3.

[0040] 3, information from KievDB and each of the domain shards is replicated in respective databases included in the data plane 320. According to some embodiments, information included in a domain shard (in the control plane) is replicated and stored in a domain cache shard in the data plane 320. Specifically, in one implementation, the user information included in a domain shard may be split into several portions, and each portion may be stored in a cache (i.e., a domain cache shard) in the data plane 320.

[0041] According to some embodiments, a first endpoint 303 associated with the IAM control plane 301 is configured to receive requests related to the creation of a new domain in a customer tenant. When a domain is created in a customer tenant, an endpoint of the newly constructed domain is added to a number of second endpoints 305. That is, each domain has a corresponding endpoint (one of the number of second endpoints 305) in the control plane 310. Requests related to operations to be performed on a domain are directed to the domain's corresponding second endpoint in the control plane 310.

[0042] According to some embodiments, when a request issued by a user is destined for a particular second endpoint, an attempt is first made to authorize the user issuing the request by the corresponding domain, i.e. domain 302. In particular, if the user issuing the request belongs to a group of users associated with the domain, the user may be authorized by the control plane 310, i.e. the corresponding domain 302 to which the user belongs. However, if the user issuing the request belongs to a group not included in the domain, i.e. the user belongs to another domain, the request is forwarded by the control plane 310 to the endpoint 307 associated with the data plane 320.

[0043] When a request is forwarded to the endpoint 307, the load balancer 321 of the data plane 320 selects one data plane host to process the request. It is understood that the load balancer 321 may select one of the data plane hosts (e.g., DP 323A) in such a manner that the traffic load (i.e., requests processed by the data plane 320) is evenly distributed among the data plane hosts. When processing a request forwarded by the control plane, the data plane host (e.g., DP 323A) communicates with the routing layer 325 to obtain necessary information about the user from one of the domain cache shards. According to some embodiments, the routing layer can maintain mapping information that maps users and cache IDs (corresponding to the domain cache shards where the user information is stored). In this manner, the data plane host cooperates with the routing layer 325 to obtain relevant user information (e.g., policies related to the user) to authorize the user. The architecture of the integrated IAM system further includes an IaaS service endpoint 333 configured to receive an authorization request for an IaaS service. It should be noted that such requests are directed to data plane 320 for authorization purposes. Additionally, PaaS application instance 331 (e.g., application 111 of FIG. 1 ) communicates with single sign-on module 329 for authorization / authentication purposes. Specifically, single sign-on module 329 obtains desired user information from one of the domain shards included in data plane 320 to authorize the user to utilize / start the application instance.

[0044] FIG. 4A illustrates a flowchart showing steps performed in generating a unified identity and access management (IAM) system according to some embodiments. The process illustrated in FIG. 4A may be implemented in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of the respective systems using hardware or a combination thereof. The software may be stored in a non-transitory storage medium (e.g., memory device). The method illustrated in FIG. 4A and described below is exemplary and not limiting. FIG. 4A illustrates various processing steps performed in a particular sequence or order, but is not limited thereto. In certain alternative embodiments, the process may be performed in some different order, or some steps may be performed in parallel. For purposes of explanation, the steps of the flowchart in FIG. 4A are described with reference to generating a unified IAM system from a first IAM (e.g., OCI's IAM) system and a second IAM system (e.g., IDCS).

[0045] The process begins at step 401, where a unified IAM system is generated from a first IAM system and a second IAM system. It is noted that the second IAM system is different from the first IAM system. The step involved in generating the unified IAM system includes two sub-steps, labeled 401A and 401B, respectively. At step 401A, a domain (i.e., resource) is created in a customer tenant associated with the first IAM system. Further, at step 401B, an identity provider of the second IAM system is embedded within the domain created at step 401A. Embedding the identity provider of the second IAM system in the domain (contained in the customer tenant) results in the creation of an identity domain (e.g., identity domain 106 of FIG. 1). Doing so provides an identity framework that can be used across both systems, i.e., the first IAM system and the second IAM system, without the first IAM system having to interface with the second IAM system.

[0046] The process then proceeds to step 403, where the federated IAM system receives a request from the user to perform an operation with respect to a resource associated with the second IAM system. According to some embodiments, the request may be a create, read, update, or delete (CRUD) operation. The process then proceeds to step 405, where the request is performed responsive to the user being successfully authenticated by the federated IAM system. That is, it is determined whether the user has sufficient privileges to perform the operation.

[0047] FIG. 4B shows a flow chart illustrating a process of authorizing a user request by a unified identity management system according to some embodiments. The process shown in FIG. 4B may be implemented in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of the respective systems using hardware or a combination thereof. The software may be stored in a non-transitory storage medium (e.g., memory device). The method shown in FIG. 4B and described below is exemplary and not limiting. FIG. 4B shows various processing steps performed in a particular sequence or order, but is not limited thereto. In certain alternative embodiments, the process may be performed in some different order, or some steps may be performed in parallel.

[0048] The process begins at step 451, where the unified IAM system receives a first request at a first endpoint in the control plane. The first request corresponds to a request issued by a user to create a new domain in a customer tenant. With reference to Figure 3, the first request may be received at endpoint 303. At step 453, a domain is created in the customer tenant according to the request.

[0049] In step 455, a second endpoint is created in the control plane for the domain created in step 453. Referring to Figure 3, a new endpoint (i.e., a second endpoint corresponding to the newly created domain) is created and added to the plurality of endpoints 305. In other words, each domain in the customer's tenant has a corresponding endpoint in the control plane, so that requests related to the domain are directed to the corresponding endpoint. Then, in step 457, a second request is received at the second endpoint.

[0050] In step 458, the domain corresponding to the second endpoint attempts to authorize the user who issued the second request. According to some embodiments, if the user who issued the second request belongs to a group of users included in the domain, the user may be authorized by the domain itself. However, if the user (issuing the second request) is outside the domain, the second request is forwarded to the data plane for authorization purposes. Further, in step 461, a determination is made as to whether the second request is successfully authorized. If the response is affirmative, the process proceeds to step 467, otherwise the process proceeds to step 459.

[0051] In step 459, the second request is forwarded to the data plane for authorization. Thereafter, in step 461, the data plane of the unified IAM system processes the second request. Specifically, referring to FIG. 3, one of the data plane hosts (e.g., data plane host 323A) communicates with the routing layer 325 to obtain (the user's) information from one of the domain cache shards (e.g., domain cache shards 327A-327D). Based on the information obtained from one of the domain cache shards, the data plane host evaluates the second request. Further, in step 467, the unified IAM system executes the second request in response to the user (issuing the second request) being successfully authorized.

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

[0053] In some cases, IaaS customers can 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 their application stack. For example, a user can log into an IaaS platform and 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 even install enterprise software on the VMs. The customer can then use the provider's services to perform a variety of functions such as balancing network traffic, troubleshooting application issues, monitoring performance, and managing disaster recovery.

[0054] In most cases, the cloud computing model requires the participation of a cloud provider, which may be, but does not have to be, a third-party service that specializes in providing (e.g., providing, renting, selling) IaaS. An entity may also choose to deploy a private cloud and become its own infrastructure service provider.

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

[0056] In some instances, IaaS provisioning may even refer to obtaining computers or virtual hosts for use and installing the necessary libraries or services on them. In most cases, deployment does not include provisioning, so provisioning may need to be performed first.

[0057] In some cases, there are two different problems with IaaS provisioning. First, there is the initial challenge of provisioning an initial set of infrastructure before anything can be done. Second, there is the challenge of evolving the existing infrastructure after everything has been provisioned (e.g. adding new services, modifying services, removing services). In some cases, these two challenges can be addressed by allowing the configuration of the infrastructure to be defined declaratively. In other words, the infrastructure (e.g. which components are needed and how they interact) can be defined by one or more configuration files. Thus, the overall topology of the infrastructure (e.g. which resources depend on which resources and how each works together, etc.) can be described declaratively. In some cases, once the topology is defined, workflows can be generated to create and / or manage the various components described in the configuration files.

[0058] 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 security group rules and one or more virtual machines (VMs) that are provisioned to define how the security of the network is configured. Other infrastructure elements such as load balancers, databases, etc. may also be provisioned. The infrastructure may evolve in stages as more infrastructure elements are desired or added.

[0059] In some cases, continuous deployment techniques may be used to enable deployment of infrastructure code across various virtual computing environments. Additionally, the described techniques enable infrastructure management within these environments. In some examples, a service team may write code that is desirable to deploy to one or more, but often many, different production environments (e.g., across various different geographic locations, possibly even across the globe). However, in some examples, the infrastructure to which the code will be deployed must first be set up. In some cases, provisioning may be done manually, and a provisioning tool may be utilized to provision resources and / or a deployment tool may be utilized to deploy the code after the infrastructure has been provisioned.

[0060] FIG. 5 is a block diagram 500 illustrating an example IaaS architecture pattern, according to at least one embodiment. A service operator 502 can be communicatively coupled to a secure host tenant 504, which can include a virtual cloud network (VCN) 506 and a secure host subnet 508. In some examples, the service operator 502 can use one or more client computing devices, which can be portable handheld devices (e.g., iPhone, mobile phone, 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, PalmOS, and Internet, email, short message service (SMS), Blackberry, or other communication protocols in effect. Alternatively, the client computing devices can be general purpose personal computers, including, for example, personal computers and / or laptop computers running various versions of Microsoft Windows, Apple Macintosh, and / or Linux operating systems. The client computing device may be a workstation computer 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 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 game console with or without a Kinect® gesture input device), and / or a personal messaging device capable of communicating over a network with access to the VCN 506 and / or the Internet.

[0061] The VCN 506 may include a local peering gateway (LPG) 510 that may be communicatively coupled to a secure shell (SSH) VCN 512 via an LPG 510 that is included in the SSH VCN 512. The SSH VCN 512 may include an SSH subnet 514, which may be communicatively coupled to a control plane VCN 516 via an LPG 510 that is included in the control plane VCN 516. The SSH VCN 512 may also be communicatively coupled to a data plane VCN 518 via the LPG 510. The control plane VCN 516 and the data plane VCN 518 may be included in a service tenant 519, which may be owned and / or operated by the IaaS provider.

[0062] The control plane VCN 516 may include a control plane demilitarized zone (DMZ) tier 520 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 may help prevent security breaches. Additionally, the DMZ tier 520 may include one or more load balancer (LB) subnets 522, a control plane app tier 524 that may include an app subnet 526, a control plane data tier 528 that may include a database (DB) subnet 530 (e.g., a front-end DB subnet and / or a back-end DB subnet). The LB subnet 522 included in the control plane DMZ tier 520 may be communicatively coupled to the app subnet 526 included in the control plane app tier 524 and an Internet gateway 534 that may be included in the control plane VCN 516, and the app subnet 526 may be communicatively coupled to the DB subnet 530 included in the control plane data tier 528, as well as a service gateway 536 and a network address translation (NAT) gateway 538. The control plane VCN 516 may include a service gateway 536 and a NAT gateway 538 .

[0063] The control plane VCN 516 can include a data plane mirrored app layer 540 that can include an app subnet 526. The app subnet 526 included in the data plane mirrored app layer 540 can include a virtual network interface controller (VNIC) 542 on which a compute instance 544 can run. The compute instance 544 can communicatively couple the app subnet 526 of the data plane mirrored app layer 540 to the app subnet 526 that can be included in the data plane app layer 546.

[0064] The data plane VCN 518 can include a data plane app layer 546, a data plane DMZ layer 548, and a data plane data layer 550. The data plane DMZ layer 548 can include a LB subnet 522, which can be communicatively coupled to an app subnet 526 of the data plane app layer 546 and an Internet gateway 534 of the data plane VCN 518. The app subnet 526 can be communicatively coupled to a service gateway 536 of the data plane VCN 518 and a NAT gateway 538 of the data plane VCN 518. The data plane data layer 550 can also include a DB subnet 530, which can be communicatively coupled to the app subnet 526 of the data plane app layer 546.

[0065] The internet gateways 534 of the control plane VCNs 516 and data plane VCNs 518 may be communicatively coupled to a metadata management service 552, which may be communicatively coupled to the public internet 554. The public internet 554 may be communicatively connected to NAT gateways 538 of the control plane VCNs 516 and data plane VCNs 518. The service gateways 536 of the control plane VCNs 516 and data plane VCNs 518 may be communicatively coupled to cloud services 556.

[0066] In some examples, a service gateway 536 in the control plane VCN 516 or the data plane VCN 518 can make application programming interface (API) calls to a cloud service 556 without traversing the public Internet 554. An API call from a service gateway 536 to a cloud service 556 can be one-way: the service gateway 536 can make an API call to the cloud service 556, and the cloud service 556 can send the requested data to the service gateway 536. However, the cloud service 556 may not be able to initiate an API call to the service gateway 536.

[0067] In some examples, the secure host tenant 504 can be directly connected to the service tenant 519 or can be otherwise separate. The secure host subnet 508 can communicate with the SSH subnet 514 through the LPG 510, which can allow bidirectional communication through otherwise separate systems. Connecting the secure host subnet 508 to the SSH subnet 514 can give the secure host subnet 508 access to other entities in the service tenant 519.

[0068] The control plane VCN 516 can enable users of a service tenant 519 to set up or provision desired resources. The desired resources provisioned in the control plane VCN 516 can be deployed or used in the data plane VCN 518. In some examples, the control plane VCN 516 can be separate from the data plane VCN 518, and the data plane mirror app layer 540 of the control plane VCN 516 can communicate with the data plane app layer 546 of the data plane VCN 518 via a VNIC 542, which can be included in the data plane mirror app layer 540 and the data plane app layer 546.

[0069] In some examples, a user or customer of the system may make a request, such as, for example, a create, read, update, or delete (CRUD) operation, via the public internet 554, which may communicate the request to a metadata management service 552. The metadata management service 552 may communicate the request to the control plane VCN 516 via an internet gateway 534. The request may be received by a LB subnet 522 included in the control plane DMZ layer 520. The LB subnet 522 may determine that the request is valid, and in response to this determination, the LB subnet 522 may send the request to an app subnet 526 included in the control plane app layer 524. If the request is validated and a call to the public internet 554 is required, the call to the public internet 554 may be sent to a NAT gateway 538, which may make the call to the public internet 554. Memory that may be desirable to be stored with the request may be stored in the DB subnet 530.

[0070] In some examples, the data plane mirror app layer 540 can facilitate direct communication between the control plane VCN 516 and the data plane VCN 518. For example, it may be desirable to apply configuration changes, updates, or other suitable modifications to resources included in the data plane VCN 518. Through the VNIC 542, the control plane VCN 516 can communicate directly with the resources included in the data plane VCN 518, thereby enabling it to perform configuration changes, updates, or other suitable modifications to the resources included in the data plane VCN 518.

[0071] In some embodiments, the control plane VCN 516 and the data plane VCN 518 can be included in the service tenant 519. In this case, a user or customer of the system may not own or operate either the control plane VCN 516 or the data plane VCN 518. Instead, an IaaS provider may own or operate the control plane VCN 516 and the data plane VCN 518, both of which may be included in the service tenant 519. This embodiment may allow for network isolation that may prevent a user or customer from interacting with the resources of other users or other customers. This embodiment also allows a user or customer of the system to store databases privately without having to rely on the public Internet 654, which may not have the desired level of security for storage.

[0072] In another embodiment, the LB subnet 522 included in the control plane VCN 516 may be configured to receive signals from the service gateway 536. In this embodiment, the control plane VCN 516 and the data plane VCN 518 may be configured to be called by the IaaS provider's customers without calling the public Internet 554. The IaaS provider's customers may desire this embodiment because databases used by the customers may be stored in the service tenant 519, which may be controlled by the IaaS provider and isolated from the public Internet 554.

[0073] 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 502 of FIG. 5 ) can be communicatively coupled to a secure host tenant 604 (e.g., secure host tenant 504 of FIG. 5 ), which can include a virtual cloud network (VCN) 606 (e.g., VCN 506 of FIG. 5 ) and a secure host subnet 608 (e.g., secure host subnet 508 of FIG. 5 ). The VCN 606 can include a local peering gateway (LPG) 610 (e.g., LPG 510 of FIG. 5 ), which can be communicatively coupled to a secure shell (SSH) VCN 612 (e.g., SSH VCN 512 of FIG. 5 ) via the LPG 510 included in the SSH VCN 612. SSH VCN 612 can include an SSH subnet 614 (e.g., SSH subnet 514 in FIG. 5), which can be communicatively coupled to a control plane VCN 616 (e.g., control plane VCN 516 in FIG. 5) via an LPG 610 included in the control plane VCN 616. The control plane VCN 616 can be included in a service tenant 619 (e.g., service tenant 519 in FIG. 5), and the data plane VCN 618 (e.g., data plane VCN 518 in FIG. 5) can be included in a customer tenant 621, which can be owned or operated by a user or customer of the system.

[0074] The control plane VCN 616 may include a control plane DMZ layer 620 (e.g., control plane DMZ layer 520 of FIG. 5 ) that may include a LB subnet 622 (e.g., LB subnet 522 of FIG. 5 ), a control plane app layer 624 (e.g., control plane app layer 524 of FIG. 5 ) that may include an app subnet 626 (e.g., app subnet 526 of FIG. 5 ), and a control plane data layer 628 (e.g., control plane data layer 528 of FIG. 5 ) that may include a database (DB) subnet 630 (e.g., similar to DB subnet 530 of FIG. 5 ). The LB subnet 622 included in the control plane DMZ layer 620 can be communicatively coupled to an app subnet 626 included in the control plane app layer 624 and to an Internet gateway 634 (e.g., Internet gateway 534 in FIG. 5 ) that may be included in the control plane VCN 616, and the app subnet 626 can be communicatively coupled to a DB subnet 630 included in the control plane data layer 628, as well as a service gateway 636 (e.g., service gateway in FIG. 5 ) and a network address translation (NAT) gateway 638 (e.g., NAT gateway 538 in FIG. 5 ). The control plane VCN 616 can include the service gateway 636 and the NAT gateway 638.

[0075] The control plane VCN 616 can include a data plane mirror app layer 640 (e.g., data plane mirror app layer 540 of FIG. 5 ), which can include an app subnet 626. The app subnet 626 included in the data plane mirror app layer 640 can include a virtual network interface controller (VNIC) 642 (e.g., VNIC 542) on which a computing instance 644 (e.g., similar to the computing instance 544 of FIG. 5 ) can run. The computing instance 644 can facilitate communication between the app subnet 626 and the app subnet 626 of the data plane mirror app layer 640, which can be included in the data plane app layer 646 (e.g., data plane app layer 546 of FIG. 5 ), via the VNIC 642 included in the data plane mirror app layer 640 and the VNIC 642 included in the data plane app layer 646.

[0076] An Internet gateway 634 included in the control plane VCN 616 can be communicatively coupled to a metadata management service 652 (e.g., metadata management service 552 in FIG. 5), which can be communicatively coupled to a public Internet 654 (e.g., public Internet 554 in FIG. 5). The public Internet 654 can be communicatively coupled to a NAT gateway 638 included in the control plane VCN 616. A service gateway 636 included in the control plane VCN 616 can be communicatively coupled to cloud services 656 (e.g., cloud services 556 in FIG. 5).

[0077] In some examples, the data plane VCN 618 can be included in a customer tenant 621. In this case, the IaaS provider can provide a control plane VCN 616 for each customer, and the IaaS provider can set up a unique compute instance 644 included in a service tenant 619 for each customer. Each compute instance 644 may enable communication between the control plane VCN 616 included in the service tenant 619 and the data plane VCN 618 included in the customer tenant 621. The compute instance 644 may enable resources provisioned in the control plane VCN 616 included in the service tenant 619 to be deployed or otherwise used in the data plane VCN 618 included in the customer tenant 621.

[0078] In another example, a customer of the IaaS provider may have a database that resides in a customer tenant 621. In this example, the control plane VCN 616 may include a data plane mirror app layer 640, which may include an app subnet 626. The data plane mirror app layer 640 may reside in the data plane VCN 618, but the data plane mirror app layer 640 may not reside in the data plane VCN 618. That is, the data plane mirror app layer 640 is accessible to the customer tenant 621, but the data plane mirror app layer 640 may not reside in the data plane VCN 618 or may be owned or operated by the customer of the IaaS provider. The data plane mirror app layer 640 may be configured to make calls to the data plane VCN 618, but may not be configured to make calls to any entities included in the control plane VCN 616. A customer may wish to deploy or otherwise use resources in the data plane VCN 618 that are provisioned in the control plane VCN 616, and the data plane mirror app layer 640 may facilitate the customer's desired deployment or other use of the resources.

[0079] In some embodiments, the IaaS provider's customer can apply filters to the data plane VCN 618. In this embodiment, the customer can determine what the data plane VCN 618 can access, and the customer can limit access from the data plane VCN 618 to the public Internet 654. The IaaS provider may not be able to apply filters or control the data plane VCN 618's access to external networks or databases. Applying customer filters and controls to the data plane VCN 618 contained in a customer tenant 621 can help isolate the data plane VCN 618 from other customers and the public Internet 654.

[0080] In some embodiments, cloud services 656 may be called by the service gateway 636 to access services that may not be on the public Internet 654, on the control plane VCN 616, or on the data plane VCN 618. The connection between the cloud services 656 and the control plane VCN 616 or the data plane VCN 618 may not be live or continuous. The cloud services 656 may be on another network owned or operated by the IaaS provider. The cloud services 656 may be configured to receive calls from the service gateway 636 or may be configured not to receive calls from the public Internet 654. Some cloud services 656 may be isolated from other cloud services 656, and the control plane VCN 616 may be isolated from cloud services 656 that may not be in the same region as the control plane VCN 616. For example, the control plane VCN 616 may be located in “Region 1” and the cloud service “Deployment 6” may be located in Region 1 and Region 2. If a call to deployment 6 is made by a service gateway 636 included in control plane VCN 616 in region 1, the call may be sent to deployment 6 in region 1. In this example, control plane VCN 616, or deployment 6 in region 1, may not be communicatively coupled to or in communication with deployment 6 in region 2.

[0081] 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 502 of FIG. 5 ) can be communicatively coupled to a secure host tenant 704 (e.g., secure host tenant 504 of FIG. 5 ), which can include a virtual cloud network (VCN) 706 (e.g., VCN 506 of FIG. 5 ) and a secure host subnet 708 (e.g., secure host subnet 508 of FIG. 5 ). The VCN 706 can include an LPG 710 (e.g., LPG 510 of FIG. 5 ) that can be communicatively coupled to an SSH VCN 712 via an LPG 710 included in the SSH VCN 712 (e.g., SSH VCN 512 of FIG. 5 ). SSH VCN 712 can include an SSH subnet 714 (e.g., SSH subnet 514 of FIG. 5), which can be communicatively coupled to a control plane VCN 716 via an LPG 710 included in the control plane VCN 716 (e.g., control plane VCN 516 of FIG. 5) and to a data plane VCN 718 via an LPG 710 included in the data plane VCN 718 (e.g., data plane 518 of FIG. 5). The control plane VCN 716 and the data plane VCN 718 can be included in a service tenant 719 (e.g., service tenant 519 of FIG. 5).

[0082] The control plane VCN 716 may include a control plane DMZ tier 720 (e.g., control plane DMZ tier 520 of FIG. 5 ) that may include a load balancer (LB) subnet 722 (e.g., LB subnet 522 of FIG. 5 ), a control plane app tier 724 (e.g., control plane app tier 524 of FIG. 5 ) that may include an app subnet 726 (e.g., similar to app subnet 526 of FIG. 5 ), and a control plane data tier 728 (e.g., control plane data tier 528 of FIG. 5 ) that may include a DB subnet 730. The LB subnet 722 included in the control plane DMZ layer 720 may be communicatively coupled to an app subnet 726 included in the control plane app layer 724 and an Internet gateway 734 (e.g., Internet gateway 534 in FIG. 5 ) that may be included in the control plane VCN 716, and the app subnet 726 can be communicatively coupled to a DB subnet 730, a service gateway 736 (e.g., service gateway in FIG. 5 ), and a network address translation (NAT) gateway 738 (e.g., NAT gateway 538 in FIG. 5 ) included in the control plane data layer 728. The control plane VCN 716 may include the service gateway 736 and the NAT gateway 738.

[0083] The data plane VCN 718 may include a data plane app layer 746 (e.g., data plane app layer 546 of FIG. 5), a data plane DMZ layer 748 (e.g., data plane DMZ layer 548 of FIG. 5), and a data plane data layer 750 (e.g., data plane data layer 550 of FIG. 5). The data plane DMZ layer 748 may include a LB subnet 722, which may be communicatively coupled to a trusted app subnet 760 and an untrusted app subnet 762 of the data plane app layer 746 and an Internet gateway 734 included in the data plane VCN 718. The trusted app subnet 760 may be communicatively coupled to a service gateway 736 included in the data plane VCN 718, a NAT gateway 738 included in the data plane VCN 718, and a DB subnet 730 included in the data plane data layer 750. The untrusted app subnet 762 may be communicatively coupled to the service gateway 736 included in the data plane VCN 718 and the DB subnet 730 included in 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 included in the data plane VCN 718 .

[0084] The untrusted app subnet 762 may include one or more primary VNICs 764(1)-(N) that may be communicatively coupled to tenant virtual machines (VMs) 766(1)-(N). Each tenant VM 766(1)-(N) may be communicatively coupled to a respective app subnet 767(1)-(N), which may be included in a respective container egress VCN 768(1)-(N), which may be included in a respective customer tenant 770(1)-(N). Each secondary VNIC 772(1)-(N) may facilitate communication between the untrusted app subnet 762 included in the data plane VCN 718 and the app subnet included in the container egress VCN 768(1)-(N). Each container egress VCN 768(1)-(N) may include a NAT gateway 738 that may be communicatively coupled to the public Internet 754 (e.g., public Internet 554 of FIG. 5).

[0085] The Internet gateway 734 included in the control plane VCN 716 and included in the data plane VCN 718 can be communicatively coupled to a metadata management service 752 (e.g., metadata management system 552 of FIG. 5 ), which can be communicatively coupled to the public Internet 754. The public Internet 754 can be communicatively coupled to a NAT gateway 738 included in the control plane VCN 716 and included in the data plane VCN 718. The service gateway 736 included in the control plane VCN 716 and included in the data plane VCN 718 can be communicatively coupled to cloud services 756.

[0086] In some embodiments, the data plane VCN 718 can be integrated with a customer tenant 770. This integration can be beneficial or desirable for an IaaS provider's customer, such as when support is needed when running code. A customer may provide code for execution that may be disruptive, communicate with other customer resources, or cause other undesirable effects. In response, the IaaS provider can decide whether to run code provided to the IaaS provider by the customer.

[0087] In some examples, an IaaS provider's customer may grant the IaaS provider temporary network access to request functionality to be added to data plane layer app 746. The code to execute the functionality may be executed in VMs 766(1)-(N), and the code may not be configured to execute elsewhere on data plane VCN 718. Each VM 766(1)-(N) may be connected to one customer tenant 770. Each container 771(1)-(N) contained in VM 766(1)-(N) may be configured to execute code. In this case, double isolation may exist (e.g., code execution in container 771(1)-(N), container 771(1)-(N) may be contained in at least VMs 766(1)-(N) contained in untrusted app subnet 762), which may help prevent errant or unwanted code from damaging the IaaS provider's network or damaging another customer's network. Containers 771(1)-(N) may be communicatively coupled to customer tenants 770 and may be configured to send or receive data from customer tenants 770. Containers 771(1)-(N) may not be configured to send or receive data from any other entities in data plane VCN 718. Once code execution is complete, the IaaS provider may kill or otherwise destroy containers 771(1)-(N).

[0088] In some embodiments, trusted app subnet 760 may execute code that may be owned or operated by the IaaS provider. In this embodiment, trusted app subnet 760 may be communicatively coupled to DB subnet 730 and configured to perform CRUD operations within DB subnet 730. Untrusted app subnet 762 may be communicatively coupled to DB subnet 730, but in this embodiment, the untrusted app subnet may be configured to perform read operations in DB subnet 730. Containers 771(1)-(N) that may be included in each customer's VMs 766(1)-(N) and that may execute code from the customer may not be communicatively coupled to DB subnet 730.

[0089] In other embodiments, the control plane VCN 716 and the data plane VCN 718 may not be directly communicatively coupled. In this embodiment, there may not be direct communication between the control plane VCN 716 and the data plane VCN 718. However, communication may occur indirectly through at least one method. The LPG 710 may be established by an IaaS provider that may facilitate communication between the control plane VCN 716 and the data plane VCN 718. In another example, the control plane VCN 716 or the data plane VCN 718 may make a call to a cloud service 756 through a service gateway 736. For example, a call from the control plane VCN 716 to the cloud service 756 may include a request for a service that may communicate with the data plane VCN 718.

[0090] 8 is a block diagram 800 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 802 (e.g., service operator 502 of FIG. 5 ) can be communicatively coupled to a secure host tenant 804 (e.g., secure host tenant 504 of FIG. 5 ), which can include a virtual cloud network (VCN) 806 (e.g., VCN 506 of FIG. 5 ) and a secure host subnet 808 (e.g., secure host subnet 508 of FIG. 5 ). VCN 806 can include an LPG 810 (e.g., LPG 510 of FIG. 5 ) that can be communicatively coupled to an SSH VCN 812 (e.g., SSH VCN 512 of FIG. 5 ) via an LPG 810 included in the SSH VCN 812. SSH VCN 812 can include an SSH subnet 814 (e.g., SSH subnet 514 in FIG. 5), which can be communicatively coupled to a control plane VCN 816 via an LPG 810 included in the control plane VCN 816 (e.g., control plane VCN 516 in FIG. 5) and can be communicatively coupled to a data plane VCN 818 via an LPG 810 included in the data plane VCN 818 (e.g., data plane 518 in FIG. 5). The control plane VCN 816 and the data plane VCN 818 can be included in a service tenant 819 (e.g., service tenant 519 in FIG. 5).

[0091] The control plane VCN 816 may include a control plane DMZ layer 820 (e.g., control plane DMZ layer 520 of FIG. 5) that may include a LB subnet 822 (e.g., LB subnet 522 of FIG. 5), a control plane app layer 824 (e.g., control plane app layer 524 of FIG. 5) that may include an app subnet 826 (e.g., app subnet 526 of FIG. 5), and a control plane data layer 828 (e.g., control plane data layer 528 of FIG. 5) that may include a DB subnet 830 (e.g., DB subnet 730 of FIG. 7). The LB subnet 822 included in the control plane DMZ layer 820 may be communicatively coupled to an app subnet 826 included in the control plane app layer 824 and may be communicatively coupled to an Internet gateway 834 (e.g., Internet gateway 534 of FIG. 5 ) that may be included in the control plane VCN 816, which may be communicatively coupled to a DB subnet 830 included in the control plane data layer 828 and may be communicatively coupled to a service gateway 836 (e.g., service gateway of FIG. 5 ) and a network address translation (NAT) gateway 838 (e.g., NAT gateway 538 of FIG. 5 ). The control plane VCN 816 may include the service gateway 836 and the NAT gateway 838.

[0092] The data plane VCN 818 may include a data plane app layer 846 (e.g., data plane app layer 546 in FIG. 5), a data plane DMZ layer 848 (e.g., data plane DMZ layer 548 in FIG. 5), and a data plane data layer 850 (e.g., data plane data layer 550 in FIG. 5). The data plane DMZ layer 848 may include a LB subnet 822, which may be communicatively coupled to a trusted app subnet 860 (e.g., trusted app subnet 760 in FIG. 7), and may be communicatively coupled to an untrusted app subnet 862 (e.g., untrusted app subnet 762 in FIG. 7) of the data plane app layer 846 and an Internet gateway 834 included in the data plane VCN 818. The trusted app subnet 860 may be communicatively coupled to a service gateway 836 included in the data plane VCN 818, and may be communicatively coupled to a NAT gateway 838 included in the data plane VCN 818, and a DB subnet 830 included in the data plane data layer 850. The untrusted app subnet 862 can be communicatively connected to a service gateway 836 included in the data plane VCN 818 and a DB subnet 830 included in the data plane data layer 850. The data plane data layer 850 can include a DB subnet 830 that can be communicatively coupled to a service gateway 836 included in the data plane VCN 818.

[0093] The untrusted app subnet 862 can include primary VNICs 864(1)-(N), which can be communicatively coupled to tenant virtual machines (VMs) 866(1)-(N) that reside in the untrusted app subnet 862. Each tenant VM 866(1)-(N) can execute code within a respective container 867(1)-(N), which can be communicatively coupled to an app subnet 826 that can be included in a data plane app layer 846 that can be included in a container egress VCN 868. Each secondary VNIC 872(1)-(N) can facilitate communication between the untrusted app subnet 862 included in the data plane VCN 818 and the app subnet included in the container egress VCN 868. The container egress VCN can include a NAT gateway 838 that can be communicatively coupled to the public Internet 854 (e.g., public Internet 554 in FIG. 5 ).

[0094] An Internet gateway 834 included in the control plane VCN 816 and in the data plane VCN 818 can be communicatively coupled to a metadata management service 852 (e.g., metadata management system 552 of FIG. 5 ), which can be communicatively coupled to the public Internet 854. The public Internet 854 can be communicatively coupled to a NAT gateway 838 included in the control plane VCN 816 and in the data plane VCN 818. A service gateway 836 included in the control plane VCN 816 and in the data plane VCN 818 can be communicatively coupled to cloud services 856.

[0095] In some examples, the pattern illustrated by the architecture of block diagram 800 of FIG. 8 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., in a disconnected area). Each container 867(1)-(N) contained in each customer's VM 866(1)-(N) is accessible in real time by the customer. The containers 867(1)-(N) may be configured to make calls to a respective secondary VNIC 872(1)-(N) contained in an app subnet 826 of a data plane app layer 846 that may be contained in a container egress VCN 868. The secondary VNIC 872(1)-(N) may send the call to a NAT gateway 838 that may send the call to the public Internet 854. In this example, the containers 867(1)-(N) that are accessible in real time by the customer may be isolated from the control plane VCN 816 and may be isolated from other entities contained in the data plane VCN 818. Containers 867(1)-(N) may be isolated from resources from other customers.

[0096] In another example, a customer can use container 867(1)-(N) to invoke cloud service 856. In this example, the customer can execute code within container 867(1)-(N) that requests a service from cloud service 856. Container 867(1)-(N) can send the request to secondary VNIC 872(1)-(N), which can send the request to a NAT gateway that can send the request to public internet 854. Public internet 854 can send the request via internet gateway 834 to LB subnet 822 included in control plane VCN 816. In response to determining that the request is valid, the LB subnet can send the request to app subnet 826, which can send the request to cloud service 856 via service gateway 836.

[0097] It should be understood that the IaaS architectures 500, 600, 700, 800 depicted in the figures may have components other than those depicted. Additionally, the embodiments depicted in the figures are only some examples of cloud infrastructure systems that may incorporate embodiments of the present disclosure. In other embodiments, the IaaS systems may have more or fewer components than depicted, may combine two or more components, or may have different configurations or arrangements of components.

[0098] In certain embodiments, the IaaS system described herein may include a suite of application, middleware, and database services products 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.

[0099] 9 illustrates an exemplary computer system 900 in which various embodiments may be implemented. System 900 may be used to implement any of the computer systems described above. As shown, computer system 900 includes a processing unit 904 that communicates with a number of peripheral subsystems via a bus subsystem 902. These peripheral subsystems may include a processing accelerator 906, an I / O subsystem 908, a storage subsystem 918, and a communication subsystem 924. The storage subsystem 918 includes a tangible computer-readable storage medium 922 and a system memory 910.

[0100] Bus subsystem 902 provides a mechanism that allows the various components and subsystems of computer system 900 to communicate with each other as intended. Although bus subsystem 902 is shown diagrammatically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. Bus subsystem 902 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 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 Peripheral Component InterConnect (PCI) bus. It may be implemented as a mezzanine bus manufactured in accordance with the IEEE P1386.1 standard.

[0101] Processing unit 904 may be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers) and controls the operation of computer system 900. One or more processors may be included in processing unit 904. These processors may include single-core processors or multi-core processors. In particular embodiments, processing unit 904 may be implemented as one or more independent processing units 932 and / or 934 with a single-core processor or a multi-core processor included in each processing unit. In other embodiments, processing unit 904 may be implemented as a quad-core processing unit formed by integrating two dual-core processors into a single chip.

[0102] In various embodiments, the processing unit 904 may execute various programs in response to program code and may maintain multiple simultaneously executing programs or processes. At any time, some or all of the program code being executed may reside in the processor 904 and / or in the memory subsystem 918. Through appropriate programming, the processor 904 may provide the various functions discussed above. The computer system 900 may further include a processing accelerator 906, which may include a digital signal processor (DSP), special purpose processor, or the like.

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

[0104] User interface input devices may 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 video cameras, portable media players, webcams, image scanners, fingerprint scanners, barcode readers 3D scanners, 3D printers, laser range finders, and eye-tracking devices. Additionally, user interface input devices may include medical imaging input devices such as, for example, computed tomography, magnetic resonance imaging, position emission tomography, and medical ultrasound machines. User interface input devices may also include audio input devices such as, for example, MIDI keyboards, digital musical instruments, and the like.

[0105] User interface output devices may include non-visual displays such as a display subsystem, indicator lights, or audio output devices. The display subsystem may be a flat panel device such as one using a cathode ray tube (CRT), liquid crystal display (LCD) or plasma display, a projection device, a touch screen, etc. 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 900 to a user or to another computer. For example, user interface output devices include, but are not limited to, various display devices that visually convey text, graphics, and audio / video information, such as monitors, printers, speakers, headphones, automobile navigation systems, plotters, voice output devices, and modems.

[0106] Computer system 900 may include a storage subsystem 918 that comprises software elements shown as currently located in system memory 910. System memory 910 may store program instructions that are loadable and executable on processing unit 904, as well as data generated during the execution of these programs.

[0107] Depending on the configuration and type of computer system 900, the system memory 910 may be volatile (such as random access memory (RAM)) and / or non-volatile (such as read only memory (ROM), flash memory). RAM typically contains data and / or program modules that are immediately accessible to and / or currently being operated on and executed by the processing unit 904. In some implementations, the system memory 910 may include a number of different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM). In some implementations, a basic input / output system (BIOS), containing the basic routines that help to transfer information between elements within the computer system 900, such as during start-up, may typically be stored in ROM. By way of example and not limitation, the system memory 910 also illustrates application programs 912, program data 914, and an operating system 916, which may include client applications, a web browser, a mid-tier application, a relational database management system (RDBMS), and the like. By way of example, operating systems 916 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, etc.), and / or mobile operating systems such as iOS, Windows® Phone, Android® OS, BlackBerry® 10 OS, and Palm® OS operating systems.

[0108] The storage subsystem 918 may also provide a tangible computer-readable storage medium for storing the basic programming and data constructs that provide the functionality of some embodiments. Software (programs, code modules, instructions) that, when executed by the processor, provide the functionality described above may be stored in the storage subsystem 918. These software modules or instructions may be executed by the processing unit 904. The storage subsystem 918 may also provide a repository for storing data used in accordance with the present disclosure.

[0109] Storage subsystem 900 may also include a computer readable storage medium reader 920 that can be further connected to a computer readable storage medium 922. Together, and optionally in combination with system memory 910, computer readable storage medium 922 can comprehensively represent remote, local, fixed, and / or removable storage devices, as well as storage media for containing, storing, transmitting, and retrieving computer readable information on a temporary and / or more permanent basis.

[0110] The computer readable storage medium 922 containing the code or portions of code may include any suitable medium known or used in the art, including, but not limited to, storage media and communication media, such as volatile and non-volatile, removable and non-removable media implemented in any manner or technology for storing and / or transmitting 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 device, magnetic cassette, magnetic tape, magnetic disk storage device or other magnetic storage device, or other tangible computer readable medium. This may also include intangible computer readable media, such as a data signal, data transmission, or any other medium that can be used to transmit the desired information and that can be accessed by the computing system 900.

[0111] As an example, the computer readable storage medium 922 may include hard disk drives that read or write to non-removable non-volatile magnetic media, magnetic disk drives that read or write to removable non-volatile magnetic disks, and optical disk drives that read or write to removable non-volatile optical disks such as CD-ROMs, DVDs, Blu-Ray® disks, or other optical media. The computer readable storage medium 922 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 tapes, and the like. The computer readable storage medium 922 may also include solid state drives (SSDs) based on non-volatile memory such as flash memory-based SSDs, enterprise flash drives, SSDs based on volatile memory such as solid state RAM, dynamic RAM, static RAM, such as solid state ROM, DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, and hybrid SSDs that use a combination of DRAM and flash memory-based SSDs. The 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 computer system 900.

[0112] The communications subsystem 924 provides an interface to other computer systems and networks. The communications subsystem 924 serves as an interface for transmitting and receiving data from the computer system 900 to and from other systems. For example, the communications subsystem 924 may enable the computer system 1000 to connect to one or more devices via the Internet. In some embodiments, the communications subsystem 924 may include radio frequency (RF) transceiver components for accessing wireless voice and / or data networks (e.g., using cellular technology, advanced data network technologies such as 3G, 4G, or EDGE (Enhanced Data Rates for Global Evolution)), WiFi (IEEE 802.11 family standard, or other mobile communications technologies, or any combination thereof), global positioning system (GPS) receiver components, and / or other components. In some embodiments, the communications subsystem 924 may provide a wired network connection (e.g., Ethernet) in addition to or instead of a wireless interface.

[0113] In some embodiments, the communications subsystem 924 may also receive incoming communications in the form of structured and / or unstructured data feeds 926, event streams 928, event updates 930, etc., on behalf of one or more users who may use the computer system 900.

[0114] As an example, the communications subsystem 924 may be configured to receive data feeds 926 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 information sources.

[0115] Additionally, the communications subsystem 924 may be configured to receive data in the form of a continuous data stream, which may include an event stream 928 of real-time events and / or event updates 930, which may be continuous or essentially unlimited with no apparent end. Examples of applications that generate continuous data may include, for example, sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, and the like.

[0116] The communications subsystem 924 may also be configured to output structured and / or unstructured data feeds 926, event streams 928, event updates 930, etc. to one or more databases that may be in communication with one or more streaming data source computers coupled to the computer system 900.

[0117] The computer system 900 may be one of a variety of types, including a handheld portable device (e.g., an iPhone® mobile 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 other data processing system.

[0118] Due to the ever-changing nature of computers and networks, the description of the computer system 900 shown in the figure is intended only as a specific example. Many other configurations are possible, with more or fewer components than the system shown in the figure. For example, customized hardware may also be used, or particular elements may be implemented in hardware, firmware, software (including applets), or a combination thereof. Additionally, connections to other computing devices, such as network input / output devices, may be used. Based on the disclosure and teachings provided herein, one of ordinary skill in the art will appreciate other approaches and / or methods for implementing various embodiments. Although specific embodiments have been described, various modifications, variations, alternative constructions, and equivalents are within the scope of the disclosure. The embodiments are not limited to operating in any particular data processing environment, but may freely operate in multiple data processing environments. Furthermore, while the embodiments have been described using a particular sequence of transactions and steps, it will be apparent to those skilled in the art that the scope of the 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 in combination.

[0119] Furthermore, while 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 using only hardware, only software, or a combination thereof. The various processes described herein may be implemented on the same processor or any combination of different processors. Thus, where a component or module is described as being configured to perform a particular operation, such configuration may be achieved, for example, by designing electronic circuitry 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, with different pairs of processes using different techniques and the same pair of processes using different techniques at different times.

[0120] Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. It will be apparent, however, that additions, subtractions, deletions, and other modifications and alterations may be made without departing from the broader spirit and scope of the appended claims. Accordingly, although certain disclosed embodiments have been described, they are not intended to be limiting. Various modifications and equivalents are intended to be within the scope of the following claims.

[0121] Use of the terms "a," "an," "the," and similar referents in the context of describing the disclosed embodiments (particularly in the context of the claims that follow) should be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. The terms "comprise," "have," "include," and "contain" 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 being partially or wholly contained within, attached to, or connected to, even if there is something intervening. The recitation of ranges of values ​​herein is merely intended to serve as a shorthand method of individually referring to each individual value falling within the range, unless otherwise stated herein, and each individual value is incorporated into the specification as if it were individually set forth herein. All methods described herein can be performed in any suitable order, unless otherwise indicated herein or clearly contradicted by context. Any examples provided herein, or the use of exemplary language (e.g., "such as"), are intended merely to better illustrate the embodiments and do not impose limitations on the scope of the disclosure unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the disclosure.

[0122] Disjunctive language, such as the phrase "at least one of X, Y, or Z," is intended to be understood in context as generally used to indicate that an item, term, etc. can be either X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z), unless specifically stated otherwise. Thus, such disjunctive language is generally not intended to, and should not, imply that a particular embodiment requires that at least one of X, at least one of Y, or at least one of Z, respectively, be present.

[0123] 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 will become apparent to those skilled in the art upon reading the foregoing 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 as specifically described herein. Accordingly, this 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, this disclosure encompasses any combination of the above-described elements in all possible variations thereof.

[0124] All references cited in this specification, including publications, patent applications, and patents, are herein 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.

[0125] In the foregoing specification, aspects of the disclosure have been 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-described disclosure can be used individually or in combination. Moreover, the embodiments can 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 rather than restrictive.

Claims

1. generating a unified identity and access management (IAM) system from a first IAM system and a second IAM system different from the first IAM system by (i) creating a domain within a customer tenant associated with the first IAM system, and (ii) embedding an identity provider of the second IAM system within the domain; receiving, by the integrated IAM system, a request from a user to perform an action with respect to a resource associated with the second IAM system; and executing the request in response to the user being successfully authenticated by the integrated IAM system.

2. The method of claim 1 , wherein the domain is created in a compartment of the customer tenant.

3. The method of claim 2 , wherein the compartment is associated with a policy corresponding to one or more rules governing access to resources by the user.

4. 3. The method of claim 1, further comprising creating a plurality of domains within the customer tenant, each of the plurality of domains corresponding to a stripe of the second IAM system, the stripe corresponding to a container that includes one or more users.

5. The method of claim 4 , wherein each of the plurality of domains is associated with a corresponding policy.

6. 3. The method of claim 1, wherein the control plane of the integrated IAM system includes (i) a first endpoint configured to receive requests for the creation of a new domain, and (ii) a plurality of second endpoints, each of which corresponds to a previously created domain and is configured to receive requests related to operations to be performed within the domain.

7. registering an application with said domain; Creating a dynamic group of one or more resource principals; The method of claim 1 or 2, further comprising: assigning the dynamic group of one or more resource principals to the application.

8. 3. The method of claim 1, further comprising provisioning a default domain for the customer tenant, the default domain including a first user who created the customer tenant, the default domain being associated with a default policy that provides the first user access within the customer tenant.

9. 3. The method of claim 1 or 2, wherein the request is processed by a network source determiner (NSD) located within the customer tenant, the NSD configured to determine a source of the request, the method further comprising: executing the request in response to successfully identifying the source of the request.

10. The method of claim 1 or 2, wherein the request is performed without coordinating the first IAM system with the second IAM system.

11. 1. A computer program comprising specific computer-executable instructions that, when executed by a processor of a computer system, cause the computer system to perform a method, the method comprising: generating a unified identity and access management (IAM) system from a first IAM system and a second IAM system different from the first IAM system by (i) creating a domain within a customer tenant associated with the first IAM system, and (ii) embedding an identity provider of the second IAM system within the domain; receiving, by the integrated IAM system, a request from a user to perform an action with respect to a resource associated with the second IAM system; and executing the request in response to the user being successfully authenticated by the integrated IAM system.

12. The computer program of claim 11 , wherein the domain is created in a compartment of the customer tenant.

13. The computer program product of claim 12 , wherein the compartment is associated with a policy corresponding to one or more rules governing access to resources by the user.

14. The method comprises:

13. The computer program product of claim 11 or 12, further comprising creating a plurality of domains within the customer tenant, each of the plurality of domains corresponding to a stripe of the second IAM system, the stripe corresponding to a container including one or more users.

15. 13. The computer program product of claim 11 or 12, wherein the control plane of the integrated IAM system includes (i) a first endpoint configured to receive requests related to the creation of a new domain, and (ii) a plurality of second endpoints, each of the plurality of second endpoints corresponding to a previously created domain and configured to receive requests related to operations to be performed within the domain.

16. The method comprises: registering an application with said domain; Creating a dynamic group of one or more resource principals; 13. The computer program product of claim 11 or 12, further comprising: assigning the dynamic group of one or more resource principals to the application.

17. 13. The computer program product of claim 11 or 12, wherein the request is processed by a network source determiner (NSD) located within the customer tenant, the NSD configured to determine a source of the request, and the method further comprising executing the request in response to successfully identifying the source of the request.

18. 13. The computer program product of claim 11 or 12, wherein the request is performed without coordinating the first IAM system with the second IAM system.

19. 1. A computing device comprising: a processor; and a memory containing instructions that, when executed by the processor, cause the computing device to perform at least: generating a unified identity and access management (IAM) system from a first IAM system and a second IAM system different from the first IAM system by (i) creating a domain within a customer tenant associated with the first IAM system, and (ii) embedding an identity provider of the second IAM system within the domain; receiving, by the integrated IAM system, a request from a user to perform an action with respect to a resource associated with the second IAM system; and executing the request in response to the user being successfully authenticated by the integrated IAM system.

20. 20. The computing device of claim 19, wherein the request is performed without coordination between the first IAM system and the second IAM system.

Images