Cross-regional trust for multi-tenant identity cloud services

Abstract

To provide secure access to cloud-based applications.SOLUTION: A multi-tenant cloud system includes: a first data center configured to authenticate a first plurality of registered clients and located in a first geographical area; and a second data center configured to authenticate a second plurality of registered clients and located in a second geographical area that is different from the first geographical area. The first data center receives, from a first client of the first plurality of registered clients, a request to access a resource of the second data center, validates the request from the first client, and issues a global access token. The second data center receives the request together with the global access token. Based on the global access token, a cloud gate at the second data center validates the request and provides the resource to the first client.SELECTED DRAWING: Figure 14

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Provisional Patent Application No. 62 / 648,455, filed March 27, 2018, the disclosure of which is incorporated herein by reference.

[0002] Field One embodiment relates generally to identity management, and more particularly to identity management in cloud systems. [Background technology]

[0003] Background information The use of cloud-based applications (e.g., enterprise public cloud applications, third-party cloud applications, etc.), which are typically accessed from a variety of devices (e.g., desktop and mobile devices) and a variety of users (e.g., employees, partners, customers, etc.), is growing exponentially. Due to the diversity and accessibility of cloud-based applications, identity management and access security have become central concerns. Typical security issues in cloud environments include unauthorized access, account hijacking, and malicious insiders. Therefore, secure access is needed for cloud-based applications, regardless of the type of device or user accessing the application, whether the application is cloud-based or located anywhere. Summary of the Invention [Means for solving the problem]

[0004] overview An embodiment of a multi-tenant cloud system includes a first data center configured to authenticate a first plurality of registered clients and located in a first geographic region, and a second data center configured to authenticate a second plurality of registered clients and located in a second geographic region different from the first geographic region. The first data center receives a request from a first client of the first plurality of registered clients to access resources at the second data center, validates the request from the first client, and issues a global access token. The second data center receives the request along with the global access token. A Cloud Gate at the second data center validates the request and provides the resource to the first client based on the global access token. [Brief explanation of the drawings]

[0005] [Figure 1] FIG. 1 is a block diagram of an example of an embodiment providing cloud-based identity management. [Figure 2] FIG. 1 is a block diagram of an example of an embodiment providing cloud-based identity management. [Figure 3] FIG. 1 is a block diagram of an example of an embodiment providing cloud-based identity management. [Figure 4] FIG. 1 is a block diagram of an example of an embodiment providing cloud-based identity management. [Figure 5] FIG. 1 is a block diagram of an example of an embodiment providing cloud-based identity management. [Figure 6] FIG. 1 is a block diagram providing a system view of an embodiment. [Figure 6A] FIG. 1 is a block diagram providing a functional view of an embodiment. [Figure 7] FIG. 1 is a block diagram of an embodiment implementing Cloud Gate. [Figure 8] FIG. 1 illustrates an example of a system that provides multiple tenancies in one embodiment. [Figure 9]FIG. 2 is a block diagram of a network view of an embodiment. [Figure 10] FIG. 1 is a block diagram of a system architecture view of single sign-on ("SSO") functionality in one embodiment. [Figure 11] FIG. 10 is a message sequence flow diagram of the SSO feature in one embodiment. [Figure 12] FIG. 1 illustrates an example of a distributed data grid in one embodiment. [Figure 13] FIG. 1 illustrates a public cloud with multiple data centers (denoted "DC") deployed therein, each forming a "region," according to one embodiment. [Figure 14] FIG. 1 is a flow diagram of a function for accessing resources at a remote data center using a regional multi-tenant cloud-based identity and access management system, according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0006] Detailed Description Embodiments enable a client to access resources in a remote region or data center by requesting and receiving a new global access token from the home region, and then using the global access token to access resources in the remote region. In one embodiment, the issuer of the global access token is a multi-tenant identity management deployment that has been provisioned with a global signing key, and the token has specialized token claims specific to the global access or resource.

[0007] Embodiments provide an identity cloud service that enables a microservices-based architecture and provides multi-tenant identity and data security management and secure access to cloud-based applications. Embodiments support secure access for hybrid cloud deployments (i.e., cloud deployments that include a combination of public and private clouds). Embodiments protect applications and data both in the cloud and on-premise. Embodiments support multi-channel access via web, mobile devices, and application programming interfaces ("APIs"). Embodiments: Manages access for various users, including customers, partners, and employees. Embodiments manage, control, and audit both access through the cloud and on-premise. Embodiments integrate with new and existing applications and identities. Embodiments are horizontally scalable.

[0008] One embodiment is a system that provides cloud-based multi-tenant identity and access management services by implementing multiple microservices in a stateless middle-tier environment. In one embodiment, each requested identity management service is divided into real-time and near-real-time tasks. The real-time tasks are processed by the middle-tier microservices, while the near-real-time tasks are offloaded to a message queue. An embodiment enforces a security model for accessing microservices by implementing access tokens that are consumed by the routing and middle tiers. Thus, an embodiment provides a cloud-scale Identity and Access Management ("IAM") platform based on a multi-tenant microservices architecture. We provide a program.

[0009] One embodiment provides an identity cloud service that enables organizations to rapidly develop fast, reliable, and secure services for their new business initiatives. In one embodiment, the identity cloud service provides a number of core services. Each core service solves a unique challenge faced by many enterprises. In one embodiment, the identity cloud service supports administrators, for example, when initially onboarding / importing users, importing groups with user members, creating / updating / disabling / enabling / deleting users, assigning / unassigning users to groups, creating / updating / deleting groups, resetting passwords, managing policies, sending activations, etc.

[0010] Unified Access Security An embodiment protects applications and data in both cloud and on-premises environments. The embodiment secures access to any application by anyone from any device. The embodiment provides protection across both of these environments because security inconsistencies between the two environments can pose a high risk. For example, if there is such a inconsistency, a sales person may continue to have access to their Customer Relationship Management ("CRM") account even after they leave for a competitor. Thus, the embodiment extends security controls provisioned in the on-premises environment to the cloud environment. For example, if a person leaves a company, the embodiment ensures that the account is disabled both on-premises and in the cloud.

[0011] Typically, a user may access applications and / or data through a variety of channels, such as a web browser, desktop, mobile phone, tablet, smartwatch, other wearable device, etc. Accordingly, one embodiment secures access through all of these channels. For example, a user can use their mobile phone to complete a transaction that they initiated on their desktop.

[0012] An embodiment further manages access for various users, such as customers, partners, employees, etc. Typically, applications and / or data may be accessed not only by employees, but also by customers or third parties. Many known systems provide security measures when onboarding employees, but these measures typically do not meet the same level of security measures when granting access to customers, third parties, partners, etc., resulting in a potential security breach by an unsupervised party. However, embodiments ensure that sufficient security measures are provided for access for each type of user, not just employees.

[0013] Identity Cloud Services Embodiments provide Identity Cloud Service ("IDCS"), a multi-tenant, cloud-scale IAM platform. IDCS provides authentication, authorization, auditing, and federation. IDCS manages access to custom applications and services running on public cloud and on-premise systems. In alternative or additional embodiments, IDCS may also manage access to public cloud services. For example, IDCS can be used to provide Single Sign On ("SSO") capabilities across such diverse services / applications / systems. can.

[0014] Embodiments are based on a multitenant microservices architecture for designing, building, and delivering cloud-scale software services. Multitenancy refers to a physical realization of a service that securely supports multiple customers who subscribe to the service. A service is a software function or set of software functions (e.g., retrieving specified information or performing a set of operations) that can be reused by different clients for different purposes, along with policies that govern its use (e.g., based on the identity of the client requesting the service). In one embodiment, a service is a mechanism that allows access to one or more functions, provided using a specified interface and performed according to constraints and policies specified by the service description.

[0015] In one embodiment, a microservice is an independently deployable service. In one embodiment, the term microservice is intended to refer to a software architectural design pattern in which complex applications are composed of small, independent processes that communicate with each other using language-agnostic APIs. In one embodiment, microservices are small, finely decoupled services, each of which may be focused on performing a small task. In one embodiment, the microservices architectural style is an approach to developing a single application as a set of small services, each running in its own process and communicating using lightweight mechanisms (e.g., Hypertext Transfer Protocol ("HTTP") resources). In one embodiment, microservices are easier to replace than monolithic services that perform all or many of the same functions. Additionally, each microservice may be updated without adversely affecting other microservices. In contrast, updating one part of a monolithic service may have undesirable or unintended adverse effects on other parts of the monolithic service. In one embodiment, microservices may be usefully organized around their functionality. In one embodiment, the startup time of each microservice in a collection of microservices is much shorter than the startup time of a single application that runs all of the microservices together. In some embodiments, the startup time of each such microservice is on the order of one second or less, whereas the startup time of such a single application may be on the order of one minute, several minutes, or longer.

[0016] In one embodiment, a microservices architecture is a specialization of service oriented architecture ("SOA") for building flexible, independently deployable software systems. Microservices architecture is a methodology for separating and realizing tasks within a system. Services in a microservices architecture are processes that communicate with each other over a network to achieve a goal. In one embodiment, these services use technology-agnostic protocols. In one embodiment, services use fine-grained, lightweight protocols. In one embodiment, services are independently deployable. By distributing system functionality across different, smaller services, the system becomes more cohesive and coupling is reduced. This makes it easier to change the system and add functionality and quality to the system at any point. It also allows the architecture of individual services to emerge through constant refactoring, thus reducing the need for extensive up-front design and enabling earlier, continuous releases of software.

[0017] In one embodiment, in a microservices architecture, an application is developed as a collection of services, each running its own process and communicating using a lightweight protocol (e.g., a specific API per microservice). In a microservices architecture, the decomposition of a piece of software into individual services / functions can be done at different levels of granularity depending on the services provided. A service is a runtime component / process. Each microservice is a self-contained module that can talk to other modules / microservices. Each microservice has an anonymous universal port through which it can be contacted. In one embodiment, a microservice's anonymous universal port is a standard communication channel that a microservice traditionally exposes (e.g., a traditional HTTP port) that allows other modules / microservices within the same service to talk to it. Microservices or other self-contained functional modules can be collectively referred to as "services."

[0018] Embodiments provide multi-tenant identity management services that are based on open standards that ensure easy integration with a variety of applications, providing IAM capabilities through standards-based services.

[0019] Embodiments manage the lifecycle of user identities, which involves determining and enforcing what an identity can access, who can grant such access, who can manage such access, etc. Embodiments run identity management workloads in the cloud and support security functions for applications that do not necessarily reside in the cloud. The identity management services provided by these embodiments may be purchased from the cloud. For example, an enterprise may purchase such services from the cloud to manage its employees' access to the enterprise's applications.

[0020] Embodiments provide system security, massive scalability, end-user usability, and application interoperability. Embodiments address the growth of cloud and customer use of identity services. A microservices-based foundation addresses horizontal scalability requirements, while tightly orchestrated services address functional requirements. To achieve both of these goals, business logic is decomposed (as much as possible) to ultimately achieve consistent statelessness, while most operational logic that is not subject to real-time processing is shifted to near real-time by offloading it to a highly scalable asynchronous event management system with guaranteed delivery and processing. Embodiments are fully multi-tenant from the web tier to the data tier to achieve cost efficiencies and ease system management.

[0021] Embodiments may utilize industry standards (e.g., OpenID Connect, OAuth2, Security Assertion Markup Language 2 (“SAML2”), Cross-Signal Authentication, and other standards) to facilitate integration with various applications. The implementation follows standards such as System for Cross-domain Identity Management ("SCIM") and Representational State Transfer ("REST"). One embodiment provides a cloud-scale API platform, enabling horizontally scalable microservices for elastic scalability. This embodiment leverages cloud principles to provide a multi-tenant architecture with data isolation per tenant. This embodiment also provides per-tenant customization via tenant self-service. This embodiment supports on-demand integration with other identity services via APIs. It is available and provides continuous feature releases.

[0022] One embodiment provides interoperability and leverages investments in identity management ("IDM") capabilities in the cloud and on-premise. The present embodiment provides a method for transferring data from on-premise Lightweight Directory Access Protocol ("LDAP") data to cloud data, and Vice versa, it provides automated identity synchronization. This embodiment provides a SCIM identity bus between the cloud and the enterprise, enabling various options for hybrid cloud deployment (e.g., identity federation and / or synchronization, SSO agents, user provisioning connectors, etc.).

[0023] Accordingly, one embodiment is a system that provides cloud-based multi-tenant identity and access management services by implementing multiple microservices in a stateless middle tier. In one embodiment, each requested identity management service is divided into real-time and near-real-time tasks. The real-time tasks are processed by microservices in the middle tier, while the near-real-time tasks are offloaded to a message queue. An embodiment implements tokens that are consumed by a routing tier to enforce a security model for accessing the microservices. Accordingly, an embodiment provides a cloud-scale IAM platform based on a multi-tenant microservices architecture.

[0024] Known systems typically provide siloed access to applications provided by various environments, such as corporate cloud applications, partner cloud applications, third-party cloud applications, and customer applications. Such siloed access may require multiple passwords, different password policies, different account provisioning and deprovisioning techniques, disparate auditing, and the like. However, one embodiment provides unified IAM functionality for such applications by implementing IDCS. FIG. 1 is a block diagram 100 of an example embodiment using IDCS 118 to provide a unified identity platform 126 for onboarding users and applications. This embodiment provides a seamless user experience across various applications, such as corporate cloud applications 102, partner cloud applications 104, third-party cloud applications 110, and customer applications 112. Applications 102, 104, 110, and 112 may be accessed through different channels, for example, by a mobile phone user 108 via a mobile phone 106 and by a desktop computer user 116 via a browser 114. A web browser (commonly referred to as a browser) is a software application for retrieving, presenting, and traversing information resources on the World Wide Web. Examples of web browsers include Mozilla® Firefox®, Google Chrome®, Microsoft® Internet Explorer®, and and Apple® Safari®.

