Single Logout

Abstract

Described herein is a system and method for single logout between two independent systems. The system includes a first access control system having a first login protocol. The first access control system includes at least one first processor and a memory including a plurality of instructions executable by the at least one first processor. The system includes a second access control system. The second access control system has a second login protocol independent of the first login protocol. The first access control system can receive a logout request from a user at the first access control system, log out the user from the first access control system, and utilize a trust mechanism to log out the user from the second access control system.

Description

[Background technology]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Application No. 63 / 250,713, entitled “Single Logout,” filed September 30, 2021, which is incorporated by reference herein in its entirety.

[0002] background Recently, the adoption of cloud services has been growing rapidly. Currently, various types of cloud services are offered by various cloud service providers (CSPs). The term cloud service is generally used to refer to services or functionality made available by the CSP on demand to subscribing customers, generally using a subscription model, using systems and infrastructure (commonly referred to as cloud infrastructure) provided by the CSP. Generally, the servers and systems included in the cloud infrastructure provided by the CSP used to provide cloud services to subscribing customers are separate from the customer's own on-premise servers and systems. The infrastructure provided by the CSP may include computing, storage, and networking resources. Thus, customers can utilize the cloud services provided by the CSP without having to purchase their own hardware and software resources for the services. Cloud services are designed to allow subscribing customers to easily and scalably access applications and computing resources on demand, without the customer having to invest in procuring infrastructure to provide the services or functionality. Various types or models of cloud services may be offered, such as software as a service (SaaS), platform as a service (PaaS), infrastructure as a service (IaaS), etc. A customer can subscribe to one or more cloud services provided by a CSP. A customer can be any entity, such as an individual, an organization, or a business.

[0003] Different services offered by CSPs may have different logout procedures and / or requirements. In some instances, these different procedures and / or requirements may result in an unsatisfactory customer experience. Thus, further improvements are desirable. Summary of the Invention

[0004] overview An aspect of the disclosure relates to a method for performing single logout between two independent systems. The method includes receiving a logout request from a user at a first system of the two systems, logging out the user from the first system of the two systems, and logging out the user from a second system of the two systems utilizing a trust mechanism. In some embodiments, the trust mechanism may include at least one token.

[0005] In some embodiments, the trust mechanism includes at least one token. In some embodiments, the logout request indicates logging out of the user from a first system of the two systems. In some embodiments, logging out the user from the first system of the two systems includes expiring the user's session on the first system. In some embodiments, logging out the user from a second system of the two systems utilizing the trust mechanism includes redirecting the user to the second system.

[0006] In some embodiments, utilizing the trust mechanism to log out the user from the second of the two systems includes sending a JSON Web Token (JWT) from the user browser to the second system. In some embodiments, the JWT can be a post-logout redirect URL. In some embodiments, the JWT further includes an IAM login secret key.

[0007] In some embodiments, utilizing the trust mechanism to log out the user from the second of the two systems includes clearing cookies and / or tokens of the second system from the user browser. In some embodiments, utilizing the trust mechanism to log out the user from the second of the two systems includes logging out the user from an application of the second system. In some embodiments, utilizing the trust mechanism to log out the user from the second of the two systems includes sending a confirmation of the logout from the second system to the user browser, the confirmation of the logout including a JWT. In some embodiments, utilizing the trust mechanism to log out the user from the second of the two systems includes sending a JWT from the user browser to the first system as confirmation of completion of the logout from the second system. In some embodiments, the method includes logging out another application of the first system via communication of a front channel logout URL.

[0008] In some embodiments, a first system of the two systems is an attribute-based access control (ABAC) system. In some embodiments, a second system of the two systems is a role-based access control (RBAC) system. In some embodiments, a first system of the two systems is a role-based access control (RBAC) system. In some embodiments, a second system of the two systems is an attribute-based access control (ABAC) system. In some embodiments, a first system of the two systems identifies other applications of the first system to which the user is logged in and logs the user out of those other applications. In some embodiments, a second system of the two systems identifies other applications of the second system to which the user is logged in, receives a front channel logout URL in the other applications of the second system to which the user is logged in, and directs loading of the front channel logout URL by the other applications of the second system to which the user is logged in.

[0009] One aspect relates to a system including a first access control system having a first login protocol and a second access control system having a second login protocol independent of the first login protocol. The first access control system includes at least one first processor and a memory including a plurality of instructions executable by the at least one first processor. The first access control system is capable of receiving a logout request from a user at the first access control system, logging the user out of the first access control system, and utilizing a trust mechanism to log the user out of the second access control system.

[0010] In some embodiments, the logout request indicates a logout of the user from the first access control system. In some embodiments, logging out the user from the first access control system includes expiring the user's session on the first access control system. In some embodiments, logging out the user from the second access control system utilizing the trust mechanism includes redirecting the user to the second access control system. In some embodiments, logging out the user from the second access control system utilizing the trust mechanism includes sending a JSON Web Token (JWT) from the user browser to the second access control system.

[0011] One aspect relates to a non-transitory computer-readable storage medium storing a plurality of instructions executable by one or more processors that, when executed by the one or more processors, cause the one or more processors to receive a logout request from a user at a first of two systems, log out the user from the first of the two systems, and log out the user from a second of the two systems utilizing a trust mechanism. [Brief description of the drawings]

[0012] [Figure 1] FIG. 1 is a simplified block diagram of a distributed multi-domain environment incorporating an exemplary embodiment. [Diagram 2] FIG. 1 is a schematic diagram of one embodiment of a system for unified identity management. [Diagram 3] 1 is a flow diagram illustrating one embodiment of a process for single logout. [Figure 4] 11 is a flow chart illustrating another embodiment of a process for single logout. [Diagram 5] FIG. 1 is a block diagram illustrating one pattern for implementing a cloud infrastructure as a service system in accordance with at least one embodiment. [Figure 6]FIG. 2 is a block diagram illustrating another pattern for implementing a cloud infrastructure as a service system in accordance with at least one embodiment. [Figure 7] FIG. 2 is a block diagram illustrating another pattern for implementing a cloud infrastructure as a service system in accordance with at least one embodiment. [Figure 8] FIG. 2 is a block diagram illustrating another pattern for implementing a cloud infrastructure as a service system in accordance with at least one embodiment. [Figure 9] FIG. 1 is a block diagram illustrating an example of a computer system in accordance with at least one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0014] The present disclosure relates generally to cloud computing, specifically to logout to an independently authenticated system, and more specifically to single logout to an independently authenticated system.

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