[0025] IDCS 118 provides a unified view 124 of a user's applications, unified secure credentials across devices and applications (via identity platform 126), and unified management (via admin console 122). IDCS services may be obtained by calling IDCS API 142. Such services include, for example, login / SSO services 128 (e.g., OpenID Connect), federation services 130 (e.g., SAML), token services 132 (e.g., OAuth), directory services 134 (e.g., SCIM), provisioning services 136 (e.g., SCIM or Ansible), and so on. Transport over Multiprotocol ("AToM"), event services 138 (e.g., REST), and role-based access control ("R The IDCS 118 may also provide reports and dashboards 120 regarding the services provided.

[0026] Integration Tools Large enterprises typically have IAM systems in place to secure access to their on-premises applications. Business practices are typically mature and standardized around an in-house IAM system, such as Oracle's "Oracle IAM Suite." Small to mid-sized organizations also typically design their business processes around managing user access through simple directory solutions, such as Microsoft Active Directory ("AD"). To enable on-premises integration, embodiments provide tools that enable customers to integrate their applications with IDCS.

[0027] 2 is a block diagram 200 of an example embodiment using IDCS 202 in a cloud environment 208 providing integration with AD 204 on-premises 206. This embodiment provides a seamless user experience across all applications, including various applications / services in the cloud 208, such as cloud services 210, cloud applications 212, partner applications 214, and customer applications 216, as well as on-premises and third-party applications, such as on-premises applications 218. Cloud applications 212 may include, for example, Human Capital Management ("HCM"), CRM, Talent Acquisition (e.g., Oracle Corporation's Oracle Taleo cloud service), Configure Price and Quote ("CPQ"), and other cloud services. Cloud services 210 may include, for example, Platform as a Service (“PaaS”), Java, databases, etc. data, business intelligence (“BI”), documents, etc. It can be seen.

[0028] Applications 210, 212, 214, 216, 218 may be accessed through different channels, for example, by a mobile phone user 220 via a mobile phone 222 and by a desktop computer user 224 via a browser 226. The embodiment automatically synchronizes identities from on-premise AD data to cloud data via a SCIM identity bus 234 between the cloud 208 and the enterprise 206. The embodiment also provides a SAML bus 228 for federating authentication (e.g., using passwords 232) from the cloud 208 to the on-premise AD 204.

[0029] In general, an identity bus is a service bus for identity-related services. A service bus provides a platform for communicating messages from one system to another, for example, in a service oriented architecture ("SOA") to share information between trusted systems. An identity bus is a logical bus built according to standard HTTP-based mechanisms such as web services, web server proxies, etc. Communication in an identity bus may be performed according to a protocol (e.g., SCIM, SAML, OpenID Connect, etc.). For example, a SAML bus is an HTTP-based connection between two systems to carry messages related to SAML services. Similarly, a SCIM bus is used to carry SCIM messages according to the SCIM protocol.

[0030] The embodiment of Figure 2 implements a small binary (e.g., 1MB in size) Identity ("ID") Bridge 230 that can be downloaded and installed on-premise 206 along with a customer's AD 204. The ID Bridge 230 aggregates users and groups (e.g., users and groups) of organizational units ("OUs") selected by the customer. IDCS 208 listens to groups of users (e.g., groups of users) and synchronizes these users to the cloud 208. In one embodiment, user passwords 232 are not synchronized to the cloud 208. Customers can manage application access for users by mapping groups of IDCS users to cloud applications managed in IDCS 208. Whenever a user's group membership changes on-premise 206, the corresponding cloud application access is automatically changed.

[0031] For example, an employee who moves from the engineering department to the sales department can gain near-instant access to the sales cloud and lose access to the developer cloud. When this change is reflected in the on-premises AD 204, the cloud application access change is realized in near real time. Similarly, a user who leaves the enterprise has access to cloud applications managed by IDCS 208 revoked. For full automation, a customer may set up SSO between the on-premises AD 204 and IDCS 208, for example, through an AD federation service ("AD / FS" or some other mechanism that achieves SAML federation), allowing end users to access cloud applications 210, 212, 214, 216 and on-premises applications 218 using a single enterprise password 332.

[0032] FIG. 3 is a block diagram 300 of an example embodiment that includes the same components 202, 206, 208, 210, 212, 214, 216, 218, 220, 222, 224, 226, 228, and 234 as FIG. 2 . However, in the embodiment of FIG. 3 , the IDCS 202 provides integration with an on-premises IDM 304, such as Oracle IDM. Oracle IDM 304 is a software suite from Oracle Corporation for providing IAM functionality. This embodiment provides a seamless user experience across all applications, including on-premises and third-party applications. This embodiment provisions user identities from the on-premises IDM 304 to the IDCS 208 via a SCIM identity bus 234 between the cloud 202 and the enterprise 206. This embodiment also provides a SAML bus 228 (or OpenID Connect bus) for federated authentication from the cloud 208 to the on-premises 206.

[0033] In the embodiment of FIG. 3, Oracle Identity Manager (Oracle Identity Manager) from Oracle Corporation is used. Identity Manager ("OIM") Connector 302 and Oracle Access Manager from Oracle Corporation Oracle Access Manager ("OAM") Integration Module 306 OIM is realized as an extension module of Oracle IDM 304. A connector is a module that has physical knowledge of how to talk to a system. OIM is an application configured to manage user identities (e.g., managing user accounts in different systems based on what a user should and should not have access to). OAM is a security application that provides access management capabilities such as web SSO, identity context, authentication and authorization, policy management, testing, logging, and auditing. OAM has built-in support for SAML. If a user has an account in IDCS 202, you can use the OIM Connector 302 and OAM Federation 306 with Oracle IDM 304 to create / delete this account and manage access from this account.

[0034] FIG. 4 is a block diagram 400 of an example embodiment that includes the same components 202, 206, 208, 210, 212, 214, 216, 218, 220, 222, 224, 226, and 234 as in FIGS. 2 and 3. However, in the embodiment of FIG. 4, IDCS 202 provides functionality for extending cloud identities to on-premises applications 218. This embodiment provides a seamless view of identities across all applications, including on-premises and third-party applications. In the embodiment of FIG. 4, a SCIM identity bus 234 is used to synchronize data in IDCS 202 with on-premises LDAP data, referred to as a "cloud cache" 402. Cloud cache 402 is disclosed in more detail below.

[0035] Generally, applications configured to communicate based on LDAP require an LDAP connection. Such applications may not establish an LDAP connection using a URL (unlike, for example, "www.google.com" to connect to Google®) because LDAP must be on the local network. In the embodiment of FIG. 4 , the LDAP-based application 218 connects to Cloud Cache 402, which connects to IDCS 202 and then pulls the requested data from IDCS 202. Communication between IDCS 202 and Cloud Cache 402 may be achieved according to the SCIM protocol. For example, Cloud Cache 402 may use SCIM bus 234 to send SCIM requests to IDCS 202 and receive corresponding data.

[0036] Typically, the complete realization of an application involves building a consumer portal, running marketing campaigns to external user populations, supporting web and mobile channels, and handling user authentication, sessions, user profiles, user groups, application roles, password policies, self-service / registration, social integration, identity federation, etc. Application developers are typically not identity / security experts, which is why on-demand identity management services are desirable.

[0037] FIG. 5 is a block diagram 500 of an example embodiment that includes the same components 202, 220, 222, 224, 226, 234, and 402 as in FIGS. 2-4. However, in the embodiment of FIG. 5, IDCS 202 provides on-demand, secure identity management. This embodiment provides on-demand integration with IDCS 202's identity services (e.g., based on standards such as OpenID Connect, OAuth2, SAML2, or SCIM). Applications 505 (which may be on-premises or in a public or private cloud) may call IDCS 202's identity service API 504. Services provided by IDCS 202 may include, for example, self-service registration 506, password management 508, user profile management 510, user authentication 512, token management 514, social integration 516, and the like.

[0038] In this embodiment, the SCIM identity bus 234 is used to synchronize data in IDCS 202 with data in the on-premises LDAP cloud cache 402. Additionally, "Cloud Gate" 502 running on a web server / proxy (e.g., NGINX, Apache, etc.) may be used by applications 505 to obtain user web SSO and REST API security from IDCS 202. Cloud Gate 502 secures access to multi-tenant IDCS microservices by ensuring that client applications provide valid access tokens and / or users successfully authenticate to establish an SSO session. Cloud Gate 502 is further disclosed below. Cloud Gate 502 (an enforcement point similar to webgate / webagent) is a component that supports This allows applications running behind a web server that is running on the same machine to participate in SSO.

[0039] One embodiment provides SSO and cloud SSO capabilities. For many organizations, SSO is a common entry point for both on-premises IAM and IDCS. Cloud SSO allows users to access multiple cloud resources with a single user sign-in. Organizations often want to federate their on-premises identities. Therefore, by leveraging open standards, embodiments enable integration with existing SSO, allowing you to conserve and extend your investment (e.g., until an eventual full migration to an identity cloud services approach).

[0040] One embodiment may provide the following functionality: Maintaining an identity store to track authorized user accounts, ownership, access, and permissions. · Integration with workflows to simplify the various approvals (e.g., administrative, IT, human resources, legal, and compliance) required for application access. Provision SaaS user accounts for select devices (e.g., mobile and personal computers (“PCs”)). Access to user portals includes numerous private and public cloud resources. ·Facilitate periodic management demonstrations for compliance with regulations and current job responsibilities.

[0041] In addition to these features, embodiments further include: Cloud account provisioning for managing the account lifecycle in cloud applications; More robust multifactor authentication (“MFA”) integration; Enhanced mobile security features, and Dynamic authentication options may be provided.

[0042] One embodiment provides adaptive authentication and MFA. Passwords and challenge questions have typically been deemed insufficient and susceptible to common attacks such as phishing. Most modern enterprises are turning to some form of MFA to reduce risk. However, for a solution to be successfully deployed, it must be easy for end users to provision, maintain, and understand, as end users typically resist anything that disrupts their digital experience. Enterprises are looking to make MFA a nearly transparent component of a seamless user access experience while still allowing for bring your own device ("bring your own device") authentication. "BYOD"), social identities, remote users, customers, and contractors are seeking ways to securely incorporate them. In MFA deployments, industry standards such as OAuth and OpenID Connect are essential to ensure the integration of existing multi-factor solutions and the adoption of newer adaptive authentication technologies. Accordingly, embodiments define dynamic (or adaptive) authentication as the evaluation of available information (i.e., IP address, location, time, and biometrics) to prove identity after a user session has begun. Appropriate standards (e.g., open authentication ("OAT")) are used to verify identity. With integration of "Fast Identity Online" ("FIDO") and fast identity online ("FIDO") authentication technologies and an extensible identity management framework, embodiments can be easily adopted and upgraded within IT organizations as part of an end-to-end secure IAM deployment. When considering MFA and adaptive policies, organizations must achieve consistent policies across on-premise and cloud resources, which requires integration between systems in hybrid IDCS and on-premise IAM environments.

[0043] One embodiment provides user provisioning and attestation. Generally, a fundamental function of an IAM solution is to enable and support the entire user provisioning lifecycle. This includes providing users with application access appropriate to their identity and role within the organization (e.g., as a user's role or the tasks or applications used in that role change over time) and quickly deprovisioning users when they leave the organization. This is important not only for meeting various compliance requirements, but also because inappropriate insider access is a leading cause of security breaches and attacks. Automated user provisioning capabilities in identity cloud solutions can be important not only in their own right but also as part of a hybrid IAM solution. Therefore, IDCS provisioning can offer more flexibility during migration than on-premises solutions when companies downsize, expand, merge, or seek to integrate existing systems with IaaS / PaaS / SaaS environments. An IDCS approach can save time and effort in one-time upgrades and ensure proper integration of necessary departments, divisions, and systems. The need to scale this technology often emerges silently within the enterprise, and quickly delivering scalable IDCS capabilities across the enterprise can provide benefits in terms of flexibility, cost, and control.

[0044] Typically, employees are granted additional privileges over the years as their job responsibilities change (i.e., "privilege creep"). Less regulated enterprises typically lack an "attestation" process. This process requires administrators to periodically audit the enterprise's employee privileges (e.g., access rights to networks, servers, applications, and data) to stop or slow privilege creep that results in over-privileged accounts. Therefore, one embodiment may provide a regularly performed (at least annual) attestation process. Furthermore, with mergers and acquisitions, the need for these tools and services increases exponentially as users reside in SaaS systems, on-premise, across different departments, and / or are deprovisioned or reassigned. The move to the cloud can further disrupt this situation, and things can quickly escalate beyond existing, often manually managed, attestation methods. Therefore, one embodiment automates these functions, applying advanced analytics to user profiles, access history, provisioning / deprovisioning, and granular rights.

[0045] One embodiment provides identity analytics. In general, the ability to integrate identity analytics with an IAM engine for comprehensive attestation and verification can be essential to securing an organization's risk profile. Properly deployed, identity analytics can require overall enforcement of internal policies. Identity analytics that provide a unified, single management view across cloud and on-premises is highly necessary in preventative governance, risk, and compliance (“GRC”) enterprise environments and can help provide a closed-loop process for reducing risk and meeting compliance regulations. Accordingly, one embodiment provides identity analytics that can be easily customized by clients to meet specific industry conditions and government regulations for reporting and analysis required by administrators, executives, and auditors.

[0046] One embodiment provides self-service and access request capabilities to improve end-user experience and efficiency while reducing the cost of help desk calls. While many enterprises typically deploy on-premises self-service access requests for their employees, many do not adequately extend these systems outside the formal enterprise walls. Positive digital customer experiences beyond the scope of employee use cases contribute to increased business trust and ultimately increased revenue, allowing enterprises to not only reduce customer help desk calls but also increase customer satisfaction. Therefore, one embodiment provides an identity cloud services environment that is based on open standards and seamlessly integrates with existing access control software and MFA mechanisms as needed. The SaaS delivery model eliminates the time and effort previously spent on system upgrades and maintenance, freeing up specialized IT staff to focus on more core business applications.

[0047] One embodiment utilizes privileged account management ("PAM") ) Generally, all organizations, whether using SaaS, PaaS, IaaS, or on-premise applications, are vulnerable to insider abuse of privileged accounts by superusers, such as system administrators, executives, human resources officers, contractors, and system integrators, using their superuser access credentials. Additionally, external threats typically first compromise low-level user accounts and eventually reach and exploit privileged user access controls within corporate systems. Therefore, one embodiment provides PAM to prevent such unauthorized insider account use. A key component of a PAM solution is the password vault, which can be delivered in a variety of ways: as software installed on a corporate server, as a virtual appliance also on a corporate server, as a packaged hardware / software appliance, or as part of a cloud service. The PAM function is analogous to a physical safe used to store passwords that are kept in an envelope and periodically changed with a manifest for sign-in and sign-out. One embodiment allows for password checkout as well as the ability to set time limits, enforce period changes, automatically track checkouts, and report on all activity. One embodiment provides a way to connect directly to the requested resource without the user knowing the password. This functionality also opens the door to methods for session management and other functions.