[0016] The data centers offered by a CSP may be hosted in different geographic regions. A region may refer to a specific geographic area and be identified by a region name. Regions are generally independent of each other and may be in very distant locations, such as across countries or even continents. Examples of CSP regions include US West, US East, Australia East, Australia Southeast, etc. In certain implementations, a collection of regions is called a realm. A realm may include one or more regions. Thus, a CSP may offer a realm that includes one or more regions, where each region includes one or more data centers.

[0017] Thus, each datacenter is associated with a region. A CSP may deploy one or more datacenters within a region, where the datacenters are located within a particular geographic area (e.g., city) within the region. For example, a particular CSP may have multiple regions, such as US Western region, US Eastern region, Australia Eastern region, Australia Southeast region, etc. The CSP may deploy one or more datacenters in each region, such as cities within the region. For example, one or more datacenters in the US Western region may be in San Jose, California, a datacenter in the US Eastern region may be in Ashburn, Virginia, one or more datacenters in the Australia Eastern region may be in Sydney, Australia, one or more datacenters in the Australia Southeast region may be in Melbourne, Australia, etc. Datacenters in two different regions may provide the same or different sets of cloud services and resources to subscribing customers.

[0018] In certain implementations, to provide high availability to customers and for disaster recovery purposes, data centers within a region may be further organized into one or more availability domains, where an availability domain contains one or more data centers. The availability domains within a region are isolated from each other, fault tolerant, and designed to make it highly unlikely that data centers in multiple availability domains within a region will fail simultaneously. For example, the availability domains within a region may be structured such that a failure in one availability domain within a region is unlikely to impact the availability of data centers in other availability domains within the same region.

[0019] A Cloud Service Provider (CSP) may offer multiple cloud services to 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.

[0020] In a cloud environment, an identity management 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 identity management system include, but are not limited to, user single sign-on capabilities, authentication and authorization services, and other identity-based services.

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

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

[0023] As a result of offering these two separate platforms, if a CSP customer subscribes to both SaaS or PaaS and IaaS services offered by the CSP, that customer now has two separate accounts - one account with IAM for the IaaS subscription and a separate account with IDCS for the PaaS / SaaS subscription. Each account has its own credentials such as user login, password, etc. Thus, the same customer has two separate sets of credentials. This results in a less than satisfactory customer experience, customers having to maintain two different sets of credentials, and potentially increased security risks as the credentials are maintained in two systems. Furthermore, having two separate identity management systems also creates obstacles to interaction between SaaS / PaaS and IaaS services.

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

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

[0026] However, this integration is technically very challenging, since the two platforms may use different procedures and protocols to implement identity-related features. For example, IAM is 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 expressing complex Boolean rule sets that can evaluate many different attributes. The purpose of ABAC is to protect objects such as data, network devices, and IT resources from unauthorized users and actions that do not have the "approved" 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 constructs such as role-privilege, user-role, and role-role relationships make it easier to perform user assignments. As yet another example, the authentication and authorization frameworks or workflows used by the two platforms may be different (e.g., types of tokens used, different authentication frameworks such as OAUTH, etc.). Therefore, providing an integration solution is technically very challenging.

[0027] When a user signs on to IAM and IDCS, there may be further issues associated with signing off from these multiple systems. To solve this issue, single logout is developed. A user may be logged into multiple applications, but single logout logs the user out from all those applications. This is achieved by logging the user out directly using IDCS and then logging out from IAM utilizing a trust mechanism in the form of a token.

[0028] Depending on whether a user tries to log out via an IAM application or an IDCS application, the backend workflow changes, but the user experience remains the same.

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

[0030] FIG. 1 is a simplified block diagram of a distributed, multi-domain environment 100 incorporating an exemplary embodiment. The distributed environment 100 illustrates multiple domain data centers communicatively connected to one another via a communications network 130. For purposes of illustration, the domains illustrated in FIG. 1 include a global domain 102, a domain 112 that is a home domain for a particular tenancy, and a domain 122 that is a non-home domain for that tenancy (i.e., a domain that is not the home domain for the tenancy). For purposes of illustrating various features, assume that the non-home domain 122 is Phoenix, USA (identified by the label "PHX") and the home domain 112 is Ashburn, USA (identified by the label "ASH").

[0031] Each region shown in Figure 1 may include one or more datacenters that comprise infrastructure provided by the CSP to provide one or more cloud services on a subscription basis to subscribing customers. The datacenter infrastructure may include computing, memory, and networking resources provided by the CSP. For example, in Figure 1, global region 102 includes datacenter 104 (also referred to as global region datacenter 104), home region 112 includes datacenter 114 (also referred to as home region datacenter 114), and non-home region 122 includes datacenter 124 (also referred to as non-home region datacenter 124).

[0032] The data centers in the various regions may be communicatively coupled to each other and to user devices 140 via a communication network 130 that facilitates communication between the various computing systems. The communication network 130 may be of various types and may include one or more communication networks, such as one or more public networks. Examples of the communication network 130 include, without limitation, the Internet, a wide area network (WAN), a local area network (LAN), an Ethernet network, a wired network, a wireless network, and the like, and combinations thereof. Different communication protocols may be used to facilitate communication over the communication network 130, including both wired and wireless protocols, such as the IEEE 802.XX protocol suite, TCP / IP, IPX, SAN, AppleTalk, Bluetooth, and various other protocols. In general, the communication network 130 may include any infrastructure that facilitates communication between the various systems depicted in FIG. 1.

[0033] In the embodiment shown in Figure 1, each datacenter hosts an identity and access management (IAM) application (referred to as a login application in Figure 1) configured to perform identity and access management functions such as login processing, session creation, authentication / authorization operations, etc. In Figure 1, global region datacenter 104 includes login application 106 (also referred to as global login application 106), home region datacenter 114 includes login application 116 (also referred to as home region login application 116), and non-home region datacenter 124 includes login application 126.