[0048] Typically, most cloud services utilize APIs and management interfaces, which provide opportunities for intruders to bypass security. Therefore, one embodiment fills these gaps in PAM implementations, as the move to the cloud introduces new challenges for PAM. While many small to medium-sized businesses currently manage their own SaaS systems (e.g., Office 365), large enterprises increasingly have individual business units that spin up their own SaaS and IaaS services. These customers often have PAM functionality included in their identity cloud service solution or obtained from their IaaS / PaaS provider, but they have little or no experience with this responsibility. Additionally, in some cases, many different, geographically distributed business units seek to separate management responsibilities for the same SaaS applications. Therefore, one embodiment enables customers in these situations to link their existing PAM into the overall identity framework of the identity cloud service, ensuring it aligns with the cloud load conditions their business needs dictate, for greater security and compliance.

[0049] API Platform An embodiment provides an API platform that exposes a collection of functionality as a service. APIs are aggregated into microservices, and each microservice exposes one or more of the APIs. That is, each microservice may expose a different type of API. In one embodiment, each microservice communicates only through its API. In one embodiment, each API may be a microservice. In one embodiment, multiple APIs are aggregated into a single service based on the target functionality the service provides (e.g., OAuth, SAML, Admin, etc.). As a result, similar APIs are not exposed as separate runtime processes. APIs are made available to service consumers to use services provided by IDCS.

[0050] Generally, in the IDCS web environment, a URL contains three parts: host, microservice, and resource (e.g., host / microservice / resource). In one embodiment, a microservice is characterized by having a specific URL prefix (e.g., "host / oauth / v1"), and the actual microservice is "oauth / v1" There are multiple APIs under "oauth / v1", for example, For example, the API for requesting a token is "host / oauth / v1 / token", and the API for authenticating (authorizing) a user is "host / oauth / v1 / authorize". In other words, the URL is a microservice. The host portion of the URL identifies the tenant (e.g., https: / / tenant3.identity.oraclecloud.com: / oauth / v1 / token).

[0051] Configuring applications that integrate with external services that have the required endpoints and keeping that configuration up to date is typically a challenge. To overcome this challenge, embodiments expose a public discovery API in a well-known location from which applications can discover information about IDCS that is necessary to consume the IDCS API. In one embodiment, two discovery documents are supported: IDCS configuration (e.g., <idcs-url>IDCS, SAML, SCIM, OAuth, and OpenID Connect in / .well-known / idcs-configuration configuration) and (e.g. <idcs-url> / .well-known / openid-configuration) industry standard This is a quasi-OpenID Connect configuration. Applications can be configured with a single IDCS URL to retrieve discovery documents.