[0034] As previously discussed, when a tenancy account is opened for a customer, a home realm is associated with the tenancy. Generally, identity and access management (IAM) artifacts configured for the tenancy are stored in a data center of the home realm of the tenancy. These IAM artifacts may include, for example, login credentials, certificates, keys, etc. These artifacts are used to perform login operations, for example, when creating a new session, authentication or authorization functions, and other identity and access management related functions for the tenancy. For example, when a user associated with the tenancy requests access to a protected resource, operations to allow the user to access the resource may involve operations (e.g., tenancy login operations and session creation) that can be performed using IAM artifacts configured for the tenancy and stored in a home realm data center of the tenancy's home realm.

[0035] In FIG. 1, it is assumed that region 112 is the home region for tenancy T1, and thus IAM resources 118 and / or IDCS resources 119 in tenancy T1 are stored by home region datacenter 114. A region within a realm can be a home region for multiple tenancies. Also, within a realm, one region can be the home region for a first tenancy, a second, different region can be the home region for a second tenancy, and so on. As previously mentioned, in general, IAM artifacts and resources and / or IDCS artifacts and resources in a tenancy are stored in a datacenter in the home region associated with that tenancy.

[0036] In certain implementations, tenancy-to-home-region mapping information is used to map tenancies to their corresponding home regions. The tenancy-to-home-region mapping information may identify home regions and home region datacenters in different tenancies. In some embodiments, any region may be a global region, and thus all regions may contain information regarding tenancy-to-home-region mapping. In the embodiment of FIG. 1, tenancy-to-home-region mapping information 108 is shown as being stored by the global region datacenter 104 and not by the other datacenters shown in FIG. 1.

[0037] One or more resources (e.g., applications) may be hosted by different data centers. These applications may be used by users associated with customers who subscribe to one or more cloud services offered by the CSP. For example, in FIG. 1, application "AppA" 128 is deployed in non-home domain data center 124 of domain 122. For the purposes of the example shown in FIG. 1, assume that domain 122 is a non-home domain with respect to tenancy T1.

[0038] A user 142 associated with a customer tenancy can access one or more services or resources (e.g., AppA 128) provided by the various data centers illustrated in FIG. 1 through a user device 140. The user device 140 can be a computing device such as a laptop, desktop, mobile device, etc. There are various ways in which a user such as user 142 can access a resource such as AppA 128. In a particular use case, the user 142 can use an application (e.g., a browser) running on the user device 140 to access the resource. For example, in FIG. 1, the user 142 can access AppA 128 using a browser 144. The user 142 can access AppA 128 by providing a URL endpoint corresponding to AppA 128 to the browser 144, by clicking a link corresponding to AppA 128, etc. An API call can also be made to access AppA 128.

[0039] AppA 128 may be a "protected" resource, in which case access to AppA 128 is controlled by an IAM application. A user associated with a customer tenancy (such as user 142) is typically identified by a user account or user principal associated with the user. User 142 can access protected resources such as AppA 128 through this user account or user principal.

[0040] Browser 144 may be of different types. Commonly used browsers include Google Chrome®, Mozilla Firefox®, Microsoft Edge, Internet Explorer®, Apple Safari®, and others. A particular browser implementation may have associated storage capabilities. For example, browser 144 has in-browser storage represented by database 145. Information related to various endpoints accessed using browser 144 or applications accessed using browser 144 is stored in database 145 on user device 140 (called client-side storage because it is stored on the user device).

[0041] 2, a schematic diagram of one embodiment of a system 200 for unified identity management, also referred to herein as a unified identity management platform 200, is shown. The system 200 includes a user device 202, which may be a user device 140, one or several IAM servers 204, and one or several IDCS servers 206. In some embodiments, the user device 202 may comprise a computing device such as a laptop, a desktop, a mobile device, etc. The one or several IAM servers 204 and / or the one or several IDCS servers 206 may each comprise one or several computing resources including, for example, one or several servers or server racks. The one or several IAM servers 204 and / or the one or several ICDS servers 206 may be located in one or several of the global region 102, the home region 112, and / or the non-home region 122.

[0042] One of the number of IAM servers 204 may include an instance of IAM login 208, also referred to herein as IAM logout 208. In some embodiments, the instance of IAM login 208 may interact with the user during all or part of the login and / or logout process. These instances may include, for example, a local instance, a global instance, and / or a home instance. In some embodiments, the local instance may run on a server in the same realm as the server where the IAM app runs, the global instance may run on a server that includes a common global endpoint, and the home instance may run in the home realm of the tenancy that the user is trying to access.

[0043] One of the IAM servers 204 may further include an IAM application 210, which may be an application protected by the IAM. In some embodiments, a user may log in to access the IAM application 210 and may log out when they are done using the IAM application 210.

[0044] One or several instances of the IDCS server 206 can include an IDCS application 212, which can be an IDCS-secured application. In some embodiments, a user can log in to access the IDCS application 212 and can log out when they are done using the IDCS application 212.

[0045] A user can log in through one or more IAM applications 210 or can log in through one or more IDCS applications 212 using a user device 202. Similarly, a user can log out through one or more IAM applications 210 running on one or more IAM servers 204 or can log out through one or more IDCS applications 212 running on one or more IDCS servers 206.

[0046] In some embodiments, the user device 202 can be directly connected to one or both of the at least one IAM server 204 and the at least one IDCS server 206, e.g., via a wired or wireless connection over the communications network 130. In some embodiments, the user device 202 can be directly connected to one or both of the at least one IAM server 204 and the at least one IDCS server 206, e.g., via one or more communications networks and / or one or more computer networks. In some embodiments, the user device 202 can be directly connected to one or both of the at least one IAM server 204 and the at least one IDCS server 206, e.g., via the Internet.

[0047] In some embodiments, some or all of the IAM server 204 and the IDCS server 206 can be located in the same location or in different locations. In some embodiments, some or all of the IAM server 204 and the IDCS server 206 can be located in different computing networks, different data centers, different regions, etc. In some embodiments, when applying single logout between independent systems as disclosed herein, when a user logs out of one of the IAM server 204 and the IDCS server 206, the user is automatically logged out of the other of the IAM server or IDCS server 206.

[0048] In some embodiments, the method may include receiving a logout request from a user at a first system of two systems. The two systems may include, for example, an IAM or an IDCS. In some embodiments, the logout request may be received from the user via a protection application, such as, for example, an IAM protection application or an IDCS protection application. The method includes logging out the user from the first system of the two systems and then utilizing a trust mechanism to log out the user from a second system of the two systems. The trust mechanism may include at least one token.

[0049] In some embodiments, the method may include receiving a logout request from a user. The logout request may indicate a logout of the user from a first of two systems. The two systems may include, for example, an IAM or an IDCS. The method may include expiring the user's session on the first system and redirecting the user to the second system. Thus, in some embodiments, the session may be expired on one of the IAM and the IDCS and the user may then be redirected to the other of the IAM and the IDCS. The method may include sending a JSON Web Token (JWT) from the user browser to the second system and clearing cookies and / or tokens of the second system from the user browser. The user may be logged out of an application of the second system and a confirmation of the logout from the second system may be sent from the second system to the user browser. The confirmation of the logout may include the JWT and may include sending the JWT from the user browser to the first system as confirmation of completion of the logout from the second system. In some embodiments, the JWT includes a post-logout redirect URL. The method can include logging out of other applications of the first system via communication of the front channel logout URL.

[0050] In some embodiments, a first of the two systems includes an attribute-based access control (ABAC) system and a second of the two systems includes a role-based access control (RBAC) system. In some embodiments, a first of the two systems includes a role-based access control (RBAC) system and a second of the two systems includes an attribute-based access control (ABAC) system. In some embodiments, the first of the two systems identifies other applications of the first system to which the user is logged in and logs the user out of those other applications. In some embodiments, the second of the two systems identifies other applications of the second system to which the user is logged in, receives front channel logout URLs of the other applications of the second system to which the user is logged in, and directs loading of the front channel logout URLs by the other applications of the second system to which the user is logged in.

[0051] From the IAM application 3, a flow chart illustrating one embodiment of a process 300 for single logout is shown. Process 300 may be performed by all or a portion of system 200. Process 300 begins when user 142 selects to log out of IAM protected application 210 via user device 140, as shown in step 402. In some embodiments, the user may select log out via operation of a feature within a user interface, such as, for example, operation of a log out button and / or pressing one or more keys that indicate log out. The user may select log out within and / or from within the IAM protected application.

[0052] At step 304, the tokens are cleared from the browser storage in the application domain. In some embodiments, these tokens are cleared by the user browser in response to the user selecting to log out. In some embodiments, these tokens may be tokens in the application domain. At step 306, the user browser redirects the user to an IAM login, specifically an instance of IAM login 208. At step 308, the user is prompted to log out at the IAM login.

[0053] In step 310, the user information in the user browser is cleared in the user browser's indexed database, thereby expiring the session. Specifically, the IAM login 208 instructs the user browser to clear the user information, which may expire the user browser's session from the IAM login domain.

[0054] The user browser redirects to the IDCS logout at step 312. As part of this redirect, the user browser sends an IAM token, which may be a JSON Web Token (JWT). This token may include a post-logout redirect URL, which may be signed, for example, using the private key of the user browser and / or the IAM login. In some embodiments, this token, when stamped by the IAM login, may ensure the authenticity of the post-logout redirect URL.

[0055] At step 314, the IDCS clears login-related cookies and / or tokens in the user browser. In some embodiments, this may include clearing session tokens from the IDCS domain in the user browser. At step 316, the IDCS redirects the user browser to an IAM logout. This may include sending the next URL for the user browser to navigate to from the IDCS to the user browser.

[0056] At step 318, the user browser sends the JWT already sent to IDCS at step 312 to the IAM login. This may further include the user browser sending the tenant and / or domain the user browser is logged into to IDCS. The IAM login recognizes the JWT and trusts the redirect request. At step 320, the IAM login instructs the user browser to load front channel logout URLs. These front channels may be loaded via iframes of other IAM applications that are logged into. In some embodiments, the iframes may load front channel logout URLs of other applications that the user and / or the user browser is logged into. At step 322, the user browser instructs the other applications to load the front channel logout URLs. In some embodiments, the front channel logout URLs may be saved during login. At step 324, the user browser redirects to the post-logout redirect URL included within the JWT.

[0057] Logging out from the IDCS application 4, a flow chart illustrating one embodiment of a process 400 for single logout is shown. Process 400 may be performed by all or a portion of system 200. Process 400 is executed to initiate a logout from an IDCS protected application 212, which may then be propagated to other systems, specifically any IAM applications 210 to which the user is logged in.

[0058] Process 400 begins when a user 142 selects to log out of the IDCS protected application 212 via a user device 140, as shown in step 402. In some embodiments, the user may select log out via operation of a function within a user interface, for example, via operation of a log out button and / or via pressing one or more keys that indicate log out. The user may select log out within and / or from within the IAM protected application.

[0059] At step 404, the tokens are cleared from the browser storage in the application domain. In some embodiments, these tokens are cleared by the user browser in response to the user selecting logout. In some embodiments, these tokens may be tokens in the application domain. At step 406, the browser redirects to IDCS logout. At step 408, the user is prompted to log out at IDCS. This may include initiating an Oauth protocol between the user browser and IDCS logout and / or sending a token from the user browser to IDCS logout. The token may be, for example, a JWT token that may include a post-logout redirect URL. In some embodiments, the JWT may include a value that may be an opaque value that may maintain state between the request and the callback.

[0060] At step 410, the user information in the user browser is cleared in the user browser's indexed database, thereby expiring the session. This may include, for example, clearing tokens and / or cookies that may be stored by the user browser. In some embodiments, this may further include logging the user out of other IDCS protected applications 212 in which the user is logged in. In some embodiments, this may include an IDCS logout that determines whether the user is logged into other IDCS protected applications 212, and if other IDCS protected applications 212 in which they are logged in are identified, the user is logged out of those other IDCS protected applications 212.