[0052] Figure 6 is a block diagram that provides a system view 600 of IDCS in one embodiment. In Figure 6, any of a variety of applications / services 602 can use the IDCS service by making HTTP calls to the IDCS API. Examples of such applications / services 602 include web applications, native applications (e.g., Windows applications), and Applications built to run on a specific operating system, such as an iOS® application, an Android® application, a web service, a customer application, a partner application, or Software as a Service ("SaaS"), Platform as a Service ("PaaS"), and and Infrastructure as a Service (Iaa It is a service provided by public clouds such as "Cloud Computing Service (CSC)".

[0053] In one embodiment, an HTTP request for an application / service 602 requesting an IDCS service is routed to an Oracle Public Cloud BIG-IP appliance 604 and an IDCS BIG-IP appliance 606 (or similar technology such as a load balancer). The request typically passes through a technology called a Cloud Load Balancer as a Service ("LBaaS"), which implements appropriate security rules to protect the traffic. However, the request may be received in any manner. Within the IDCS BIG-IP appliance 606 (or similar technology, such as a load balancer or Cloud LBaaS, if applicable), a cloud provisioning engine 608 performs the tenant and service reconciliation. In one embodiment, the cloud provisioning engine 608 manages the internal security artifacts associated with new tenants being onboarded to the cloud or new service instances purchased by customers.

[0054] This HTTP request is then received by the IDCS web routing tier 610. This routing tier implements security gates (i.e., cloud gates) and provides service routing and microservice registration and discovery 612. Depending on the requested service, the HTTP request is forwarded to IDCS microservices in the IDCS middle tier 614. IDCS microservices handle external and internal HTTP requests. IDCS microservices implement platform and infrastructure services. IDCS platform services are separately deployed Java-based runtime services that implement the business of IDCS. IDCS infrastructure services are separately deployed runtime services that provide infrastructure support for IDCS. IDCS also includes infrastructure libraries, which are common code packaged as shared libraries used by IDCS services, and shared libraries. The infrastructure services and libraries provide the supporting functionality required by the platform services to implement their functions.

[0055] Platform Services In one embodiment, IDCS supports standard authentication protocols, and therefore the IDCS microservice includes platform services such as OpenID Connect, OAuth, SAML2, and System for Cross-domain Identity Management++ ("SCIM++").

[0056] The OpenID Connect Platform Service enables standard OpenID Connect login / logout flows. Interactive web-based and native applications facilitate standard browser-based OpenID Connect flows to request user authentication and then use a standard identity token, a JavaScript Object Notation ("JSON") Web Token (Web Token "JWT"), to convey the user's authenticated identity. The OpenID Connect protocol receives a JWT identity token from the user. Internally, the runtime authentication model is stateless, maintaining the user's authentication / session state in the form of a host HTTP cookie (containing a JWT identity token). Authentication interactions initiated via the OpenID Connect protocol are delegated to a trusted SSO service that implements the user's login / logout ceremonies for local and federated logins. Further details of this functionality are disclosed below with reference to Figures 10 and 11. In one embodiment, the OpenID Connect functionality is implemented in accordance with, for example, the OpenID Foundation standard.

[0057] OAuth2 Platform Services provides a token authorization service, which provides a rich API infrastructure for creating and validating access tokens that convey user entitlements to make API calls. It supports a range of useful token grant types and allows customers to securely connect clients to its services. It enables standard two-party and three-party OAuth2 token grant types. Support for OpenID Connect ("OIDC") allows compliant applications (OIDC Relay Parties ("RPs")) to be integrated with IDCS as an identity provider (OIDC OpenID Providers ("OPs"). Similarly, by integrating IDCS as an OIDC RP with social OIDC OPs (e.g., Facebook®, Google®, etc.), customers can enable policy-based access of social identities to applications. In one embodiment, OAuth functionality is supported by, for example, the Internet Engineering Task Force ("IETF") , implemented in accordance with Request for Comments (“RFC”) 6749.

[0058] The SAML2 Platform Service provides identity federation services, which allows customers to connect to a SAML identity provider ("ID provider"). It enables the setting up of federation agreements with its partners based on a SAML service provider ("P") and SAML service provider ("SP") relationship model. In one embodiment, the SAML2 platform service implements the standard SAML2 browser post-login and logout profile. In one embodiment, the SAML functionality is implemented in accordance with, for example, IETF, RFC 7522.

[0059] SCIM is an open standard for automating the exchange of user identity information between identity domains or information technology ("IT") systems, for example, as provided by the IETF, RFCs 7642, 7643, and 7644. The SCIM++ Platform Service provides identity management services and enables customers to access the IDP features of IDCS. The administration service exposes a set of stateless REST interfaces (i.e., APIs) covering identity lifecycle, password management, group management, etc., and exposes artifacts as web-accessible resources.

[0060] All IDCS configuration artifacts are resources, and the Admin Service API enables management of IDCS resources (e.g., users, roles, password policies, applications, SAML / OIDC identity providers, SAML service providers, keys, certificates, notification templates, etc.). The Admin Service leverages and extends the SCIM standard to provide Create, Read, Update, Delete, and Query (CRUD) operations on all IDCS resources. It provides a schema-based REST API for IDCS ("Q") operations. In addition, all internal IDCS resources used to manage and configure IDCS itself are exposed as SCIM-based REST APIs. Access to the identity store 618 is isolated to a SCIM++ API.

[0061] In one embodiment, for example, the SCIM standard is implemented to manage user and group resources defined by the SCIM standard, while SCIM++ is configured to support additional IDCS internal resources (e.g., password policies, roles, settings, etc.) using the language defined by the SCIM standard.

[0062] The Administration Service supports SCIM 2.0 standard endpoints using the standard SCIM 2.0 core schema and schema extensions as needed. In addition, the Administration Service supports several SCIM 2.0 compliant endpoint extensions to manage other IDC resources, such as users, groups, applications, and settings. The Administration Service also does not perform CRUDQ operations, but instead provides functional services, such as: For example, a remote procedure call-style ("RPC-style") implementation that provides "UserPasswordGenerator", "UserPasswordValidator", etc. ") supports a set of REST interfaces.

[0063] The IDCS Management API uses the OAuth2 protocol for authentication and authorization. IDCS supports common OAuth2 scenarios, such as those for web server, mobile, and JavaScript applications. Access to the IDCS API is protected by an access token. To access the IDCS Management API, an application must be registered through the IDCS Admin console as an OAuth2 client or as an IDCS application (in which case the OAuth2 client is created automatically) and must be granted the desired IDCS Admin role. When making an IDCS Management API call, the application first Request an access token from the OAuth2 service. After obtaining this token, the application sends the access token in an HTTP Authorization header. The application can use the IDCS Admin REST API directly or can use the IDCS Java Client API library.

[0064] Infrastructure Services IDCS infrastructure services support the functionality of the IDCS platform services. These runtime services include an event processing service (for asynchronously handling user notifications, application submissions, and audits against the database), a job scheduler service (for scheduling and executing jobs, e.g., for executing long-running tasks immediately or at a set time without user intervention), a cache management service, a storage management service (for integrating with public cloud storage services), a reporting service (for generating reports and dashboards), an SSO service (for managing internal user authentication and SSO), a user interface ("UI") service (for hosting different types of user interface ("UI") clients), and a service manager service. The service manager is the internal interface between the Oracle public cloud and IDCS. The service manager manages commands issued by the Oracle public cloud that need to be fulfilled by IDCS. For example, if a customer signs up for an account in a cloud store before they are ready to purchase something, the cloud sends a request to IDCS asking for a tenant to be created. In this case, the service manager implements the cloud-specific behavior that the cloud expects IDCS to support.

[0065] An IDCS microservice may call another IDCS microservice through a network interface (i.e., an HTTP request).

[0066] In one embodiment, IDCS may also provide a schema service (or persistence service) that enables the use of database schema. The schema service allows you to delegate the responsibility of managing database schema to IDCS. Therefore, IDCS users do not need to manage databases because there is an IDCS service that provides this functionality. For example, a user may use a database to persist schemas per tenant, and when they run out of space in the database, the schema service manages the functionality of getting another database to expand that space so that users do not have to manage the database themselves.

[0067] IDCS also provides data repositories that IDCS requires / generates, such as Datastore. The IDCS includes an identity store 618 (which stores users, groups, etc.), a global database 620 (which stores configuration data that IDCS uses to configure itself), an operational schema 622 (which stores customer data per customer with separate schemas per tenant), an audit schema 624 (which stores audit data), a caching cluster 626 (which stores cached objects to speed up implementation), and more. All IDCS consumers, internal and external, integrate with the identity service using standards-based protocols. This allows the domain name system ("DNS") to be used to determine where requests should be routed, decoupling consuming applications from understanding the internal implementation of the identity service.

[0068] Real-time and near-real-time tasks IDCS separates the tasks for a requested service into synchronous real-time tasks and asynchronous near-real-time tasks. Real-time tasks include only the operations necessary for the user to proceed. In one embodiment, real-time tasks are tasks that run with minimal delay, and near-real-time tasks are tasks that run in the background without the user having to wait. In one embodiment, real-time tasks are tasks that run with virtually no or very little delay, and appear to the user to run almost instantly.

[0069] Real-time tasks perform the primary business functions of a particular identity service. For example, when requesting a login service, an application sends a message to authenticate the user's credentials and obtain a session cookie for them. The user's experience is that they are logged into the system. However, several other tasks may be performed in relation to the user logging in, such as validating who the user is, auditing, sending notifications, etc. Thus, validating credentials is a task that is performed in real time, as the user is given an HTTP cookie to initiate a session, while tasks related to notifications (e.g., sending an email to notify them of the account creation), auditing (e.g., tracking / recording), etc. are near-real-time tasks that can be performed asynchronously to allow the user to proceed with minimal delay.

[0070] When an HTTP request for a microservice is received, the corresponding real-time tasks are executed by the middle-tier microservice, and the remaining near-real-time tasks, such as computational logic / events that do not necessarily undergo real-time processing, are offloaded to a message queue 628. The message queue 628 supports a highly scalable asynchronous event management system 630 with guaranteed delivery and processing. Therefore, certain behaviors are pushed from the front end to the back end, enabling IDCS to provide a high level of service to customers with low latency response times. For example, a login process may include credential validation, log report submission, and last login time update; these tasks can be offloaded to a message queue and executed near-real time instead of real time.

[0071] In one example, a system may need to register or create a new user. The system calls the IDCS SCIM API to create the user. The end result is a notification email with a link for the user to reset their password when the user is created in the identity store 618. When IDCS receives a request to register or create a new user, the corresponding microservice looks at the configuration data in the operational database (located in the global database 620 in Figure 6) and verifies that the action "user create" is registered with the "user created" event. The microservice determines that the user is being created. This operation is identified in the configuration data as an asynchronous operation. The microservice returns to the client indicating that the user creation was successful, but the actual sending of the notification email is postponed and pushed to the backend. To do so, the microservice uses messaging API 616 to queue this message to its store, queue 628.

[0072] To populate queue 628, a messaging microservice, which is an infrastructure microservice, runs continuously in the background, scanning queue 628 for events in queue 628. The events in queue 628 are processed by event subscribers 630, such as auditing, user notification, application subscription, data analytics, etc. Depending on the task indicated by the event, event subscriber 630 may communicate with, for example, audit schema 624, user notification service 634, identity event subscriber 632, etc. For example, if the messaging microservice finds a "user created" event in queue 628, it executes the corresponding notification logic and sends a corresponding email to the user.

[0073] In one embodiment, queue 628 queues operational events published by microservices 614 and resource events published by APIs 616 that manage IDCS resources.

[0074] IDCS improves system performance and user experience using a real-time caching structure. The cache itself is also provided as a microservice. IDCS implements an elastic cache cluster 626 that grows as the number of customers supported by IDCS increases. The cache cluster 626 may be implemented in a distributed data grid, which is disclosed in more detail below. In one embodiment, write-only resources bypass the cache.

[0075] In one embodiment, the IDCS runtime component publishes health and operational metrics to a public cloud monitoring module 636 that collects such metrics for public clouds, such as Oracle Corporation's Oracle Public Cloud.

[0076] In one embodiment, a user may be created using IDCS. For example, a client application 602 may issue a REST API call to create a user. The administration service (platform services at 614) delegates this call to the user manager (infrastructure library / services at 614). The user manager then creates this user in the identity store stripe for the specific tenant in the identity store 618. In the case of a "User Create Success," the user The User Manager audits the tables in the Audit Schema 624 by auditing the operation and publishes "identity.user.create.success" to the message queue 628. The Identity Subscriber 632 picks up this event and sends a "welcome" email to the newly created user containing the newly created login details.

[0077] In one embodiment, IDCS may be used to grant roles to users, which in turn may provision users for actions. For example, a client application 602 may issue a REST API call to grant a role to a user. An administration service (platform services in 614) may delegate this call to a role manager (infrastructure library / services in 614). The role manager may then grant roles in the identity store stripe for a particular tenant in identity store 618. In the case of "Role Grant Success," the role manager audits the operation against an audit table in audit schema 624 and publishes "identity.user.role.grant.success" to message queue 628. The identity subscriber 632 picks up this event and evaluates the provisioning grant policies. If there is an active application grant for the role being granted, the provisioning subscriber performs some validation, initiates account creation, calls out to the target system, creates the account in the target system, and marks the account creation as successful. Each of these functions can result in the publication of a corresponding event, such as "prov.account.create.initiate," "prov.target.create.initiate," "prov.target.create.success," or "prov.account.create.success." These events can have their own business metric, which sums the number of accounts created in the target system in the last N days.

[0078] In one embodiment, IDCS can be used for user login. For example, client application 602 may request a user login using one of the supported authentication flows. IDCS authenticates the user and, if successful, audits the operation against an audit table in audit schema 624. If unsuccessful, IDCS audits the failure in audit schema 624 and publishes a "login.user.login.failure" event in message queue 628. A login subscriber picks up this event, updates its metrics for the user, and determines whether additional analysis of the user's access history needs to be performed.

[0079] Thus, by providing "inversion of control" functionality (e.g., altering the flow of execution to schedule an operation for execution at a later point in time so that the operation is under the control of another system), embodiments can dynamically add other event queues and subscribers to test new features on a small sample of users before deploying them to a wider user base, or to handle specific events for specific internal or external customers.

[0080] Stateless Functions IDCS microservices are stateless, meaning that the microservices themselves do not maintain state. "State" refers to the data an application uses to perform its function. IDCS provides multi-tenancy by persisting all state in tenant-specific repositories within the IDCS data tier. The middle tier (i.e., the code that processes requests) does not have data stored in the same location as the application code. Therefore, IDCS is highly scalable both horizontally and vertically.

[0081] Vertical scaling (or scaling up / down) means adding resources to (or removing resources from) one node in a system and typically involves adding CPUs or memory to a single computer. Vertical scalability allows an application to scale up to the limits of its hardware. Horizontal scaling (or scaling out / in) means adding more nodes to (or removing nodes from) a system, such as adding an additional computer to a distributed software application. Horizontal scalability allows an application to scale almost infinitely, limited only by the amount of bandwidth provided by the network.

[0082] The statelessness of the IDCS middle tier makes it horizontally scalable by simply adding more CPUs to the IDCS components that run the work of your application. does not need to have a designated physical infrastructure where a particular application runs. The statelessness of the IDCS middle tier makes IDCS highly available, even when providing identity services to a large number of customers / tenants. Each pass through an IDCS application / service is CPU intensive, solely to execute the application transaction, but does not use hardware to store data. Scaling is achieved by adding more slices while the application is running, while the data for the transaction is stored in a persistence tier where more copies can be added as needed.

[0083] The IDCS web tier, middle tier, and data tier can each be scaled independently and separately. Scaling the web tier allows you to handle more HTTP requests. Scaling the middle tier allows you to support more service functions. Scaling the data tier allows you to support more tenants.

[0084] IDCS Feature View Figure 6A is an example block diagram 600b of a functional view of IDCS in one embodiment. In block diagram 600b, the IDCS functional stack includes services, shared libraries, and a data store. The services include IDCS platform services 640b, IDCS premium services 650b, and IDCS infrastructure services 662b. In one embodiment, IDCS platform services 640b and IDCS premium services 650b are separately deployed Java-based runtime services that enable the business of IDCS. IDCS infrastructure services 662b are separately deployed runtime services that provide infrastructure support for IDCS. The shared libraries include IDCS infrastructure libraries 680b, which are common code packaged as shared libraries used by IDCS services, and shared libraries. Data stores are data repositories required / generated by IDCS, including identity store 698b, global configuration 700b, message store 702b, global tenant 704b, personalization settings 706b, resources 708b, user transient data 710b, system transient data 712b, per-tenant schema (managed ExaData) 714b, operational store (not shown), caching store (not shown), etc.

[0085] In one embodiment, IDCS platform services 640b include, for example, OpenID Connect services 642b, OAuth2 services 644b, SAML2 services 646b, and SCIM++ services 648b. In one embodiment, IDCS premium services include, for example, Cloud SSO and Governance 652b, Enterprise Governance 654b, AuthN Broker 656b, Federation Broker 658b, and Private Account Management 660b.

[0086] IDCS infrastructure services 662b and IDCS infrastructure libraries 680b provide support for the functionality that IDCS platform services 640b require to perform their work. In one embodiment, IDCS infrastructure services 662b include a job scheduler 664b, a UI 666b, an SSO 668b, reports 670b, a cache 672b, storage 674b, a service manager 676b (public cloud control), and an event processor 678b (user notifications, application submissions, auditing, data analysis). In one embodiment, IDCS infrastructure libraries 680b include a data manager API 682b, an event API 684b, a storage API 686b, an authentication API 688b, an authorization API 690b, and an event processor 678b (user notifications, application submissions, auditing, data analysis). 0b, a cookie API 692b, a key API 694b, and a credentials API 696b. In one embodiment, the cloud computing service 602b (internal Nimbula) Supports the functionality of IDCS infrastructure services 662b and IDCS infrastructure libraries 680b.

[0087] In one embodiment, IDCS provides various UIs 602b for consumers of IDCS services, such as a customer end user UI 604b, a customer management UI 606b, a DevOps management UI 608b, and a login UI 610b. In one embodiment, IDCS enables application (e.g., customer applications 614b, partner applications 616b, and cloud applications 618b) integration 612b and firmware integration 620b. In one embodiment, various environments may integrate with IDCS to support their access control needs. Such integration is provided, for example, by an identity bridge 622b (which provides AD integration, WNA, and a SCIM connector), an Apache agent 624b, or an MSFT agent 626b.

[0088] In one embodiment, internal and external IDCS consumers integrate with IDCS's identity services over standards-based protocols 628b, such as OpenID Connect 630b, OAuth2 632b, SAML2 634b, SCIM 636b, and REST / HTTP 638b, allowing them to use the domain name system ("DNS") to determine where to route requests, decoupling application consumption from understanding the internal implementation of the identity services.

[0089] The IDCS functional view of FIG. 6A further includes public cloud infrastructure services that provide common functionality that IDCS relies on for user notifications (Cloud Notification Service 718b), file storage (Cloud Storage Service 716b), and metrics / alerts for DevOPs (Cloud Monitor Service (EM) 722b and Cloud Metrics Service (Graphite) 720b).

[0090] Cloud Gate In one embodiment, IDCS implements "Cloud Gate" at the web tier. Cloud Gate is a web server plugin that allows web applications to externalize user SSO to an identity management system (e.g., IDCS), similar to WebGate or WebAgent technologies that work with enterprise IDM stacks. Cloud Gate acts as a security gatekeeper that secures access to IDCS APIs. In one embodiment, Cloud Gate is implemented by a web / proxy server plugin that provides a web Policy Enforcement Point ("PEP") to protect HTTP resources based on OAuth.

[0091] Figure 7 is a block diagram 700 of an embodiment implementing Cloud Gate 702. Cloud Gate 702 runs within a web server 712 and acts as a Policy Enforcement Point ("PEP"). Policy Enforcement Points are implemented using open standards (e.g., OAuth2, OpenID IDCS Policy Decision Point (e.g., Connect) The IDCS PDP is configured to secure access to REST API resources 714 for web browsers and applications. In some embodiments, the PDP is implemented with OAuth and / or OpenID Connect microservices 704. For example, when a user browser 706 sends a request to IDCS to log in a user 710, the corresponding IDCS PDP receives the credentials. After verifying the credentials, it determines whether the credentials are sufficient (e.g., whether to require other credentials, such as a second password). In the embodiment of Figure 7, Cloud Gate 702 has local policies and can therefore act as both a PEP and a PDP.

[0092] As part of the one-time deployment, Cloud Gate 702 registers IDCS as an OAuth2 client, allowing it to request OIDC and OAuth2 operations from IDCS. It then maintains configuration information about the application's protected and unprotected resources, subject to request matching rules (e.g., how to match URLs against wildcards, regular expressions, etc.). Cloud Gate 702 can be deployed to protect different applications with different security policies, and the protected applications may be multi-tenant.

[0093] During browser-based user access, Cloud Gate 702 acts as an OIDC RP 718 that initiates the user authentication flow. If the user 710 does not have a valid local user session, Cloud Gate 702 redirects the user to the SSO microservice and participates in the OIDC "Auth Code" flow with the SSO microservice. This flow culminates in the delivery of a JWT as an identity token. Cloud Gate 708 validates the JWT (e.g., noting the signature, expiration, destination / audience, etc.) and issues a local session cookie for the user 710. It acts as a session manager 716 that secures web browser access to protected resources and issues, updates, and validates local session cookies. It also provides a logout URL for deletion of the local session cookie.

[0094] Cloud Gate 702 also acts as an HTTP Basic Auth authenticator, validating HTTP Basic Auth credentials against IDCS. This behavior is supported in sessionless and session-based (local session cookie) modes, in which case a server-side IDCS session is not created.

[0095] During programmatic access by a REST API client 708, Cloud Gate 702 can act as an OAuth2 resource server / filler 720 for the application's protected REST API 714. It checks the request for the presence of an authorization header and an access token. When a client 708 (e.g., mobile, web application, JavaScript, etc.) presents an access token (issued by IDCS) for use with the protected REST API 714, Cloud Gate 702 validates the access token (e.g., signature, expiration, audience, etc.) before allowing access to the API. The original access token is sent without modification.

[0096] Typically, OAuth is used to generate a client identity propagation token (e.g., indicating who the client is) or a user identity propagation token (e.g., indicating who the user is). In this embodiment, the implementation of OAuth in Cloud Gate is based on JWT, which defines the format of Web Tokens, for example, as provided by IETF RFC7519.

[0097] When a user logs in, a JWT is issued. The JWT is signed by IDCS to support multi-tenancy in IDCS. Cloud Gate enables multi-tenancy in IDCS by verifying the JWT issued by IDCS. Therefore, IDCS provides multitenancy both in the physical structure and in the logical business processes that support the security model.

[0098] Tenancy Types IDCS identifies three types of tenancies: customer tenancy, client tenancy, and user tenancy. Customer or resource tenancy identifies who the IDCS customer is (i.e., for whom the work is being performed). Client tenancy identifies which client application is accessing the data (i.e., which application is performing the work). User tenancy identifies which user is using an application to access the data (i.e., by whom the work is being performed). For example, if a professional services firm provides systems integration capabilities for a large discount retailer and uses IDCS to provide identity management for the large discount retailer's systems, the user tenancy corresponds to the professional services firm, the client tenancy corresponds to the application used to provide the systems integration capabilities, and the customer tenancy is the large discount retailer.

[0099] Separating and integrating these three tenancies enables multi-tenancy in cloud-based services. Typically, for on-premise software installed on physical machines on-premise, there is no need to identify these three tenancies because users must be physically present on the machine to log in. However, for cloud-based service architectures, embodiments have tokens to determine who uses which applications and accesses which resources. The three tenancies are codified by the token, enforced by Cloud Gate, and used by middle-tier business services. In one embodiment, an OAuth server generates the token. In various embodiments, the token may be used with security protocols other than OAuth.

[0100] The separation of user, client, and resource tenancy provides substantial business benefits to users of services provided by IDCS. For example, a service provider that understands the needs of a business (e.g., a health care business) and its identity management problems can purchase services provided by IDCS, develop its own backend application that consumes the IDCS services, and offer this backend application to the target business. Thus, the service provider can extend the IDCS services to provide their desired functionality and offer them to specific target businesses. The service provider does not have to build and run software to provide identity services, but instead can extend and customize the IDCS services to meet the needs of the target business.

[0101] Some known systems only account for a single tenancy, the customer tenancy. However, such systems fall short when dealing with access by a combination of users, such as customer users, customer partners, customer clients, the client themselves, or clients whose access is delegated by the customer. By defining and enforcing multiple tenancies in this embodiment, it becomes easier to specify management functions for these diverse users.

[0102] In one embodiment, an entity in IDCS belongs to only one tenant, rather than multiple tenants simultaneously, and a "tenancy" is the location where an artifact resides. Typically, there are multiple components that implement a particular function, and these components can belong to multiple tenants or can belong to the infrastructure. When the infrastructure needs to act on behalf of a tenant, it interacts with entity services on behalf of the tenant. In this case, the infrastructure itself has its own tenancy, and the customer has its own tenancy. When a request is submitted, there are multiple tenancies involved in this request.

[0103] For example, a client belonging to "Tenant 1" may make a request to obtain a token for "Tenant 2" that specifies a user in "Tenant 3." As another example, a user in "Tenant 1" may need to perform an action in an application owned by "Tenant 2." Therefore, the user must go to the resource namespace of "Tenant 2" and request a token for it. Thus, delegation of authority is achieved by specifying "who" can do "what" and to whom. As another example, a first user working for a first organization ("Tenant 1") may allow a second user working for a second organization ("Tenant 2") to access documents hosted by a third organization ("Tenant 3").

[0104] In one example, a client in "Tenant 1" may request an access token for a user in "Tenant 2" to access an application in "Tenant 3." The client may request the token by invoking an OAuth request for this token at "http: / / tenant3 / oauth / token." The client identifies itself as a client residing in "Tenant 1" by including a "Client Assertion" in the request. This Client Assertion includes a client ID (e.g., "Client 1") and a client tenancy ("Tenant 1"). As "Client 1" in "Tenant 1," the client has the right to invoke a request for a token for "Tenant 3" and desires a token for a user in "Tenant 2." Therefore, a "User Assertion" is also sent as part of the same HTTP request. The generated access token is issued in the context of the target tenancy, which is the application tenancy ("Tenant 3"), and includes the user tenancy ("Tenant 2").

[0105] In one embodiment, each tenant in the data tier is implemented as an independent stripe. From a data management perspective, artifacts reside in the tenant. From a service perspective, the service knows how to work with heterogeneous tenants, and multiple tenancies are different dimensions in the service's business functionality. Figure 8 shows an example system 800 that implements multiple tenancies in one embodiment. The system 800 includes a client 802 that requests a service provided by a microservice 804 that understands how to work with data in a database 806. This database contains multiple tenants 808, each of which contains artifacts for a corresponding tenancy. In one embodiment, the microservice 804 requests a token via https: / / tenant3 / oauth / token. The OAuth microservice is a microservice that performs the functions of the OAuth microservice in microservice 804 using data from database 806 to verify whether a client 802 request is valid and, if so, constructs a token using data from a different tenancy 808. Thus, system 800 is multi-tenant in that it can operate in a cross-tenant environment by supporting services that are provided to each tenancy as well as services that can act on behalf of various tenants.

[0106] System 800 is advantageous because microservice 804 is physically decoupled from the data in database 806, and by replicating the data closer to the client, microservice 804 can be offered as a local service to the client, and system 800 can manage the availability of the service and offer it globally.

[0107] In one embodiment, microservice 804 is stateless. This means that the machine running microservice 804 does not maintain a marker indicating the service for a particular tenant. Instead, tenancy may be marked, for example, in the host portion of the URL of an incoming request. This tenancy indicates one of the tenants 808 of database 806. When supporting a large number of tenants (e.g., millions of tenants), microservice 804 cannot have as many connections to database 806. Instead, microservice 804 uses connection pool 810, which provides the actual physical connections to database 806 in the context of a database user.

[0108] Typically, a connection is established by providing a connection string to the underlying driver or provider. The connection string is used to address a specific database or server and to provide instance and user authentication credentials (e.g., "Server=sql_box;Database=Common;User ID=uid;Pwd=password;"). Once established, a connection can be opened and closed, and properties (e.g., command timeout length or transaction, if any) can be set. The connection string contains a set of key-value pairs dictated by the data access interface of the data provider. A connection pool is a cache of database connections that is maintained so that connections can be reused when future requests to the database are needed. In connection pooling, connections are created and placed in a pool and reused so that new connections do not have to be established. For example, if 10 connections are needed between microservice 804 and database 808, connection pool 810 would have 10 open connections, all in the context of a database user (e.g., relative to a specific database user, e.g., who owns this connection, whose credentials are being validated, is it a database user, is it a system credential, etc.).

[0109] Connections in connection pool 810 are created for a system user with access to anything. Therefore, to properly handle auditing and privileges by microservice 804 processing requests on behalf of tenants, database operations are performed in the context of a "proxy user" 812 associated with the schema owner assigned to a particular tenant. This schema owner has access only to the tenancy for which this schema was created, and the value of this tenancy is the value of this schema owner. When a request is made for data in database 806, microservice 804 serves this data using a connection in connection pool 810. Thus, multitenancy is achieved by having a stateless, elastic middle-tier service that processes incoming requests in the context of (e.g., associated with) a tenant-specific data store binding built on top of data connections created in the context of (e.g., associated with) a data store proxy user associated with a resource tenancy, allowing the database to scale independently of the service.

[0110] The following provides an example of functionality for implementing the proxy user 812:

[0111]

number

[0112] In this function, microservice 804 uses a database connection in connection pool 810, but sets the "Proxy User" setting for the connection drawn from connection pool 810 to "Tenant" and performs data operations in the context of the tenant.

[0113] When striping all tables to configure different columns for different tenants in the same database, one table may contain a mix of data for all tenants. In contrast, one embodiment provides a tenant-driven data tier. This embodiment provides a different physical database for each tenant, rather than striping the same database for different tenants. For example, multitenancy is achieved using pluggable databases (e.g., Oracle Corporation's Oracle Database 12c). In this case, each tenant is assigned a separate partition. In the data tier, a resource manager processes requests and then asks for the data source for the request (separate from the metadata). This embodiment performs a runtime switch to each data source / store for each request. By isolating each tenant's data from other tenants, this embodiment provides improved data security.

[0114] In one embodiment, different tokens codify different tenancies. A URL token may identify the tenancy of the application requesting the service. An identity token may codify the identity of the user to be authenticated. An access token may identify multiple tenancies. For example, an access token may codify the tenancy that is the target of such access (e.g., the application tenancy) and the user tenancy of the user to whom access is granted. A client assertion token may identify a client ID and a client tenancy. A user assertion token may identify a user and a user tenancy.

[0115] In one embodiment, an identity token contains at least a "claim / statement" that indicates the user tenant name (i.e., where the user resides). A "claim" (as used by those skilled in the security arts) in the context of an authentication token is a statement that one entity makes about itself or another entity. A statement may be about a name, identity, key, group, permission, or capability, for example. Claims are issued by a provider and given one or more values ​​before being packaged into a security token issued by an issuer, commonly known as a security token service ("STS").

[0116] In one embodiment, the access token includes at least a claim / statement indicating the resource tenant name (e.g., customer) at the time the request for the access token was made, a claim indicating the user tenant name, a claim indicating the name of the requesting OAuth client, and a claim indicating the client tenant name. In one embodiment, the access token may be implemented according to the following JSON function:

[0117]

number

[0118] In one embodiment, the client assertion token includes at least a claim indicating the client tenant name and a claim indicating the name of the requesting OAuth client.

[0119] The tokens and / or multiple tenancies described herein may be implemented by any multi-tenant cloud-based service other than IDCS. For example, the tokens and / or multiple tenancies described herein may be implemented in a SaaS or Enterprise Resource Planning ("ERP") service.

[0120] Figure 9 is a block diagram of a network view 900 of IDCS in one embodiment. Figure 9 illustrates the network interactions between application "zones" 904 in one embodiment. Applications are divided into zones based on the level of protection required and the connectivity to various other systems (e.g., SSL zones, no SSL zones, etc.). Some application zones provide services that require access from within IDCS, some provide services that require access from outside IDCS, and some are open access. Thus, each level of protection is enforced for each zone.

[0121] In the embodiment of Figure 9, communication between services occurs using HTTP requests. In one embodiment, IDCS uses access tokens, as described herein, to provide services as well as secure access to IDCS and within IDCS itself. In one embodiment, IDCS microservices are exposed through RESTful interfaces and secured by tokens, as described herein.

[0122] In the embodiment of Figure 9, any one of various applications / services 902 may use the IDCS service by making HTTP calls to the IDCS API. In one embodiment, the HTTP request for the application / service 902 may be received by an IDCS web routing tier 912 through an Oracle public cloud load balancing external virtual IP address ("VIP") 906 (or other similar technology), a public cloud web routing tier 908, and an IDCS load balancing internal VIP appliance 910 (or other similar technology). The IDCS web routing tier 912 receives requests from outside or inside IDCS. The IDCS platform services tier 914 receives and routes the data through the IDCS platform services tier 914 or the IDCS infrastructure services tier 916. The IDCS platform services tier 914 contains IDCS microservices called from outside of IDCS, such as OpenID Connect, OAuth, SAML, and SCIM. The IDCS infrastructure services tier 916 contains support microservices called from within IDCS to support the functionality of other IDCS microservices. Examples of IDCS infrastructure microservices include UI, SSO, reporting, caching, job scheduler, service manager, and key creation functions. The IDCS cache tier 926 supports caching functionality for the IDCS platform services tier 914 and the IDCS infrastructure services tier 916.

[0123] By strengthening security for both external access to IDCS and internal access to IDCS, IDCS customers can gain outstanding security compliance for the applications they run.

[0124] In the embodiment of FIG. 9, Structured Query Language ("SQL With the exception of the data tier 918, which communicates based on OAuth 2.0, and the identity store tier 920, which communicates based on LDAP, the OAuth protocol is used to secure communication between IDCS components (e.g., microservices) within IDCS, and the same tokens used to secure access from outside IDCS are also used for security within IDCS. That is, the web routing tier 912 uses the same tokens and protocols to process incoming requests, whether the requests are received from outside or within IDCS. Therefore, IDCS enables outstanding security compliance by providing one consistent security model to protect the entire system, because the fewer security models implemented within a system, the more secure the system.

[0125] In the IDCS cloud environment, applications communicate by making network calls, which may be protocols such as HTTP, Transmission Control Protocol ("TCP"), User Datagram Protocol (UDP), and the like. Based on an applicable network protocol, such as UDP (Uniform Resource Locating Protocol) For example, application "X" may communicate with application "Y" over HTTP by exposing application "Y" as an HTTP Uniform Resource Locator ("URL"). In one embodiment, "Y" is an IDCS microservice that exposes multiple resources, each corresponding to a function. When "X" (e.g., another IDCS microservice) needs to call "Y," it constructs a URL that includes "Y" and the resource / function that needs to be invoked (e.g., https: / host / Y / resource) and makes the corresponding REST call that is routed through the web routing layer 912 to "Y."

[0126] In one embodiment, callers outside of IDCS may not need to know where "Y" is located, but the web routing layer 912 does need to know where application "Y" is running. In one embodiment, IDCS provides discovery functionality (enabled by OAuth services) to determine where each application is running, eliminating the need for availability of static routing information.

[0127] In one embodiment, an enterprise manager ("EM") 922 provides a "single pane of glass" that extends on-premise and cloud-based management to IDCS. In one embodiment, Chef Software's configuration management tool, "Chef" Server 924 provides configuration management functionality for the various IDCS tiers. In one embodiment, service deployment infrastructure and / or persistent storage module 928 may send OAuth2 HTTP messages to IDCS web routing tier 912 for tenant lifecycle management operations, public cloud lifecycle management operations, or other operations. In one embodiment, IDCS infrastructure services tier 916 may send ID / password HTTP messages to public cloud notification service 930 or public cloud storage service 932.

[0128] Cloud Access Control - SSO One embodiment supports lightweight cloud standards to achieve a cloud-scale SSO service. Examples of lightweight cloud standards include HTTP, REST, and standards that provide access through a browser (because web browsers are lightweight). Conversely, SOAP is an example of a heavy cloud standard that requires more administration, configuration, and tooling to build clients. This embodiment uses OpenID Connect semantics for applications to request user authentication from IDCS. This embodiment uses lightweight HTTP cookie-based user session tracking to track a user's active session in IDCS without stateful server-side session support. This embodiment uses JWT-based identity tokens to map authenticated identities back to their local sessions for consuming applications. This embodiment supports integration with federated identity management systems and exposes SAML IDP support in enterprise deployments to request user authentication from IDCS.

[0129] Figure 10 is a block diagram 1000 of a system architecture view of SSO functionality within IDCS in one embodiment. This embodiment allows client applications to drive standards-based web protocols to initiate user authentication flows. Applications requesting SSO integration with cloud systems may reside in a corporate data center, a remote partner data center, or be operated by an on-premises customer. In one embodiment, different IDCS platform services enable the SSO business, including OpenID Connect for handling login / logout requests from connected native applications (i.e., applications that use OpenID Connect to integrate with IDCS), a SAML IDP service for handling browser-based login / logout requests from connected applications, a SAML SP service for coordinating user authentication against an external SAML IDP, and an internal IDCS SSO service for coordinating end-user login ceremonies, including local or federated login flows, and managing IDCS-hosted session cookies. Generally, HTTP works with or without forms. When working with forms, the form is the one visible in the browser. When working without forms, it functions as client-to-server communication. Both OpenID Connect and SAML require the ability to render forms, which is accomplished by the presence of a browser or virtually performed by an application that functions as if a browser were present. In one embodiment, an application client that accomplishes user authentication / SSO through IDCS must be registered as an OAuth2 client in IDCS and must obtain a client identifier and credentials (e.g., ID / password, ID / certificate, etc.).

[0130] The example embodiment of Figure 10 shows the OAut as two platform microservices. The IDCS includes three components / microservices that collectively provide login functionality, including h2 1004 and SAML2 1006, and SSO 1008 as an infrastructure microservice. In the embodiment of Figure 10, IDCS provides an "identity metasystem." In this metasystem, SSO service 1008 is provided to different types of applications, such as a browser-based web or native application 1010 that requires a three-party OAuth flow and acts as an OpenID Connect relaying party ("RP," an application that outsources its user authentication function to an IDP), a native application 1011 that requires a two-party OAuth flow and acts as an OpenID Connect RP, and a web application 1012 that acts as a SAML SP.

[0131] In general, an identity metasystem is an interoperable architecture for digital identity, allowing for the use of multiple underlying technologies, implementations, and a collection of providers. LDAP, SAML, and OAuth are examples of different security standards that provide identity functionality and can serve as the basis for building applications, and an identity metasystem may be configured to provide a unified security system for such applications. The LDAP security model specifies specific mechanisms for handling identities, and all paths through the system must be strictly protected. SAML was developed to allow one set of applications to securely exchange information with another set of applications that belong to a different organization in a different security domain. Because there is no trust between these two applications, SAML was developed to allow one application to authenticate another application that does not belong to the same organization. OAuth provides OpenID Connect, a lightweight protocol for performing web-based authentication.

[0132] In the embodiment of FIG. 10 , when an OpenID application 1010 connects to an OpenID server in IDCS, its “channel” requests SSO services. Similarly, when a SAML application 1012 connects to a SAML server in IDCS, its “channel” also requests SSO services. In IDCS, each microservice (e.g., OpenID microservice 1004 and SAML microservice 1006) handles each application, and these microservices request SSO functionality from SSO microservice 1008. This architecture can be extended to support any number of other security protocols by adding a microservice for each protocol and then using SSO microservice 1008 for SSO functionality. SSO microservice 1008 issues sessions (i.e., is provided with SSO cookie 1014) and is the only system with authority to issue sessions in this architecture. The IDCS session is realized by browser 1002 through its use of SSO cookie 1014. Browser 1002 also manages its local session using local session cookie 1016.

[0133] In one embodiment, for example, within a browser, a user may log in using a first application based on SAML and then use a second application built using a different protocol, such as OAuth. The user is given SSO on the second application within the same browser. Thus, the browser is the state or user agent and manages cookies.

[0134] In one embodiment, the SSO microservice 1008 handles login ceremony 1018, ID / password recovery 1020, first login flow 1022, authentication management The system provides a login ceremony 1018, an HTTP cookie manager 1024, an HTTP cookie manager 1026, and an event manager 1028. The login ceremony 1018 realizes the SSO functionality based on customer settings and / or application context and may be configured according to a local form (e.g., Basic Auth), an external SAML IDP, an external OIDC IDP, etc. The ID / password recovery 1020 is used to recover a user's ID and / or password. The first login flow 1022 is realized the first time a user logs in (i.e., an SSO session does not yet exist). The authentication manager 1024 issues an authentication token upon successful authentication. The HTTP cookie manager 1026 stores the authentication token in an SSO cookie. The event manager 1028 publishes events related to the SSO functionality.

[0135] In one embodiment, the interaction between the OAuth microservice 1004 and the SSO microservice 1008 is based on a browser redirect, and the SSO microservice 1008 challenges the user with an HTML form, validates the credentials, and issues a session cookie.

[0136] In one embodiment, for example, OAuth microservice 1004 receives an authentication request from browser 1002 and authenticates the user of the application according to a three-party OAuth flow. Thus, OAuth microservice 1004 acts as an OIDC provider 1030 and redirects browser 1002 to SSO microservice 1008 and proceeds with the application context. Depending on whether the user has a valid SSO session, SSO microservice 1008 either validates the existing session or performs a login ceremony. If the authentication or validation is successful, SSO microservice 1008 returns the authentication context to OAuth microservice 1004. OAuth microservice 1004 then redirects browser 1002 to a callback URL with an authorization ("AZ" code). Browser 1002 sends the AZ code to OAuth microservice 1004 and requests the required token 1032. Browser 1002 also includes its client credentials (obtained when registering IDCS as an OAuth2 client) in the HTTP Authorization header. In response, OAuth microservice 1004 provides the requested token 1032 to browser 1002. In one embodiment, the token 1032 provided to browser 1002 includes a JW identity and an access token signed by the IDCS OAuth2 server. Further details of this functionality are disclosed below with reference to FIG. 11.

[0137] In one embodiment, for example, OAuth microservice 1004 receives an authorization request from native application 1011 and authenticates the user according to a two-party OAuth flow, where authentication manager 1034 of OAuth microservice 1004 performs the corresponding authentication (e.g., based on the ID / password received from client 1011), and token manager 1036 issues the corresponding access token upon successful authentication.

[0138] In one embodiment, for example, SAML microservice 1006 receives an SSO POST request from a browser and authenticates the user of web application 1012, which acts as a SAML SP. SAML microservice 1006 then acts as a SAML IDP 1038 and redirects browser 1002 to SSO microservice 1008, following the application context. Depending on whether the user has a valid SSO session, SSO microservice 1008 either validates the existing session or performs a login ceremony. Upon successful authentication or validation, SSO microservice 1008 passes the authentication context to SAML microservice 1008. 6. The SAML microservice then redirects back to the SP with the required token.

[0139] In one embodiment, for example, the SAML microservice 1006 may act as a SAML SP 1040 and communicate with a remote SAML IDP 1042 (e.g., an active directory federation service (“ADFS”) One embodiment implements the standard SAML / AD flow. In one embodiment, the interaction between the SAML microservice 1006 and the SSO microservice 1008 is based on a browser redirect, and the SSO microservice 1008 challenges the user with an HTML form, validates the credentials, and issues a session cookie.

[0140] In one embodiment, interactions between components within the IDCS (e.g., 1004, 1006, 1008) and components external to the IDCS (e.g., 1002, 1011, 1042) occur through a firewall 1044.

[0141] Login / Logout Flow Figure 11 illustrates a message sequence flow 1100 for SSO functionality provided by IDCS in one embodiment. When a user uses a browser 1102 to access a client 1106 (e.g., a browser-based application or a mobile / native application), Cloud Gate 1104 acts as an application enforcement point and enforces policies defined in a local policy text file. If Cloud Gate 1104 detects that the user does not have a local application session, it requests the user's authentication. To do so, Cloud Gate 1104 initiates an OpenID Connect login flow to OAuth2 microservice 1110 by redirecting browser 1102 to OAuth2 microservice 1110 (a three-way AZ Grant flow with scope="openid"). profile").

[0142] The browser 1102 request traverses the IDCS routing tier web service 1108 and Cloud Gate 1104 to the OAuth2 microservice 1110. The OAuth2 microservice 1110 constructs an application context (i.e., metadata describing the application, such as the connecting application's identity, client ID, configuration, what the application can do, etc.) and redirects the browser 1102 to the SSO microservice 1112 for login.

[0143] If the user has a valid SSO session, the SSO microservice 1112 validates the existing session without initiating a login ceremony. If the user does not have a valid SSO session (i.e., no session cookie exists), the SSO microservice 1112 initiates a user login ceremony according to the customer's login preferences (e.g., displaying a branded login page). To do so, the SSO microservice 1112 redirects the browser 1102 to a login application service 1114, which is implemented in JavaScript. The login application service 1114 provides the browser 1102 with a login page. The browser 1102 sends a REST POST containing the login credentials to the SSO microservice 1112. The SSO microservice 1112 generates an access token and sends it in a REST POST to Cloud Gate 1104. Cloud Gate 1104 verifies the user's password by sending the authentication information to the administration SCIM microservice 1116. The administration SCIM microservice 1116 determines that the authentication was successful and sends a corresponding message to the SSO microservice 1112.

[0144] In one embodiment, during the login ceremony, the login page does not display a consent page because the "login" operation does not require further consent. Instead, a privacy policy is posted on the login page that informs the user about the specific profile attributes that are exposed to the application. During the login ceremony, the SSO microservice 1112 honors the customer's IDP preferences and, if configured, redirects to the IDP for authentication against the configured IDP.

[0145] Upon successful authentication or validation, SSO microservice 1112 redirects browser 1102 back to OAuth2 microservice 1110 with a newly created / updated SSO host HTTP cookie (e.g., a cookie created in the context of the host indicated by "HOSTURL") that contains the user's authentication token. OAuth2 microservice 1110 returns an AZ code (e.g., an OAuth concept) to browser 1102, which redirects to Cloud Gate 1104. Browser 1102 sends the AZ code to Cloud Gate 1104, which sends a REST POST to OAuth2 microservice 1110 requesting an access token and an identity token. Both of these tokens are scoped to OAuth microservice 1110 (indicated by the audience token claim). Cloud Gate 1104 receives these tokens from OAuth2 microservice 1110.

[0146] Cloud Gate 1104 uses the identity token to map the authenticated user's identity to their internal account representation, and it may store this mapping in its HTTP cookie. Cloud Gate 1104 then redirects browser 1102 to client 1106. Browser 1102 then reaches client 1106 and receives a corresponding response from client 1106. From this point on, browser 1102 can seamlessly access the application (i.e., client 1106) as long as the application's local cookie is valid. If the local cookie becomes invalid, the authentication process repeats.

[0147] Cloud Gate 1104 also retrieves "userinfo" from the OAuth2 microservice 1110 or from the SCIM microservice using the access token included in the request. This access token is sufficient to access the "userinfo" resource for attributes granted by the "profile" scope. It is also sufficient to access the " / me" resource via the SCIM microservice. In one embodiment, by default, the included access token is only sufficient for user profile attributes granted under the "profile" scope. Access to other profile attributes is authorized based on additional (optional) scopes presented in the AZ Grant Login request issued by Cloud Gate 1104.

[0148] If the user accesses another OAuth2 integrated application, the same process is repeated.

[0149] In one embodiment, the SSO integration architecture uses a similar OpenID Connect user authentication flow for browser-based user logout. In one embodiment, a user with an existing application session accesses Cloud Gate 1104 to initiate the logout. Alternatively, the user may have initiated the logout on the IDCS side. Cloud Gate 1104 terminates the application-specific user session and initiates an OAuth2 OpenID Provider (“OP”) logout request to OAuth2 microservice 1110. The OAuth2 microservice The SSO microservice 1110 redirects to the SSO microservice 1112, which deletes the user's host SSO cookie. The SSO microservice 1112 initiates a set of redirects (OAuth2 OP and SAML IDP) to known logout endpoints tracked in the user's SSO cookie.

[0150] In one embodiment, when Cloud Gate 1104 requests user authentication (e.g., login) using the SAML protocol, a similar process is initiated between the SAML microservice and the SSO microservice 1112.

[0151] Cloud Cache One embodiment provides a service / feature called Cloud Cache. Cloud Cache is provided to IDCS to support communication with LDAP-based applications (e.g., email servers, calendar servers, some business applications, etc.) because IDCS does not communicate according to LDAP, but such applications are configured to communicate only based on LDAP. Typically, cloud directories are exposed via REST APIs and do not communicate according to the LDAP protocol. Managing LDAP connections through a corporate firewall generally requires specialized configurations that are difficult to set up and manage.

[0152] To support LDAP-based applications, Cloud Cache translates LDAP communications into a protocol suitable for communicating with the cloud system. Typically, LDAP-based applications use a database through LDAP. Alternatively, the application may be configured to use a database through a different protocol, such as SQL. However, LDAP provides a hierarchical representation of resources in a tree structure, while SQL represents data as tables and fields. Therefore, LDAP may be more desirable for search functions, while SQL may be more desirable for transactional functions.

[0153] In one embodiment, services provided by IDCS can be used by LDAP-based applications to, for example, authenticate users of the application (i.e., identity services) or enforce security policies for the application (i.e., security services). In one embodiment, the interface with IDCS is through a firewall and based on HTTP (e.g., REST). Typically, corporate firewalls do not allow access to internal LDAP communications, even if those communications implement Secure Sockets Layer ("SSL"). Also, corporate firewalls do not allow TCP ports to be exposed through the firewall. However, Cloud Cache translates between LDAP and HTTP, allowing LDAP-based applications to reach services provided by IDCS, and the firewall is open to HTTP.

[0154] Typically, an LDAP directory may be used in a line of business, such as marketing and development, to define users, groups, tasks, etc. In one example, a marketing and development business may serve a variety of customers, each of which may have its own applications, users, groups, tasks, etc. Another example of a line of business that may implement an LDAP cache directory is a wireless service provider. In this case, each call made by a user of the wireless service provider authenticates the user's device against the LDAP directory, and some of the corresponding information in the LDAP directory may be synchronized with a billing system. In these examples, LDAP may be implemented Provides the ability to physically separate content that is searched at runtime.

[0155] In one example, a wireless service provider may use services provided by IDCS to support short-term marketing campaigns, while handling its own identity management services for its core business (e.g., regular calls). In this case, Cloud Cache "flattens" LDAP to the point where it has a set of users and a set of groups running against the cloud. In one embodiment, any number of Cloud Caches may be implemented in IDCS.

[0156] Distributed Data Grid In one embodiment, the cache cluster in IDCS is implemented based on a distributed data grid, such as that disclosed in U.S. Patent Publication No. 2016 / 0092540, the disclosure of which is incorporated herein by reference. A distributed data grid is a system in which a collection of computer servers in one or more clusters in a distributed or clustered environment work together to manage information and related operations, such as computation. A distributed data grid can be used to manage application objects and data shared among servers. A distributed data grid provides low response times, high throughput, predictable scalability, continuous availability, and reliability of information. As a specific example, a distributed data grid, such as Oracle's Oracle Coherence data grid, achieves higher performance by storing information in-memory and uses redundancy to maintain synchronized copies of information across multiple servers, ensuring system resilience in the event of a server failure and continuous availability of data.

[0157] In one embodiment, IDCS implements a distributed data grid, such as Coherence. Coherence allows all microservices to request access to a shared cache object without being blocked. Coherence is a Coherence is a proprietary Java-based in-memory data grid designed for higher reliability, scalability, and performance compared to traditional management systems. Coherence is a peer-to-peer (i.e., no central manager) in-memory data grid. Provides a distributed cache.

[0158] 12 illustrates an example of a distributed data grid 1200 that stores data, provides data access rights to clients 1250, and implements embodiments of the present invention. A "data grid cluster" or "distributed data grid" is a system that includes multiple computer servers (e.g., 1220a, 1220b, 1220c, and 1220d) that work together in one or more clusters (e.g., 1200a, 1200b, 1200c) to store information and manage related computations and other operations within a distributed or clustered environment. While the distributed data grid 1200 is shown as including four servers 1220a, 1220b, 1220c, and 1220d in cluster 1200a, along with five data nodes 1230a, 1230b, 1230c, 1230d, and 1230e, the distributed data grid 1200 may include any number of clusters and any number of servers and / or nodes in each cluster. In one embodiment, a distributed data grid 1200 implements the present invention.

[0159] As shown in Figure 12, a distributed data grid provides data storage and management capabilities by distributing data across multiple servers (e.g., 1220a, 1220b, 1220c, and 1220d) working together. Each server in a data grid cluster may be based on "commodity x86" server hardware, e.g., with one to two processor sockets and two to four CPU cores per processor socket. The servers may be conventional computer systems, such as a cloud platform. Each server (e.g., 1220a, 1220b, 1220c, and 1220d) is configured with one or more CPUs, a network interface card ("NIC"), and memory, including, for example, a minimum of 4 GB of RAM and a maximum of 64 GB or more of RAM. Server 1220a is shown as having CPU 1222a, memory 1224a, and NIC 1226a (these elements are also present on the other servers 1220b, 1220c, and 1220d but are not shown). Optionally, each server may be equipped with flash memory (e.g., SSD 1228a) to provide excess storage capacity. When provided, the SSD capacity is preferably 10 times the size of the RAM. The servers (eg, 1220a, 1220b, 1220c, 1220d) of the data grid cluster 1200a are connected to a high performance network switch 1220 (eg, Gigabit or higher Ethernet) using high bandwidth NICs (eg, PCI-X or PCIe).

[0160] Cluster 1200a preferably includes a minimum of four physical servers to avoid the possibility of data loss during a failure, although typical installations have many more. The more servers there are in each cluster, the more efficient the failover and failback will be, and the less impact a server failure will have on the cluster. To minimize communication time between servers, each data grid cluster is ideally limited to a single switch 1202 that provides single-hop communication between servers. In this way, the cluster is limited by the number of ports on switch 1202. Thus, a typical cluster will include between 4 and 96 physical servers.

[0161] Distributed Data Grid 1200 Most Wide Area Networks In a distributed data grid ("WAN") configuration, each data center in the WAN has independent but interconnected data grid clusters (e.g., 1200a, 1200b, and 1200c). A WAN may include more clusters than those shown in FIG. 12, for example. Additionally, by using interconnected but independent clusters (e.g., 1200a, 1200b, 1200c) and / or by locating the interconnected but independent clusters in data centers that are separate from one another, a distributed data grid can guarantee data and services to clients 1250 to prevent the simultaneous loss of all servers in a cluster due to natural disasters, fires, floods, extended power outages, etc.

[0162] One or more nodes (e.g., 1230a, 1230b, 1230c, 1230d, and 1230e) run on each server (e.g., 1220a, 1220b, 1220c, 1220d) of cluster 1200a. In a distributed data grid, a node may be, for example, a software application, a virtual machine, etc., and a server may include an operating system, hypervisor, etc. (not shown) on which the node runs. In an Oracle Coherence data grid, each node is a Java virtual machine ("JVM"). There may be many JVMs / nodes on each server, depending on the CPU processing power and memory available on the server. JVMs / nodes may be added, started, stopped, and removed depending on the needs of the distributed data grid. JVMs running Oracle Coherence automatically join and form a cluster upon startup. JVMs / nodes that join a cluster are called cluster members or cluster nodes.

[0163] Each client or server may include a bus or other communication mechanism for communicating information, and a processor coupled to the bus for processing information. The processor may be any type of general-purpose or special-purpose processor. Each client or server may further include memory for storing information and instructions executed by the processor. The memory may include: It may be comprised of a combination of random access memory ("RAM"), read-only memory ("ROM"), static storage such as a magnetic or optical disk, or any other type of computer-readable medium. Each client or server may further include a communications device such as a network interface card to provide access to a network. Thus, a user may interface with each client or server directly, remotely through a network, or by any other means.

[0164] Computer-readable media can be any available media that can be accessed by a processor and includes both volatile and nonvolatile media, removable and non-removable media, and communication media, which may include computer-readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery media.

[0165] The processor may also be coupled via the bus to a display, such as a liquid crystal display ("LCD"), A keyboard and cursor control device, such as a computer mouse, may also be coupled to the bus to allow a user to interface with each client or server.

[0166] In one embodiment, the memory stores software modules that, when executed by the processor, provide functionality. The modules include an operating system that provides operating system functionality for each client or server. The modules may further include a cloud identity management module for providing cloud identity management functionality, and any other functionality disclosed herein.

[0167] The client may access a web service, such as a cloud service. In one embodiment, the web service may be implemented on Oracle's WebLogic Server. Other embodiments may use other implementations of web services. The web service accesses a database that stores cloud data.

[0168] Inter-regional trust Generally, Oracle Public Cloud ("OPC") Such public clouds provide virtual machines ("VMs"), applications, and Public clouds are intended to provide and support IaaS, PaaS, and SaaS services to customers worldwide by making resources, such as infrastructure, software, and storage, available to the general public over the Internet. Public clouds are known for having multiple data centers, each located in a different geographic region, to provide services with minimal latency to customers located closest to each data center. In embodiments, public cloud services may be deployed in different data centers serving customers that are separated by physical boundaries called "regions."

[0169] FIG. 13 illustrates a public cloud 1300 with multiple deployed data centers (denoted "DC"), each forming a "region," according to one embodiment. For example, data center 1301 is located in a city in Canada, data center 1302 is located in a city in Germany, and data center 1303 is located in a city in Australia. In an embodiment, one or more data centers are integrated into a single "island" managed by one or more "control plane" deployments (denoted "CP"). An island is a collection of regions integrated into a single "cloud" and managed by a single control plane. For example, control plane 1310 may be deployed across data centers 1301, 1304, 1305, 1306, and 1307, while control plane 1311 manages data centers 1308 and 1309. A typical control plane deployment can serve one or more regions based on scalability requirements and customer load in each region. In one embodiment, in situations where a control plane component serves more than one region, this component requires authorization to interact with all regions with a single identity.

[0170] A customer account is managed by cloud 1300 for each user / customer who purchases / acquires various public cloud services. One type of service available to customers may be the multi-tenant identity management service, or IDCS, disclosed above, which may be implemented as a control plane component and deployed separately in every region (i.e., every data center) to protect resources in that region. As noted above, in one embodiment, a control plane component not deployed in a particular region requires unique permissions to interact with components or tenants in regions where it is not deployed. For example, a control plane component designated for one region may want to access an IDCS customer tenancy located in another region (i.e., hosted in a different IDCS deployment). This requires that trust be established between these deployments so that components / customers assigned to IDCS in one region can make IDCS API calls to IDCS in another region (e.g., to access specific microservices among IDCS microservices 614 in FIG. 6 ). Known solutions currently allow a user who is designated and assigned to a region to access resources only in this region and not in other regions, and to be authenticated only from this region and not from other regions.

[0171] In contrast, in embodiments, a user with a new access token, called a "global access token" or "token" in one region, can use this token to access resources in another region (i.e., a remote region). Embodiments address how to establish trust between regions to manage various IDCS regions to provide resources and authentication capabilities wherever the user / customer is located. Generally, a global access token must be given to the user to enable cross-region trust functionality. This token is then consumed by the destination security center.

[0172] For example, a "client" (i.e., any application or programmatic approach for accessing a user or service) may exist only in Chicago data center 1307 (where this data center was originally built). Each client has its own identity and must validate it to obtain a token. Assume that the client does not exist or have a footprint in any of the other data centers (i.e., IDCS deployments in other data centers) of cloud 1300, such as data center 1303 located in Sydney. Therefore, even if the client is physically located near Sydney, it is not present in Sydney and cannot authenticate to the Sydney data center. To solve this problem, embodiments provide the necessary cross-regional trust by generating a global access token. Thus, after authenticating in Chicago, the client would request recovery of the global access token in Sydney. Chicago DC 1307 generates the token and signs it with a global private key, which is available in all DCs. In embodiments, the global access token is used to access only IDCS REST APIs, and therefore, using this token to access non-IDCS REST APIs across multiple regions is not supported. An error will occur.

[0173] When presented, the IDCS deployment in Sydney DC1303 consumes and validates the token. The client can then access resources in Sydney, even though it is not designated in Sydney. In an embodiment, the client only needs to be designated in one IDCS deployment, but can still access resources in other deployments.

[0174] 14 is a flow diagram of a function for accessing resources at a remote data center using a regional multi-tenant cloud-based IAM system, according to one embodiment. In one embodiment, the functions of the flow diagram of FIG. 14 are implemented by software stored in memory or other computer-readable or tangible medium and executed by a processor. In other embodiments, the functions may be implemented by hardware (e.g., through the use of application-specific integrated circuits ("ASICs"), programmable gate arrays ("PGAs"), field-programmable gate arrays ("FPGAs"), etc.), or any combination of hardware and software.

[0175] At 1402, a client or any infrastructure component desires to access a resource in a region where the client does not have a physical footprint (i.e., a remote region where the client is not an enrolled customer or where the client is not registered). In one embodiment, the "resource" is accessed by invoking an IDCS API on an IDCS deployment located in this remote region, where the resource is an IDCS REST API resource. The IDCS API may correspond to one of many microservices for performing IDCS tasks, such as microservice 614 in FIG. 6, or may be a REST API as described with respect to 714 in FIG. 7. In an embodiment, the client may access a PaaS Service Manager (PSM), a tenant automation system, or a service provider. It may also be an Oracle cloud control plane instance, such as a Tenant Automation System (“TAS”), storage control plane, etc.

[0176] At 1404, the client obtains a global access token in the region where the client has a footprint or is registered (i.e., a different data center / region where the desired resources are managed). This token can be redeemed in another region on the same island, in one embodiment, or in any other region of public cloud 1300, in another embodiment. In one embodiment, a client is registered in only one IDCS region / deployment.

[0177] At 1406, the global access token is then validated in a remote region (i.e., a region where the client does not have a physical footprint). In one embodiment, a "global access token issuer" verifies the authority of the token acquisition request by checking the client's role membership (referred to as a "global client role") and issues a global access token to the client. In one embodiment, the infrastructure component sends the operation request along with the global access token to a target endpoint that may be located in a different region than the region where the token was issued.

[0178] At 1408, the global access token is then used to forward this request to Cloud Gate (e.g., Cloud Gate 702 in FIG. 7) to the actual resource (i.e., IDCS in the remote region). The token is then consumed by forwarding it to an AZfilter in the remote region. The AZfilter is an authorization module deployed in IDCS that is called every time an IDCS REST API is called to ensure that the client has the necessary permissions (specified in the access token) to call this particular IDCS REST API. The Cloud Gate agent protecting the endpoint verifies that the token was issued by an IDCS deployment belonging to the same island (in one embodiment) and the signature of the signing authority using the "public key" of the "global token issuer."

[0179] At 1410, the desired resource is then accessed at the remote location. In one embodiment, we use a canonical model in which IDCS deployments in various regions of a given island are all configured to trust each other or a "globally trusted entity." Any request to perform an action in a remote region where a component does not have a physical footprint always involves a token signed by a globally trusted entity. Because the trust is pre-established, the token can be validated in any region of the island, or in other embodiments, any region of the public cloud.

[0180] In one embodiment, each IDCS deployment within an island is configured to be a global access token issuer. In one embodiment, a global access token is valid only within the island where it is issued. All global access token issuers are provisioned with a signing key called a "global signing key." In one embodiment, each IDCS deployment is provisioned with the same global signing key. In another embodiment, each IDCS deployment is provisioned with its own "authentication key" that can be used to obtain a signing key from a central authority. This authentication key can also be used to retrieve the public keys of all trusted IDCS deployments from the central authority. This also enables signing key rollover among regional IDCS deployments. In another embodiment, one or more global token issuers are deployed separately rather than combined as part of the IDCS deployment. In an embodiment, all infrastructure components with cross-region interaction requests in the island are provisioned with an OAuth client with a more privileged role (i.e., the global IDCS client role).

[0181] In embodiments, the Global IDCS Client role is an IDCS role that grants cross-region IDCS permissions to its members. In embodiments, this role is defined as an IDCS App with app id "idcs-cloudinfra- <region>" tenancy only, and "idcs-cloudinfra- <region>" can only be granted to selected control plane components in a tenant. In an embodiment, the global IDCS client role can only be granted as part of the IDCS seeding tool, which calls the / sm / v1 / AppServices endpoint to seed security artifacts for control plane components. The global IDCS client role indicates that this client can obtain a global token and recover this token equally in the local IDCS deployment as well as other remote IDCS deployments. The IDCS scope "GlobalClient" is granted to the global IDCS client role by the IDCS AZ policy. The client obtains API access permissions based on other roles it may have. In one embodiment, the global IDCS client role is defined with parameters as follows:

[0182]

number

[0183] In embodiments, the global key pair is the key for signing global tokens. This signing key pair exists in each IDCS deployment in the idcs-oracle tenancy, stored as the CROSS_IDCS_KEY alias, and is stored in the idcs-cloudinfra- <region>Used by the OAuth service to sign global tokens. The global key pair can be manually regenerated / re-uploaded using the IDCS system console. In one embodiment, all IDCS deployments have the same global key pair, so the public key of the local global key pair is also the global public key of all remote IDCS deployments. In another embodiment, each IDCS deployment has a different global key pair, so the local IDCS deployment can sign the global tokens of each remote idcs-cloudinfra- <region>It must be possible to store the global public key of the tenancy.

[0184] In one embodiment, a global token is an OAuth access token that can only be obtained by a "global IDCS client" in one region where the client has a footprint, and is signed by the OAuth server in the requesting region using a global key. In one embodiment, an OAuth access token or "identity token" includes at least a claim / statement indicating the user tenant name (i.e., the location where the user resides). A "claim" (as used by those skilled in the security field) related to an authentication token is a statement made by one entity about itself or another entity. A statement may be about, for example, a name, identity, key, group, permission, or capability. Claims are issued by a provider and given one or more values ​​before being packaged into a security token issued by an issuer, commonly known as a security token service ("STS").

[0185] In one embodiment, the access token includes at least a claim / statement indicating the resource tenant name (e.g., customer) at the time the request for the access token was made, a claim indicating the user tenant name, a claim indicating the name of the requesting OAuth client, and a claim indicating the client tenant name. In one embodiment, the access token may be implemented according to the following JSON function:

[0186]

number

[0187] In one embodiment, the client assertion token includes at least a claim indicating the client tenant name and a claim indicating the name of the requesting OAuth client.

[0188] In one embodiment, a global access token can be recovered in another region within the same island. A global access token is an access token that has the following OAuth claims, shown in bold and underlined, in addition to the standard OAuth claims of a regular OAuth access token:

[0189] [Table 1-1]

[0190] [Table 1-2]

[0191] To obtain a global access token, in one embodiment, the following sequence of events occurs in the home region of the global IDCS client (i.e., the region where the client has a physical footprint): 1. The client sends an access token request to https: / / idcs-cloudinfra- <region1>Send to .identity.oraclecloud.com / oauth2 / v1 / tokens Resource Tenancy = idcs-cloudinfra- <region1> · audience = idcs-cloudinfra- <region1>.identity.oraclecloud.com 2.「idcs-cloudinfra- <region1>The local OAuth server is responsible for handling OAuth clients. Checks whether the client's role has the "Global IDCS Client" role. 3. In a standard scenario, the client does not have the "Global IDCS Client" role, and the OAuth server sees it as a regular client and issues a regular token with authenticated permissions. 4. If the client has the "Global IDCS Client" role, a. The OAuth server assumes it needs a "global key" to sign tokens, and obtains this from the IDCS deployment configuration b. "Global Tokens" are issued with: ·token.iss = https: / / idcs-cloudinfra-uscom-central-1.identity.oraclecloud.com token.clientID =<requesting client with GlobalClient Role> token.gt = true ·token.locationID = locationID (aka islandID) ·token.audience = https: / / idcs-cloudinfra- <region1>.identity.oraclecloud.com 5. The OAuth server signs the token using the "global signing key" and returns the "global token" to the requesting client.

[0192] In one embodiment, to validate a global access token, the following sequence of events occurs in the remote regions of a global IDCS client (i.e., regions where the client does not have a physical footprint): 1. The global IDCS client attempts to access the resource by presenting the "global token." 2. This request is intercepted by IDCS Cloud Gate 3.idcs-cloudinfra- <region2>The IDCS CG registered with inspects the token and: Follow the logic 4. If the token.gt attribute is not set or is false a. The token is a normal token.

[0193] b. Get the public signing key for the resource tenancy if it is not already in the cache. c. The IDCS CG uses the public key to verify the token.

[0194] d. If the token is valid, Forward the request to IDCS e. Otherwise, send a failure response (401). 5. If the token.gt attribute is set and its value is true, this is a "global token" a. The CG calls the new GetGlobalKey(tenant) API exposed on the IDCS internal URL to retrieve the global key for the tenancy specified in the issuer element. This is necessary if different global keys are given to different deployments. Otherwise, the CG should already have the global key. Initially, the API can return this for all regions.

[0195] The b.AZ policy also introduces a new scope "GlobalIDCSClient" that allows calling the GetGlobalKey(tenant) API. This scope can only be given to the CG, since this call is only made by the CG.

[0196] c. The IDCS CG validates various aspects of the token, including the signature and revocation. Any failure to validate results in:

[0197] ·"HTTP / 1.1 401 Unauthorized WWW-Authenticate: Bearer error="invalid_token", error_description=" <text> " <text>are "token expiration", "token signature", "token audience", and "token tenant".

[0198] d. Once the signature is verified, it validates the token by "locationID", i.e. IDCS CG uses discovery API to discover local deployments. tionID".

[0199] The discovered "locationID" value is compared with the token's "token.locationID" attribute.

[0200] If they don't match, throw an "unauthorized" error. If there is a match, the CG checks whether the client also has a tenant scope. Cross-tenant scope 1. Audience URL of the access token (idcs-cloudinfra- <region1>)of Get 2. Tenant value of "Resource Tenancy" (idcs- <tenant>) and 3. Validate the target URL against the AUD claim in the access token. 6. Once the token is validated, the CG forwards the request to https: / / idcs- <tenant>.identity.oraclecloud.com / <endpoint>) to IDCS 7. The request is made to https: / / idcs- <tenant>.identity.oraclecloud.com / <endpoint>of Reach the IDCS service.

[0201] Once the token is validated, the CG forwards the request to the actual resource, in this case IDCS, to recover a global access token, which the AZ filter will consume. 1. The Authz filter in "Region 2" evaluates the authorization for the token a. The AZ filter then evaluates the scopes listed in the global access token.

[0202] If the scope is not recognized, ignore it, log an error (IDCS version mismatch), and return a 401-Unauthorized response.

[0203] If the roles do not match, ignore them and log an error. b. The AZ filter constructs an IDCS principal using the client ID stored in the global access token. c. This is audited as the actor ID in audit events when the IDCS Admin Service REST service is invoked. d.Introduce actorTenantName, which is initialized by the AZ filter and written to Audit by the event manager.

[0204] In one embodiment, downstream components must ensure that they do not attempt to locate the IDCS App using the client ID provided in the global access token, because the client is not specified there, which leads to errors in the remote IDCS deployment.

[0205] As disclosed, embodiments enable a client to access resources in a remote region or data center by requesting and receiving a new global access token from the home region, and then using this global access token to access resources in the remote region (i.e., IDCS API resources in one embodiment only). In one embodiment, the issuer of the global access token is an IDCS deployment that has been provisioned with a global signing key, and the token has specialized token claims specific to the global access or resource.

[0206] Although several embodiments have been specifically illustrated and / or described herein, modifications and variations of the disclosed embodiments are within the spirit and intended scope of the invention. It will be appreciated that the teachings above are covered by the present invention without departing from the spirit and scope of the following claims.< / endpoint> < / tenant> < / endpoint> < / tenant> < / tenant> < / text> < / text> < / region> < / region> < / region> < / region>

Claims

1. A multi-tenant cloud system, a first data center adapted to authenticate a first plurality of registered clients and located in a first geographic region; a second data center adapted to authenticate a second plurality of registered clients and located in a second geographic region different from the first geographic region; the first data center receives a request from a first client of the first plurality of registered clients to access a resource at the second data center; the first data center verifies the request from the first client and issues a global access token, the global access token being a regular OAuth token claim plus an additional token claim, the additional token claim including a location identifier identifying an island to which the first geographic region in which the first data center is located and the second geographic region in which the second data center is located belong; The second data center receives the request along with the global access token, and the multi-tenant cloud system further: a Cloud Gate at the second data center that validates the request and grants the resource to the first client based on the global access token.

2. The multi-tenant cloud system of claim 1 , wherein the additional token claims include a client tenant name, the location identifier, and a flag indicating that the OAuth token claim is the global access token.

3. The multi-tenant cloud system of claim 1 , wherein issuing the global access token includes determining whether the client has a global role.

4. The multi-tenant cloud system of claim 1 , wherein after the request is verified, the global access token is consumed by an authentication filter.

5. The multi-tenant cloud system of any one of claims 1 to 4, wherein the resources of the second data center include a representational state transfer (REST) ​​application programming interface (API) of the multi-tenant cloud system.

6. The multi-tenant cloud system according to any one of claims 1 to 5, wherein the first data center and the second data center are located on the same control plane.

7. 1. A method of operating a multi-tenant cloud system, the multi-tenant cloud system comprising: a first data center adapted to authenticate a first plurality of registered clients and located in a first geographic area; and a second data center adapted to authenticate a second plurality of registered clients and located in a second geographic area different from the first geographic area, the method comprising: receiving, at the first data center, a request from a first client of the first plurality of registered clients to access a resource at the second data center; and validating the request from the first client at the first data center and issuing a global access token, the global access token being a regular OAuth token claim plus an additional token claim, the additional token claim including a location identifier identifying an island to which the first geographic region in which the first data center is located and the second geographic region in which the second data center is located belong; The method further comprises: receiving, at the second data center, the request along with the global access token; and at a Cloud Gate at the second data center, validating the request and granting the resource to the first client based on the global access token.

8. 8. The method of claim 7, wherein the additional token claims include a client tenant name, the location identifier, and a flag indicating that the OAuth token claim is the global access token.

9. The method of claim 7 , wherein issuing the global access token comprises determining whether the client has a global role.

10. The method according to any one of claims 7 to 9, wherein after validating the request, the global access token is consumed by an authentication filter.

11. The method of any of claims 7 to 10, wherein the resources of the second data center include a representational state transfer (REST) ​​application programming interface (API) of the multi-tenant cloud system.

12. The method according to any one of claims 7 to 11, wherein the first data center and the second data center are located on the same control plane.

13. A program for causing at least one processor out of a plurality of processors to execute the method according to any one of claims 7 to 12.

Images