[0061] IDCS logout redirects the user browser to IAM logout at step 412. As part of this redirect, the user browser sends a token, which may be a JSON Web Token (JWT). In some embodiments, the JWT may be signed by an IDCS private key. In some embodiments, this JWT may be sent so that the IDCS can be verified. Specifically, the user browser sends the JWT token to IAM logout, and when IAM login redirects to IDCS, IDCS sends the JWT back to the user browser so that the IDCS can be verified. In step 414, a logout request is sent to IAM login, which may include information identifying the tenant, domain, etc. In some embodiments, the JWT may also be set to the IAM login. The logout request may be sent from the user browser to the IAM login. In some embodiments, the logout request may further include an opaque value and / or string used to maintain state between requests. In some embodiments, this logout request may include a token, which may include, for example, an opaque value and / or string. In step 416, IAM login instructs the user browser to set the session to expire, and the front channel logout URLs of all apps logged in through the IAM are invoked. In some embodiments, this may include identifying the IAM protected application the user is logged into and / or this may include querying the front channel logout URL from a data repository and / or database in which they are stored. Depending on which request, the front channel logout URL for the IAM application the user is logged into can be obtained and provided.

[0062] At step 418, the front channel logout URL saved during login is loaded. In some embodiments, this may include loading the retrieved and provided front channel logout URL. At step 420, the IAM login redirects the user browser to IDCS. At step 422, the user browser sends the token, causing a clearing of the login-related cookies in the token in the user browser. In some embodiments, this may include the browser sending the JWT from step 414, originally sent to the IDCS login at step 408. In some embodiments, sending the JWT, and using the JWT to verify identity information, may provide a secure way to communicate requests and ensure that the communication information is not manipulated. Based on the received token, the IDCS login may trust the success of the IAM logout and may redirect the user browser to a post-logout redirect URL, as shown at step 424. In some embodiments, the post-logout redirect URL may be included in the token, for example. At step 426, the post-logout redirect URL is provided from the browser to the user application.

[0063] Exemplary embodiments 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 instances, IaaS providers may also offer various services (e.g., billing, monitoring, logging, load balancing, clustering) that accompany these infrastructure components. Thus, these services are policy-driven, so IaaS users may implement policies that drive load balancing to maintain application availability and performance.

[0064] In some instances, IaaS customers can access resources and services over a wide area network (WAN) such as the Internet and 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 to 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.

[0065] In most cases, the cloud computing model requires the involvement of a cloud provider, which may be, but does not have to be, a third-party service that specializes in supplying (e.g., providing, renting, selling) IaaS. Enterprises can also choose to become their own infrastructure service provider by implementing a private cloud.

[0066] 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 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., server, storage, network hardware, virtualization). Thus, the customer may be involved in the process of (OS), middleware, and / or application deployment (e.g., self-service virtual machines (e.g., that can be spun up on demand)), etc.

[0067] In some instances, IaaS provisioning may even refer to obtaining the computers or virtual hosts you want to use and installing the libraries or services they require. In most cases, deployment does not include provisioning, so you may need to perform the provisioning first.

[0068] In some examples, there are two distinct challenges in 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 examples, 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 required 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) can be described declaratively. In some examples, once the topology is defined, workflows can be generated that create and / or manage the various components described in the configuration files.

[0069] In some examples, the infrastructure may have many interconnected elements. For example, there may be one or more virtual private clouds (VPCs) (e.g., potentially on-demand pools of configurable and / or shared computing resources), also known as a core network. In some examples, there may also be one or more inbound / outbound traffic group rules and one or more virtual machines (VMs) provisioned to define how the network's inbound and / or outbound traffic 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.

[0070] In some examples, continuous deployment techniques may be used to enable infrastructure code to be deployed 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 desired to be deployed to one or more, but often many, different production environments (e.g., across various geographic locations, which may span the entire world). However, in some examples, the infrastructure to which the code will be deployed must first be set up. In some examples, provisioning may be done manually, provisioning tools may be utilized to provision resources, and / or deployment tools may be utilized to deploy the code after the infrastructure has been provisioned.

[0071] FIG. 5 is a block diagram 500 illustrating an example pattern of an IaaS architecture, according to at least one embodiment. A service operator 502 can be communicatively coupled to a secure host tenancy 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 may be portable handheld devices (e.g., iPhone®, mobile phones, iPad®, computing tablets, personal digital assistants (PDAs)) or wearable devices (e.g., Google Glass® head-mounted displays) running software such as Microsoft Windows Mobile®, and / or various mobile operating systems such as iOS, Windows Phone, Android, BlackBerry 8, Palm OS, etc., and Internet, email, short message service (SMS), BlackBerry®, or other communication protocols enabled. Alternatively, the client computing devices may 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 devices may be thin-client computers, Internet-enabled gaming systems (e.g., Microsoft Xbox game consoles with or without Kinect® gesture input devices) and / or other electronic devices such as personal messaging devices capable of communicating over a network with access to the VCN 506 and / or the Internet.

[0072] 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, and the SSH VCN 512 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 tenancy 519, which may be owned and / or operated by the IaaS provider.

[0073] 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 help prevent intrusions. 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, and 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, a service gateway 536, and a network address translation (NAT) gateway 538 included in the control plane data tier 528. The control plane VCN 516 may include a service gateway 536 and a NAT gateway 538 .

[0074] The control plane VCN 516 can include a data plane mirrored app layer 540, which 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, which can be included in the data plane app layer 546.

[0075] 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 that can be communicatively connected 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 connected 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 that can be communicatively coupled to the app subnet 526 of the data plane app layer 546.

[0076] The internet gateways 534 of the control plane VCNs 516 and data plane VCNs 518 can be communicatively connected to a metadata management service 552, which can be communicatively connected to the public internet 554. The public internet 554 can 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 can be communicatively coupled to cloud services 556.

[0077] 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. The API calls from the service gateway 536 to the cloud service 556 can be one-way. That is, 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 initiate the API call to the service gateway 536.

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

[0079] The control plane VCN 516 can enable users of the service tenancy 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.

[0080] 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 tier 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 tier 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. Metadata desired to be saved by the request may be saved in the DB subnet 530.

[0081] 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.

[0082] In some embodiments, the control plane VCN 516 and the data plane VCN 518 can be included in the service tenancy 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, the 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 tenancy 519. This embodiment may allow for network isolation that can prevent users or customers from interacting with resources of other users or other customers. This embodiment also allows users or customers of the system to store databases privately without having to rely on the public Internet 554 for storage, which may not have the desired level of threat protection.

[0083] 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 a service tenancy 519 that may be controlled by the IaaS provider and isolated from the public Internet 554.

[0084] 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 tenancy 604 (e.g., secure host tenancy 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 SSH VCN 612 (e.g., SSH VCN 512 of FIG. 5) via an LPG 510 included in a secure shell (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 tenancy 619 (e.g., service tenancy 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 tenancy 621, which can be owned or operated by a user or customer of the system.

[0085] The control plane VCN 616 may include a control plane DMZ tier 620 (e.g., control plane DMZ tier 520 of FIG. 5) that may include a LB subnet 622 (e.g., LB subnet 522 of FIG. 5), a control plane app tier 624 (e.g., control plane app tier 524 of FIG. 5) that may include an app subnet 626 (e.g., app subnet 526 of FIG. 5), and a control plane data tier 628 (e.g., control plane data tier 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 tier 620 can be communicatively coupled to an app subnet 626 included in the control plane app tier 624 and 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 and a service gateway 636 (e.g., service gateway 536 in FIG. 5 ) and a network address translation (NAT) gateway 638 (e.g., NAT gateway 538 in FIG. 5 ) included in the control plane data tier 628. The control plane VCN 616 can include the service gateway 636 and the NAT gateway 638.

[0086] 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 computing instance 544 of FIG. 5 ) can run. The computing instance 644 can facilitate communication between the app subnet 626 of the data plane mirror app layer 640 and the app subnet 626 that 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.

[0087] 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 of FIG. 5), which can be communicatively coupled to a public Internet 654 (e.g., public Internet 554 of 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 of FIG. 5).

[0088] In some examples, the data plane VCN 618 can be included in the customer tenancy 621. In this case, the IaaS provider provides a control plane VCN 616 for each customer, and the IaaS provider can configure a unique compute instance 644 for each customer, which is included in the service tenancy 619. Each compute instance 644 can enable communication between the control plane VCN 616 included in the service tenancy 619 and the data plane VCN 618 included in the customer tenancy 621. The compute instance 644 can enable resources provisioned in the control plane VCN 616 included in the service tenancy 619 to be deployed or otherwise available in the data plane VCN 618 included in the customer tenancy 621.

[0089] In another example, a customer of the IaaS provider may have a database that resides in the customer tenancy 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 may be accessible to the customer tenancy 621, but the data plane mirror app layer 640 may not reside in the data plane VCN 618 and may not be owned or operated by the IaaS provider customer. 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 entities included in the control plane VCN 616. A customer may desire 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 can facilitate the desired deployment or other use of the customer's resources.

[0090] 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 included in the customer tenancy 621 can help isolate the data plane VCN 618 from other customers and the public Internet 654.

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

[0092] 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 tenancy 704 (e.g., secure host tenancy 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), which can be communicatively coupled to an SSH VCN 712 (e.g., SSH VCN 512 of FIG. 5) via an LPG 710 included in the SSH VCN 712. SSH VCN 712 can include an SSH subnet 714 (e.g., SSH subnet 514 in FIG. 5), which can be communicatively coupled to a control plane VCN 716 (e.g., control plane VCN 516 in FIG. 5) via an LPG 710 included in the control plane VCN 716, and to a data plane VCN 718 (e.g., data plane 518 in FIG. 5) via an LPG 710 included in the data plane VCN 718. The control plane VCN 716 and the data plane VCN 718 can be included in a service tenancy 719 (e.g., service tenancy 519 in FIG. 5).

[0093] 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 tier 720 can be communicatively coupled to an app subnet 726 included in the control plane app tier 724 and to an Internet gateway 734 (e.g., Internet gateway 534 of 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 included in the control plane data tier 728 and to a service gateway 736 (e.g., service gateway of FIG. 5 ) and a network address translation (NAT) gateway 738 (e.g., NAT gateway 538 of FIG. 5 ). The control plane VCN 716 can include the service gateway 736 and the NAT gateway 738.

[0094] The data plane VCN 718 can 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 can include a LB subnet 722, which can be communicatively coupled to a trusted app subnet 760 and an untrusted app subnet 762 of the data plane app layer 746 and to an Internet gateway 734 included in the data plane VCN 718. The trusted app subnet 760 can 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 can 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.

[0095] 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) that may be included in a respective container egress VCN 768(1)-(N) that may be included in a respective customer tenancy 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).

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

[0097] In some embodiments, the data plane VCN 718 can be integrated with a customer tenancy 770. This integration can be useful or desirable for an IaaS provider's customer in some instances, such as when they want support at code runtime. A customer may provide executable code that may be potentially disruptive, communicate with other customer resources, or cause other undesirable effects. In response, the IaaS provider can determine whether to run code provided to the IaaS provider by the customer.

[0098] In some examples, an IaaS provider's customer may grant the IaaS provider temporary network access and request functionality to be added to the data plane app layer 746. The code to perform the functionality may be executed in VMs 766(1)-(N), and the code may not be configured to run elsewhere on the data plane VCN 718. Each VM 766(1)-(N) may be connected to one customer tenancy 770. Each container 771(1)-(N) contained in a VM 766(1)-(N) may be configured to execute code. In this case, there may be double isolation (e.g., if a container 771(1)-(N) executes code, the container 771(1)-(N) may be contained in at least one VM 766(1)-(N) contained in the untrusted app subnet 762), which helps prevent rogue code or other undesirable code from damaging the IaaS provider's network or damaging another customer's network. Containers 771(1)-(N) may be communicatively coupled to customer tenancy 770 and may be configured to send or receive data from customer tenancy 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 dispose of containers 771(1)-(N).

[0099] 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 within 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.

[0100] 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.

[0101] 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 tenancy 804 (e.g., secure host tenancy 504 of FIG. 5), which can include a virtual cloud network (VCN) 806 (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), which can be communicatively coupled to an SSH VCN 812 (e.g., SSH VCN 512 of FIG. 5) via an LPG 810 included in 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 (e.g., control plane VCN 516 in FIG. 5) via an LPG 810 included in the control plane VCN 816, and to a data plane VCN 818 (e.g., data plane 518 in FIG. 5) via an LPG 810 included in the data plane VCN 818. The control plane VCN 816 and the data plane VCN 818 can be included in a service tenancy 819 (e.g., service tenancy 519 in FIG. 5).

[0102] The control plane VCN 816 may include a control plane DMZ layer 820 (e.g., control plane DMZ layer 520 of FIG. 5) which 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) which 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) which may include a DB subnet 830 (e.g., DB subnet 730 of FIG. 7). The LB subnet 822 included in the control plane DMZ tier 820 can be communicatively coupled to an app subnet 826 included in the control plane app tier 824 and to an Internet gateway 834 (e.g., Internet gateway 534 in FIG. 5 ) that may be included in the control plane VCN 816, and the app subnet 826 can be communicatively coupled to a DB subnet 830 included in the control plane data tier 828 and to a service gateway 836 (e.g., service gateway in FIG. 5 ) and a network address translation (NAT) gateway 838 (e.g., NAT gateway 538 in FIG. 5 ). The control plane VCN 816 can include the service gateway 836 and the NAT gateway 838.

[0103] The data plane VCN 818 can 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 can include a LB subnet 822 that can be communicatively coupled to a trusted app subnet 860 (e.g., trusted app subnet 760 in FIG. 7) and 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 can be communicatively coupled to a service gateway 836 included in the data plane VCN 818, 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 coupled 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, which can be communicatively coupled to a service gateway 836 included in the data plane VCN 818.

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

[0105] An Internet gateway 834 included in the control plane VCN 816 and in the data plane VCN 818 may be communicatively coupled to a metadata management service 852 (e.g., metadata management system 552 of FIG. 5 ), which may be communicatively coupled to the public Internet 854. The public Internet 854 may 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 is communicatively coupled to cloud services 856.

[0106] 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 700 of FIG. 7 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 a VM 866(1)-(N) for each customer may be accessed by the customer in real time. 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 tier 846 that may be contained in a container egress VCN 868. The secondary VNIC 872(1)-(N) may send the calls to a NAT gateway 838 that may send the calls to the public internet 854. In this example, the containers 867(1)-(N) 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 also be isolated from resources from other customers.

[0107] 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 to LB subnet 822 included in control plane VCN 816 via internet gateway 834. 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.

[0108] It should be understood that the illustrated IaaS architectures 500, 600, 700, 800 may have components other than those shown. Additionally, the illustrated embodiments are only some examples of cloud infrastructure systems that may incorporate embodiments of the present disclosure. In some other embodiments, the IaaS systems may have more or fewer components than shown, may combine two or more components, or may have a different configuration or arrangement of components.

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

[0110] 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 previously described. As illustrated, 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 acceleration unit 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.

[0111] 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, which may be implemented as a mezzanine bus manufactured in accordance with the IEEE P1386.1 standard.

[0112] The processing unit 904 may be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers) and controls the operation of the computer system 900. One or more processors may be included in the processing unit 904. These processors may include single-core processors or multi-core processors. In particular embodiments, the 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, the processing unit 904 may be implemented as a quad-core processing unit formed by incorporating two dual-core processors on a single chip.

[0113] 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 storage subsystem 918. Through appropriate programming, the processor 904 may provide various functions as previously discussed. The computer system 900 may further include a processing acceleration unit 906, which may include a digital signal processor (DSP), a special purpose processor, or the like.

[0114] The I / O subsystem 908 can include user interface input devices and user interface output devices. User interface input devices can include pointing devices such as keyboards, mice or trackballs, touch pads or touch screens 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 motion sensing and / or gesture recognition devices such as Microsoft Kinect® motion sensors that allow a user to control and interact with an input device such as a Microsoft Xbox® 360 game controller through a natural user interface using gestures and voice commands. User interface input devices can also include eye gesture recognition devices such as the Google Glass® blink detector that detects eye activity from a user (e.g., “blinking” during picture taking and / or menu selection) 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.

[0115] User interface input devices may include, but are not limited to, three-dimensional (3D) mice, joysticks or pointing sticks, game pads and graphic tablets, and 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, eye tracking devices, etc. Additionally, user interface input devices may include medical imaging input devices such as, for example, computed tomography, magnetic resonance imaging, position emission tomography, medical ultrasound machines, etc. User interface input devices may also include audio input devices such as, for example, MIDI keyboards, digital musical instruments, etc.

[0116] User interface output devices may include a display subsystem, indicator lights, or non-visual displays such as audio output devices. The display subsystem may be a cathode ray tube (CRT), a flat panel device such as a liquid crystal display (LCD) or plasma display, a projection device, a touch screen, or the like. In general, use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from computer system 900 to a user or to another computer. For example, user interface output devices may 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.

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

[0118] 9, the storage subsystem 918 can include various components including a system memory 910, a computer readable storage medium 922, and a computer readable storage medium reader 920. The system memory 910 can store program instructions loadable and executable by the processing unit 904. The system memory 910 can also store data used during execution of the instructions and / or data generated during execution of the program instructions. A variety of different types of programs can be loaded into the system memory 910, including, but not limited to, client applications, web browsers, mid-tier applications, relational database management systems (RDBMS), virtual machines, containers, and the like.

[0119] The system memory 910 may also store an operating system 916. Examples of 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 OS, Palm OS operating systems, etc. In certain implementations in which the computer system 900 runs one or more virtual machines, the virtual machines along with their guest operating systems (GOS) may be loaded into the system memory 910 and executed by one or more processors or cores of the processing unit 904.

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

[0121] The computer-readable storage medium 922 may represent remote, local, fixed, and / or removable storage devices as well as storage media for temporarily and / or more permanently containing and storing computer-readable information used by the computer system 900, including instructions executable by the processing unit 904 of the computer system 900.

[0122] The computer readable storage medium 922 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 method or technology for storing and / or transmitting information, including tangible computer readable storage media such as RAM, ROM, Electronically Erasable Programmable ROM (EEPROM), flash memory or other memory technology, CD-ROM, Digital Versatile Disk (DVD) or other optical storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or other tangible computer readable storage media.

[0123] 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, solid state ROMs, SSDs based on volatile memory such as solid state RAM, dynamic RAM, static RAM, 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 the computer system 900.

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

[0125] 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 900 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 advanced data network technologies such as cellular technology, 3G, 4G or EDGE (Enhanced Data Rates Worldwide), WiFi (IEEE 802.11 family of standards), 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.

[0126] 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.

[0127] 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 Twitter® feeds, Facebook® updates, web feeds, e.g., Rich Site Summary (RSS) feeds, and / or real-time updates from one or more third party information sources.

[0128] 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 in nature or unlimited with no explicit 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.

[0129] 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 can be in communication with one or more streaming data source computers coupled to the computer system 900.

[0130] The computer system 900 can 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.

[0131] Due to the ever-changing nature of computers and networks, the description of the computer system 900 shown in the figure is intended as a specific example only. 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 and / 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 may recognize other ways and / or methods for implementing various embodiments.

[0132] 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 a particular data processing environment, but can 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 can be used individually or in combination.

[0133] Additionally, 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. 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 certain operations, such configuration may be achieved, for example, by designing electronic circuitry to perform the operations, by programming a programmable electronic circuit (such as a microprocessor) to perform the operations or combinations thereof, or by any other method. Processes may communicate using a variety of techniques, including, but not limited to, conventional techniques for inter-process communication, and different pairs of processes may use different techniques, or the same pair of processes may use different techniques at different times.

[0134] 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.

[0135] The use of the terms "a," "an," "the," and similar referents in the context of describing the disclosed embodiments (especially in the claims) should be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by the 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 indicated. The term "connected" should be construed as being partially or wholly contained within, attached to, or coupled to, even if there is something intervening. The recitation of ranges of values ​​herein is merely intended to serve as a shorthand way of individually referring to each individual value 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 the context. Any examples provided herein, or the use of exemplary language (e.g., "such as"), are intended merely to better describe 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.

[0136] Disjunctive language, such as the phrase "at least one of X, Y, or Z," is intended to be understood within the context in which it is used to indicate that an item, term, etc. may generally be X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z), unless otherwise noted. 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.

[0137] 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.

[0138] 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.

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

Claims

1. receiving a logout request from a user at a first of the two systems; Logging out the user from the first of the two systems; Logging out the user from a second of the two systems utilizing a trust mechanism; The method includes:

2. The method of claim 1 , wherein the trust mechanism includes at least one token.

3. The method of claim 1 , wherein the logout request indicates a logout of the user from the first of the two systems.

4. 4. The method of claim 3, wherein logging out the user from the first of the two systems comprises expiring the user's session on the first system.

5. 5. The method of claim 4, wherein utilizing the trust mechanism to log out the user from the second of the two systems includes redirecting the user to the second of the two systems.

6. 6. The method of claim 5, wherein utilizing the trust mechanism to log out the user from the second of the two systems includes sending a JSON Web Token (JWT) from a user browser to the second of the two systems.

7. The method of claim 6 , wherein the JWT includes a post-logout redirect URL.

8. The method of claim 7 , wherein the JWT further includes an IAM login secret key.

9. 7. The method of claim 6, wherein utilizing the trust mechanism to log out the user from the second of the two systems includes clearing cookies and / or tokens for the second of the two systems from the user browser.

10. 10. The method of claim 9, wherein utilizing the trust mechanism to log out the user from the second of the two systems includes logging out the user from an application of the second of the two systems.

11. 11. The method of claim 10, wherein utilizing the trust mechanism to log out the user from the second of the two systems includes sending a confirmation of logout from the second of the two systems to a user browser, the confirmation of logout including the JWT.

12. 12. The method of claim 11 , wherein utilizing the trust mechanism to log out the user from the second of the two systems includes transmitting the JWT from the user browser to the first system as confirmation of completion of logout from the second of the two systems.

13. 13. The method of claim 12, further comprising logging out other applications of the first system via communication of a front channel logout URL.

14. 2. The method of claim 1, wherein the first of the two systems comprises an attribute-based access control (ABAC) system and the second of the two systems comprises a role-based access control (RBAC) system.

15. 2. The method of claim 1, wherein the first of the two systems comprises a role-based access control (RBAC) system and the second of the two systems comprises an attribute-based access control (ABAC) system.

16. 16. The method of claim 15, wherein the first of the two systems identifies other applications of the first system to which the user is logged in and logs the user out of those other applications.

17. The second of the two systems is Identifying other applications of the second system to which the user is logged in; receiving a front channel logout URL in the other application of the second system in which the user is logged in; directing the loading of the front-channel logout URL by the other application of the second system into which the user is logged in; 17. The method of claim 16.

18. 1. A system comprising: A first access control system having a first login protocol, the first access control system comprising: at least one first processor; a memory containing a plurality of instructions executable by the at least one first processor; The system comprises: a second access control system, the second access control system having a second login protocol independent of the first login protocol; The first access control system comprises: receiving a logout request from a user at the first access control system; Logging the user out of the first access control system; Logging out the user from the second access control system utilizing a trust mechanism. It is configured as follows: system.

19. 20. The system of claim 18, wherein the logout request indicates logging out of the user from the first access control system, logging out of the user from the first access control system expiring the user's session on the first access control system, and utilizing the trust mechanism to log out the user from the second access control system includes redirecting the user to the second access control system, and utilizing the trust mechanism to log out the user from the second access control system includes sending a JSON Web Token (JWT) from a user browser to the second access control system.

20. A program comprising a plurality of instructions executable by one or more processors, the plurality of instructions, when executed by the one or more processors, causing the one or more processors to perform a method according to any one of claims 1 to 17.

Images