Cross-region trust for multi-tenant identity cloud service

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.), 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 become central concerns. Typical security issues in cloud environments are unauthorized access, account hijacking, malicious insiders, etc. Therefore, secure access is needed for cloud-based applications, applications located anywhere, and regardless of the type of device or type of user accessing the application. Summary of the Invention [Means for solving the problem]

[0004] overview An embodiment of a multi-tenant cloud system includes a first data center adapted to authenticate a first plurality of registered clients and located in a first geographic region, and 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, 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 description of the drawings]

[0005] [Figure 1] FIG. 1 is a block diagram of an example of an embodiment providing cloud-based identity management. [Diagram 2] FIG. 1 is a block diagram of an example of an embodiment providing cloud-based identity management. [Diagram 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. [Diagram 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 for implementing 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. 2 is a diagram of a message sequence flow for SSO functionality 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 in a remote data center using a regional multi-tenant cloud-based identity and access management system according to an embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0006] Detailed Description An embodiment allows 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 a variety of users, including customers, partners, and employees. Embodiments manage, control, and audit both cloud and on-premise access. 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 mid-tier environment. In one embodiment, each requested identity management service is split into real-time and near-real-time tasks. The real-time tasks are processed by the mid-tier microservices, while the near-real-time tasks are offloaded to a message queue. An embodiment enhances the security model for accessing the microservices by implementing access tokens that are consumed by the routing and mid-tiers. Thus, an embodiment provides a cloud-scale Identity and Access Management ("IAM") platform based on a multi-tenant microservices architecture. Provides 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-premise 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 be risky. For example, if there is such an inconsistency, a salesperson may continue to have access to their Customer Relationship Management ("CRM") account even after they have left for a competitor. Thus, the embodiment extends the security controls provisioned in the on-premise environment to the cloud environment. For example, if a person leaves the company, the embodiment ensures that the account is disabled both on-premise and in the cloud.

[0011] Typically, a user may access applications and / or data through a wide variety of channels, such as web browsers, desktops, mobile phones, tablets, smart watches, other wearable devices, etc. Thus, one embodiment secures access through all of these channels. For example, a user may use their mobile phone to complete a transaction that they started on their desktop.

[0012] An embodiment further manages the access of various users, such as customers, partners, employees, etc. Typically, applications and / or data may be accessed by employees as well as customers or third parties. Many known systems provide security measures when onboarding employees, but the security measures are typically not at the same level as when granting access to customers, third parties, partners, etc., resulting in security being breached by those not properly managed. However, an embodiment ensures that sufficient security measures are provided for access of 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 clouds and on-premise systems. In alternative or additional embodiments, IDCS may also manage access to public cloud services. For example, IDCS may be used to provide Single Sign On ("SSO") capabilities across such diverse services / applications / systems. can.

[0014] The embodiments are based on a multi-tenant microservices architecture for designing, building, and delivering cloud-scale software services. Multi-tenancy 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 (such as 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 through a given interface, and performed according to constraints and policies specified by the service description.

[0015] In one embodiment, microservices are independently deployable services. In one embodiment, the term microservices refers 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") resource access). PI). In one embodiment, microservices are easier to replace compared to monolithic services that perform all or many of the same functions. Additionally, each microservice may be updated without adversely affecting the other microservices, whereas 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 services in the collection of 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 tasks and implementing them in a single service. 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, the services use protocols that are small-granular and lightweight. In one embodiment, the services are independently deployable. By distributing the functionality of a system into different small services, the system becomes more cohesive and the coupling of the system is reduced. This makes it easier to change the system and to add features and quality to the system at any point in time. It also allows the architecture of the individual services to emerge through constant refactoring, thus reducing the need for large-scale up-front design and allowing for earlier and continuous releases of software.

[0017] In one embodiment, in a microservices architecture, an application is developed as a collection of services, where each service runs its own process and communicates using a lightweight protocol (e.g., a specific API for each 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 that can be contacted by others. In one embodiment, the anonymous universal port of a microservice is a standard communication channel that a traditional microservice exposes (e.g., a traditional HTTP port) and allows other modules / microservices in 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 and deliver 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 access of its employees to the enterprise's applications.

[0020] The embodiment provides system security, massive scalability, end-user usability, and application interoperability. The embodiment addresses the growth of cloud and customer use of identity services. The foundation based on microservices addresses the horizontal scalability requirements, while the tight orchestration of services addresses the functional requirements. To achieve both these goals, the business logic is decomposed (as much as possible) to eventually achieve consistent statelessness, while most of the operational logic that does not undergo 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. The embodiment is fully multi-tenant from the web tier to the data to achieve cost efficiency and ease of system management.

[0021] Embodiments may incorporate industry standards (e.g., OpenID Connect, OAuth2, Security Assertion Markup Language 2 ("SAML2"), Cross-Signal Authentication (CSA) and other standards) to facilitate integration with a variety of applications. The implementation follows standards such as System for Cross-domain Identity Management ("SCIM"), Representational State Transfer ("REST"), etc. One embodiment provides a cloud-scale API platform to enable horizontally scalable microservices for elastic scalability. The embodiment leverages cloud principles to provide a multi-tenant architecture with data isolation per tenant. The embodiment further provides per-tenant customization via tenant self-service. The embodiment provides 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. The present 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 split into real-time and near-real-time tasks. The real-time tasks are processed by the 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. Thus, an embodiment provides a cloud-scale IAM platform based on a multi-tenant microservices architecture.

[0024] Generally, known systems provide siloed access to applications provided by various environments, such as, for example, enterprise 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, an embodiment provides unified IAM capabilities for such applications by implementing IDCS. FIG. 1 is a block diagram 100 of an example embodiment using IDCS 118 that provides a unified identity platform 126 for onboarding users and applications. The embodiment provides a seamless user experience across various applications, such as enterprise cloud applications 102, partner cloud applications 104, third party cloud applications 110, and customer applications 112. Applications 102, 104, 110, 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 and secure credentials across devices and applications (via identity platform 126), and unified management (via administration 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 the like. 137) , event services 138 (e.g., REST), and role-based access control (e.g., 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-premise applications. Business practices are typically mature and standardised around an in-house IAM system such as Oracle's "Oracle IAM Suite". Small to mid-sized organisations also typically have their business processes designed around managing user access through a simple directory solution such as Microsoft Active Directory ("AD"). To enable on-premise integration, embodiments provide tools that allow 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-premise 206. The embodiment provides a seamless user experience across all applications including various applications / services in the cloud 208 such as, for example, cloud services 210, cloud applications 212, partner applications 214, and customer applications 216 as well as on-premise applications and third party applications such as on-premise applications 218. Cloud applications 212 may be, 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 / 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 provides automatic identity synchronization from on-premise AD data to cloud data via a SCIM identity bus 234 between the cloud 208 and the enterprise 206. The embodiment further provides a SAML bus 228 to federate authentication (e.g., with a password 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 passing messages from one system to another. This is useful, for example, for sharing information between trusted systems in a service oriented architecture ("SOA"). Identity bus is a controlled mechanism for exchanging information between 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 FIG. 2 implements a small binary (e.g., 1 MB 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) for organizational units ("OUs") selected by the customer. IDCS listens to user groups (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 moving 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-prem AD 204, the cloud application access change is realized in near real-time. Similarly, access to cloud applications managed by IDCS 208 for users leaving the enterprise is revoked. For full automation, the customer may set up SSO between the on-prem AD 204 and IDCS 208, for example through an AD federation service ("AD / FS" or any other mechanism that achieves SAML federation), to allow end users to access cloud applications 210, 212, 214, 216 and on-premise applications 218 using a single enterprise password 332.

[0032] FIG. 3 is a block diagram 300 of an example embodiment including the same components 202, 206, 208, 210, 212, 214, 216, 218, 220, 222, 224, 226, 228, 234 as FIG. 2. However, in the embodiment of FIG. 3, IDCS 202 provides integration with an on-premise 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-premise and third-party applications. This embodiment provisions user identities from on-premise IDM 304 to IDCS 208 via SCIM identity bus 234 between cloud 202 and enterprise 206. This embodiment further provides a SAML bus 228 (or OpenID Connect bus) for federation of authentication from cloud 208 to on-premise 206.

[0033] In the embodiment of FIG. 3, Oracle Identity Manager (Oracle Oracle Identity Manager ("OIM") Connector 302 and Oracle Access Manager ("Oracle") Oracle Access Manager ("OAM") Integration Module 306 The 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 shouldn't 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, auditing, etc. OAM has built-in support for SAML. If a user has an account in the IDCS 202, the OIM Connector 302 and OAM Federation 306 can be used 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, 234 as in FIG. 2 and FIG. 3. However, in the embodiment of FIG. 4, IDCS 202 provides functionality to extend cloud identities to on-premise applications 218. This embodiment provides a seamless view of identity across all applications, including on-premise 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-premise 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 a local network. In the embodiment of FIG. 4, the LDAP-based application 218 connects to the Cloud Cache 402, which connects to the IDCS 202 and then pulls the requested data from the IDCS 202. Communication between the IDCS 202 and the Cloud Cache 402 may be achieved according to the SCIM protocol. For example, the Cloud Cache 402 may use the SCIM bus 234 to send SCIM requests to the IDCS 202 and receive the corresponding data.

[0036] Typically, the complete realization of an application includes building a consumer portal, running marketing campaigns to external user populations, supporting web and mobile channels, 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 including the same components 202, 220, 222, 224, 226, 234, 402 as in FIGS. 2-4. However, in the embodiment of FIG. 5, IDCS 202 provides secure identity management on demand. 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-premise 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, etc.

[0038] In this embodiment, the SCIM identity bus 234 is used to synchronize data in IDCS 202 with data in on-premise 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 a component that ensures the integrity of the cloud service. Cloud Gate 502 is disclosed further below. Cloud Gate 502 (an enforcement point similar to webgate / webagent) is a component that ensures the integrity of the cloud service. This allows applications running behind a trusted web server to participate in SSO.

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

[0040] One embodiment may provide the following features: · Maintaining an identity store to track already 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 lower 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. In deploying MFA, 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 techniques. Thus, 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 IAM ("Fast Identity Provider") and fast identity online ("FIDO") authentication, 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 requiring integration between systems in hybrid IDCS and on-premise IAM environments.

[0043] One embodiment provides user provisioning and attestation. In general, a fundamental function of an IAM solution is to enable and support the entire user provisioning lifecycle. This includes giving users 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 the need for quick user deprovisioning when a user leaves the organization. This is important not only to meet various compliance requirements, but also because inappropriate insider access is a major cause of security breaches and attacks. Automated user provisioning capabilities in an identity cloud solution can be important in its own right, but also as part of a hybrid IAM solution, and thus IDCS provisioning can provide more flexibility during migration than on-premise solutions when companies are downsizing, expanding, merging, or trying to integrate existing systems with IaaS / PaaS / SaaS environments. The IDCS approach can save time and effort in one-time upgrades and ensure proper integration of departments, divisions, and systems as required. The need to scale this technology often emerges silently within the enterprise, and quickly delivering scalable IDCS capabilities across the enterprise can pay dividends in terms of flexibility, cost, and control.

[0044] Typically, employees are granted additional privileges over the years as their job roles change (i.e., "privilege creep"). Loosely 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 resulting in over-privileged accounts. Thus, an embodiment may provide a periodically performed (at least annual) attestation process. Furthermore, with mergers and acquisitions, the need for these tools and services grows exponentially as users reside in SaaS systems, on-premise, across different departments, and / or are deprovisioned or reallocated. The move to the cloud can further disrupt this situation, and things can quickly escalate beyond existing, often manually managed, attestation methods. Thus, an embodiment automates these functions and applies 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 secure an organization's risk profile. Properly deployed identity analytics can require enforcement of entire internal policies. Identity analytics that provide a unified, single management view across cloud and on-premise is highly necessary in preventative governance, risk, and compliance ("GRC") enterprise environments and can help provide a closed-loop process to reduce risk and meet compliance regulations. Thus, one embodiment provides identity analytics. Identity analytics 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] An embodiment provides self-service and access request capabilities to improve end-user experience and efficiency while reducing the cost of help desk calls. Typically, many enterprises deploy on-premise self-service access requests for their employees, but many do not adequately extend these systems outside the formal enterprise walls. A positive digital customer experience outside the scope of employee use increases business credibility and ultimately contributes to increased revenue, and enterprises not only reduce customer help desk calls but also increase customer satisfaction. Thus, an embodiment provides an identity cloud service 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 IT specialists to focus on more core business applications.

[0047] One embodiment is a system that uses privileged account management ("PAM") ) is provided. Generally, all organizations, whether using SaaS, PaaS, IaaS or on-premise applications, are vulnerable to insider abuse of privileged accounts using super-user access credentials such as system administrators, executives, human resources officers, contractors, system integrators, etc. In addition, external threats typically first compromise low-level user accounts and eventually reach and exploit privileged user access controls within the enterprise system. Thus, one embodiment provides PAM to prevent such unauthorized insider use of accounts. A key component of a PAM solution is a password vault, which may be delivered in a variety of ways. For example, it may be delivered in a variety of ways, for example, as software installed on an enterprise server, as a virtual appliance also on an enterprise server, as a packaged hardware / software appliance, or as part of a cloud service. The PAM function is similar to a physical secure location used to store passwords that are kept in an envelope and periodically changed with a manifest for signing in and signing out. One embodiment allows for password checkout as well as setting time limits, forcing period changes, tracking automatic checkouts, and reporting on all activity. One embodiment provides a way to directly connect to the requested resource without the user knowing the password. This functionality also opens the way for session management and other functions.

[0048] Generally, most cloud services utilize APIs and management interfaces, which provide opportunities for intruders to bypass security. Thus, one embodiment fills these gaps in PAM implementations, as the move to 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 have little experience dealing with this responsibility, even though PAM capabilities are included in the identity cloud service solution or are available from their IaaS / PaaS provider. Additionally, in some cases, many different geographically distributed business units seek to separate management responsibilities for the same SaaS applications. Thus, one embodiment enables customers in this situation to link their existing PAM into the overall identity framework of the identity cloud service, ensuring that it is aligned with the cloud load conditions that 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. The 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 one service based on the target functionality that the service provides (e.g., OAuth, SAML, Admin, etc.). As a result, similar APIs are not exposed as separate runtime processes. The APIs are made available to service consumers to use the services provided by IDCS.

[0050] Typically, in an 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 authorizing a user is "host / oauth / v1 / authorize". The host portion of the URL realizes the service and the resource portion of the URL realizes the API. Thus, multiple APIs are aggregated under the same microservice. In one embodiment, 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] FIG. 6 is a block diagram that provides a system view 600 of IDCS in one embodiment. In FIG. 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, or an Android operating system (e.g., an Android operating system, an iOS application, an Android application, etc.), web services, customer applications, partner applications, or Software as a Service ("SaaS"), 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 a similar technology such as a load balancer). The request is routed through a cloud provisioning engine 608, which may be a component of a cloud load balancer as a service ("LBaaS") that implements appropriate security rules to protect the traffic. However, the request may be received in any manner. At 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 reconciliation of tenants and services. 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 a customer.

[0054] The HTTP request is then received by the IDCS web routing tier 610, which provides security gates (i.e., cloud gates) and service routing as well as microservice registration and discovery 612. Depending on the service requested, the HTTP request is forwarded to IDCS microservices in the IDCS middle tier 614. The IDCS microservices handle external and internal HTTP requests. The IDCS microservices provide platform and infrastructure services. The IDCS platform services are separately deployed Java-based runtime services that enable the business of IDCS. The IDCS infrastructure services are separately deployed runtime services that provide infrastructure support for IDCS. IDCS further 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 support functionality required by the platform services to achieve their functionality.

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

[0056] The OpenID Connect Platform Services enable standard OpenID Connect login / logout flows. Interactive web-based and native applications facilitate standard browser-based OpenID Connect flows to request user authentication and receive a standard identity token, a JavaScript Object Notation ("JSON") Web Token (Web Token "JWT"), that conveys the user's authenticated identity. The OpenID Connect protocol receives a JWT identity token from the user. Internally, the runtime authentication model is stateless and maintains 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 that 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, integrating IDCS as an OIDC RP with social OIDC OPs (e.g., Facebook®, Google®, etc.) allows customers to 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 allow customers to subscribe to SAML identity providers ("IDs"). The SAML2 Platform Service enables SAML2 users to set up federation agreements with their partners based on a SAML service provider ("P") and SAML service provider ("SP") relationship model. In one embodiment, the SAML2 Platform Service implements standard SAML2 browser post login and logout profiles. In one embodiment, the SAML functionality is implemented in accordance with, for example, IETF, RFC7522.

[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 allows customers to access the IDP feature 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 Administration 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 Administration Service leverages and extends the SCIM standard to provide Create, Read, Update, Delete, and Query ("CRUD") operations on all IDCS resources. The IDCS provides a schema-based REST API for its "IDCS Q" (Security Entity Framework) 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 further IDCS internal resources (e.g., password policies, roles, settings, etc.) using the language defined by the SCIM standard.

[0062] The Administration Service supports the SCIM 2.0 standard endpoints using the standard SCIM 2.0 core schema and, where necessary, schema extensions. In addition, the Administration Service supports several SCIM 2.0 compliant endpoint extensions to manage other IDC resources, such as users, groups, applications, settings, etc. The Administration Service also does not perform CRUDQ operations but instead provides functional services, For example, "UserPasswordGenerator", "UserPasswordValidator", etc. are provided, providing a remote procedure call-style ("RPC-style") ") 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 must first Requests an access token from the OAuth2 service. After obtaining the 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 (to asynchronously handle user notifications, application submissions, and audits against the database), a job scheduler service (to schedule and execute jobs, e.g., to execute long-running tasks immediately or at a set time that do not require user intervention), a cache management service, a storage management service (to integrate with public cloud storage services), a reporting service (to generate reports and dashboards), an SSO service (to manage internal user authentication and SSO), a user interface ("UI") service (to host 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. Schema services allow you to delegate the responsibility of managing database schema to IDCS. Therefore, users of IDCS do not need to manage databases because there are IDCS services that provide this functionality. For example, users may use a database to persist the schema per tenant, and when there is no space left in the database, the schema service manages the functionality of getting another database to expand the space so that users do not have to manage the database themselves.

[0067] IDCS also provides a repository of data that IDCS requires and generates. 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 schema per tenant), an audit schema 624 (which stores audit data), a caching cluster 626 (which stores cached objects to speed up implementation), etc. All IDCS consumers, internal and external, integrate with the identity service according to standards-based protocols. This allows the domain name system ("DNS") to be used to determine where to route requests, decoupling consuming applications from understanding the internal implementation of the identity service.

[0068] Real-time and near-real-time tasks IDCS separates the tasks of a requested service into synchronous real-time tasks and asynchronous near-real-time tasks. Real-time tasks contain 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 functionality 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 the same. What the user experiences is that they are logged into the system. However, several other tasks may be performed related to the user being logged in, such as validating who the user is, auditing, sending notifications, etc. Thus, validating the credentials is a task that is performed in real-time, as the user is given an HTTP cookie and initiates a session, while tasks related to notifications (e.g. sending an email to notify 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 microservices, 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. Thus, certain behaviors are pushed from the front-end to the back-end, enabling IDCS to provide a high level of service to customers by reducing response time latency. For example, a login process may include validating credentials, submitting log reports, updating last login time, etc., but these tasks can be offloaded to a message queue and executed in 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 this 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 create" event. The microservice determines that the user is being queued for creation, which 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 and scans 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 uses real-time caching structures to improve system performance and user experience. The cache itself is also offered as a microservice. IDCS implements an elastic cache cluster 626 that scales with the number of customers supported by IDCS. 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, which 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 a user manager (infrastructure libraries / services at 614). The user manager then creates the user in the identity store stripe for the specific tenant in identity store 618. In the case of "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 so that they can be provisioned 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 at 614) may delegate this call to a role manager (infrastructure libraries / services at 614). The role manager may then grant roles in the identity store stripe for a particular tenant in identity store 618. In case of "Role Grant Success", the Role Manager audits the operation against an audit table in the audit schema 624 and publishes "identity.user.role.grant.success" to the 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 the 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 may result in a corresponding event being published, such as "prov.account.create.initiate", "prov.target.create.initiate", "prov.target.create.success" or "prov.account.create.success". These events may have their own business metric that sums up 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. The login subscriber picks up this event, updates its metrics for the user, and determines whether additional analysis needs to be performed on the user's access history.

[0079] Thus, by providing "inversion of control" functionality (e.g., changing the flow of execution to schedule an operation for execution at a later point in time so that it 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 Features IDCS microservices are stateless, meaning that the microservices themselves do not hold state. "State" refers to the data an application uses to perform its functionality. IDCS provides multi-tenancy by persisting all state in tenant-specific repositories in 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 stateless nature 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. There is no 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 very large number of customers / tenants. Each pass through an IDCS application / service is CPU intensive to execute application transactions exclusively, 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 features. Scaling the data tier allows you to support more tenants.

[0084] IDCS Feature View FIG. 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 data stores. 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. The data stores are data repositories required / generated by IDCS and include identity store 698b, global configuration 700b, message store 702b, global tenants 704b, personalization settings 706b, resources 708b, user temporary data 710b, system temporary 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 requires to perform its work. In one embodiment, IDCS infrastructure services 662b include a job scheduler 664b, a UI 666b, an SSO 668b, reports 670b, a cache 672b, a 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 integration 612b of applications (e.g., customer applications 614b, partner applications 616b, and cloud applications 618b) as well as 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 (providing AD integration, WNA, and SCIM connectors), 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 the domain name system ("DNS") to be used 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 functions 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 realizes a "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 an enterprise IDM stack. Cloud Gate acts as a security gatekeeper that secures access to IDCS APIs. In one embodiment, Cloud Gate is realized by a web / proxy server plugin that provides a web Policy Enforcement Point ("PEP") to protect HTTP resources based on OAuth.

[0091] 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 use open standards (e.g., OAuth2, OpenID IDCS Policy Decision Point (such as Connect) The IDCS PDP is configured to secure access to REST API resources 714 for web browsers and applications in turn. 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 validating the credentials, it determines whether the credentials are sufficient (e.g., whether to request other credentials, such as a second password). In the embodiment of FIG. 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 holds configuration information about the application's protected and unprotected resources, subject to request matching rules (how to match URLs, e.g., 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 "Authorization Code" flow with the SSO microservice. This flow ends with the delivery of a JWT as an identity token. Cloud Gate 708 validates the JWT (e.g., noting signature, expiration, destination / audience, etc.) and issues a local session cookie for the user 710. It acts as a session manager 716 that secures the web browser's access to protected resources and issues, updates, and validates local session cookies. It also provides a logout URL for removal of that local session cookie.

[0094] Cloud Gate 702 also plays the role of 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 this case, no server-side IDCS session is generated.

[0095] During programmatic access by a REST API client 708, Cloud Gate 702 may act as an OAuth2 resource server / filler 720 for the application's protected REST API 714. It checks for the presence of an authorization header and a request for 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, e.g., 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 validates the JWT issued by IDCS to enable multi-tenancy in IDCS. Thus, IDCS provides multitenancy both in the physical structure and in the logical business processes that support the security model.

[0098] Tenancy Type 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., who the work is being performed for). 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 the application to access the data (i.e., who is performing the work). For example, when a professional services firm provides systems integration capabilities for a large discount store and uses IDCS to provide identity management for the large discount store'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 store.

[0099] The separation and integration of these three tenancies enables multi-tenancy in cloud-based services. Typically, for on-premise software installed on on-premise physical machines, there is no need to identify these three tenancies because a user must be physically on the machine to log in. However, for cloud-based service architectures, embodiments have tokens to determine who uses which applications to access which resources. The three tenancies are codified by the token, enforced by Cloud Gate, and used by the 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 users, clients, and resource tenancies provides substantial business benefits to users of services offered by IDCS. For example, by doing so, a service provider that understands the needs of a business (e.g., a health business) and its identity management problems can purchase services offered by IDCS, develop their own back-end application that consumes the IDCS services, and offer this back-end application to the target business. Thus, the service provider can extend the IDCS services to provide its desired functionality and offer them to a specific target business. 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 clients 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 various users.

[0102] In one embodiment, an entity in IDCS belongs to only one tenant, not multiple tenants simultaneously, and a "tenancy" refers to the location where an artifact resides. This is where the infrastructure is deployed. Typically there are multiple components that realize a particular functionality 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 perform a request to obtain a token for "Tenant 2" that specifies a user in "Tenant 3". As another example, a user present in "Tenant 1" may need to perform an action in an application owned by "Tenant 2". Thus, the user needs to 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 the 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". Thus, 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 realized as an independent stripe. From a data management perspective, artifacts reside in a tenant. From a service perspective, the service knows how to work with heterogeneous tenants, and multiple tenancies are different dimensions in the business capabilities of the service. FIG. 8 illustrates an example system 800 that realizes 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. The database includes 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 to obtain a token. The OAuth microservice is a service that provides a mechanism for accessing and managing data from a single tenancy 802. The OAuth microservice functions are performed in microservice 804 with data from database 806 to verify whether a request from client 802 is valid and, if so, constructs a token using data from different tenancies 808. Thus, system 800 is multi-tenant in that it can work in a cross-tenant environment by supporting services provided to each tenancy as well as services that can act on behalf of various tenants.

[0106] System 800 is advantageous because microservices 804 are physically decoupled from the data in database 806, and by replicating the data closer to the clients, microservices 804 can be offered as local services to the clients, 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 that runs microservice 804 does not hold a marker indicating the service for a particular tenant. Instead, the tenancy may be marked, for example, in the host portion of the URL of the 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. Microservice 804 instead uses connection pool 810, which provides the actual physical connections to database 806 in the context of a database user.

[0108] Generally, 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 a connection is established, it 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 placed in a pool after creation 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, then connection pool 810 will have 10 connections open, all in the context of a database user (e.g., relative to a particular database user, e.g., who is the owner of this connection, whose credentials are being validated, is it a database user, is it a system credential, etc.).

[0109] The connections in the connection pool 810 are created for a system user that can access anything. Thus, to properly handle auditing and privileges by the microservice 804 that processes requests on behalf of the tenant, 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 can only access 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 the database 806, the microservice 804 serves this data using a connection in the connection pool 810. Thus, multitenancy is obtained by having a stateless, elastic mid-tier service that processes incoming requests in the context of (e.g., in relation to) a tenant-specific data store binding built per request on top of data connections created in the context of (e.g., in relation to) a data store proxy user that is associated with a resource tenancy, and the database can be scaled independently of the service.

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

[0111]

number

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

[0113] When configuring different columns for different tenants in the same database by striping all tables, one table may contain data for all tenants mixed together. 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's Oracle Database 12c). In this case, each tenant may be assigned a separate partition. In the data tier, a resource manager processes the request 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 coordinate different tenancies. A URL token may identify the tenancy of the application requesting the service. An identity token may coordinate the identity of the user to be authenticated. An access token may identify multiple tenancies. For example, an access token may coordinate the tenancy that is the target of such access (e.g., an 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 those skilled in the security arts use) in the context of an authentication token is a statement that one entity makes about itself or another entity. A statement may be about, for example, a name, an identity, a key, a group, a privilege, or a capability. Claims are issued by a provider and given one or more values, and then 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 that occur between application "zones" 904 in one embodiment. Applications are divided into zones based on the level of protection required and the ability to connect to various other systems (e.g., SSL zones, no SSL zones, etc.). Some of the application zones are application zones that provide services that require access from within IDCS, some are application zones that 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 FIG. 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 of the application / service 902 may be received by the 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 infrastructure services layer 916 receives and routes the requests through the IDCS platform services layer 914 or IDCS infrastructure services layer 916. The IDCS platform services layer 914 contains IDCS microservices that are called from outside of IDCS, such as OpenID Connect, OAuth, SAML, and SCIM. The IDCS infrastructure services layer 916 contains support microservices that are called from inside of IDCS to support the functionality of other IDCS microservices. Examples of IDCS infrastructure microservices are UI, SSO, reporting, caching, job scheduler, service manager, and functionality for creating keys. The IDCS cache layer 926 supports caching functionality for the IDCS platform services layer 914 and the IDCS infrastructure services layer 916.

[0123] Enhancing security for both external access to IDCS and access within IDCS gives IDCS customers outstanding security compliance for the applications they run.

[0124] In the embodiment of FIG. 9, Structured Query Language ("SQL Other than the data layer 918, which communicates based on LDAP, and the identity store layer 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 layer 912 uses the same tokens and protocols to process incoming requests, whether the requests are received from outside IDCS or from within IDCS. Thus, IDCS enables outstanding security compliance by providing one consistent security model to secure the entire system, because the fewer security models implemented within a system, the more secure the system is.

[0125] In the IDCS cloud environment, applications communicate by making network calls. Network calls may be made using protocols such as HTTP, Transmission Control Protocol ("TCP"), User Datagram Protocol (UDP), and HTTP-based protocols. Based on an applicable network protocol, such as UDP (Universal User Datagram Protocol) For example, application "X" may communicate with application "Y" based on 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 web routing layer 912 needs 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 An 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 management, configuration, and tools to build clients. The embodiment requests user authentication against IDCS by using OpenID Connect semantics for applications. The embodiment tracks a user's active session in IDCS without stateful server-side session support using lightweight HTTP cookie-based user session tracking. The embodiment uses JWT-based identity tokens when mapping authenticated identities back to their own local sessions for consuming applications. The embodiment supports integration with federated identity management systems and exposes SAML IDP support in enterprise deployments to request user authentication against IDCS.

[0129] FIG. 10 is a block diagram 1000 of a system architecture view of SSO functionality within IDCS in one embodiment. This embodiment allows a client application to drive standards-based web protocols to initiate a user authentication flow. The application requesting SSO integration with a cloud system may be in an enterprise data center, in a remote partner data center, or operated by a customer on-premise. In one embodiment, different IDCS platform services enable the business of SSO, such as OpenID Connect for handling login / logout requests from connected native applications (i.e., applications that utilize 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 orchestrating user authentication against an external SAML IDP, and an internal IDCS SSO service for orchestrating end-user login ceremonies, including local or federated login flows, and managing IDCS-hosted session cookies. In general, HTTP works with or without forms. When working with forms, the form is the form visible in the browser. When working without forms, it works as a 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 needs to be registered as an OAuth2 client in IDCS and needs to obtain a client identifier and credentials (e.g., ID / password, ID / certificate, etc.).

[0130] The example embodiment of FIG. 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 one infrastructure microservice. In the embodiment of FIG. 10, IDCS provides an "identity metasystem." In this metasystem, SSO services 1008 are provided for different types of applications, such as browser-based web or native applications 1010 that require a three-way OAuth flow and act as an OpenID Connect relaying party ("RP", an application that outsources its user authentication functionality to an IDP), native applications 1011 that require a two-way OAuth flow and act as an OpenID Connect RP, and web applications 1012 that act as a SAML SP.

[0131] In general, the Identity Metasystem is an interoperable architecture for digital identity, allowing 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 capabilities and can be the basis for building applications, and the Identity Metasystem may be configured to provide a unified security system for such applications. The LDAP security model specifies certain 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. Since 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 with 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 with 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 the cookies.

[0134] In one embodiment, the SSO microservice 1008 performs the login ceremony 1018, ID / password recovery 1020, first login flow 1022, authentication management The authentication manager 1024 provides a login ceremony 1018, 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 for recovering a user's ID and / or password. The first login flow 1022 is realized when a user logs in for the first time (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 follows a three-way OAuth flow to authenticate the user of the application. Thus, OAuth microservice 1004, acting as an OIDC provider 1030, 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 validates an existing session or performs a login ceremony. Upon successful authentication or validation, SSO microservice 1008 returns an authentication context to OAuth microservice 1004. The OAuth microservice 1004 then redirects the browser 1002 to a callback URL with an authorization ("AZ" code. The browser 1002 sends the AZ code to the OAuth microservice 1004 and requests the required token 1032. The browser 1002 also includes its client credentials (obtained when registering IDCS as an OAuth2 client) in the HTTP Authorization header. In response, the OAuth microservice 1004 grants the requested token 1032 to the browser 1002. In one embodiment, the token 1032 granted to the 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, the OAuth microservice 1004 receives an authorization request from the native application 1011 and authenticates the user according to a two-party OAuth flow. In this case, the authentication manager 1034 of the OAuth microservice 1004 performs the corresponding authentication (e.g., based on the ID / password received from the client 1011), and the token manager 1036 issues the corresponding access token upon successful authentication.

[0138] In one embodiment, for example, the SAML microservice 1006 receives an SSO POST request from a browser and authenticates the user of the web application 1012 acting as a SAML SP. The SAML microservice 1006 then acts as a SAML IDP 1038 and redirects the browser 1002 to the SSO microservice 1008 and proceeds with the application context. Depending on whether the user has a valid SSO session, the SSO microservice 1008 either validates the existing session or performs a login ceremony. Upon successful authentication or validation, the SSO microservice 1008 passes the authentication context to the SAML microservice 1006. 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 a remote SAML IDP 1042 (e.g., 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 FIG. 11 is a message sequence flow 1100 of the SSO functionality provided by IDCS in one embodiment. When a user accesses a client 1106 (e.g., a browser-based application or a mobile / native application) with a browser 1102, Cloud Gate 1104 acts as an application enforcement point and enforces the policies defined in the local policy text file. If Cloud Gate 1104 detects that the user does not have a local application session, it requests the user to authenticate. To do so, Cloud Gate 1104 initiates an OpenID Connect login flow to the OAuth2 microservice 1110 by redirecting the browser 1102 to the OAuth2 microservice 1110 (a 3-way AZ Grant flow, scope = "openid profile").

[0142] The browser 1102 request traverses IDCS routing tier web service 1108 and Cloud Gate 1104 to OAuth2 microservice 1110. OAuth2 microservice 1110 constructs an application context (i.e., metadata describing the application, e.g., the identity of the connecting application, client ID, configuration, what the application can do, etc.) and redirects the browser 1102 to 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 to Cloud Gate 1104 in a REST POST. Cloud Gate 1104 validates the user's password by sending the authentication information to the administration SCIM microservice 1116. The administration SCIM microservice 1116 determines that the authentication is 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 being exposed to the application. During the login ceremony, the SSO microservice 1112 respects the customer's IDP preferences and, if configured, redirects to the IDP for authentication against the configured IDP.

[0145] Upon successful authentication or validation, the SSO microservice 1112 redirects the browser 1102 back to the 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. The OAuth2 microservice 1110 returns an AZ code (e.g., an OAuth concept) to the browser 1102 and redirects it to Cloud Gate 1104. The browser 1102 sends the AZ code to Cloud Gate 1104, which sends a REST POST to the OAuth2 microservice 1110 requesting an access token and an identity token. Both of these tokens are scoped to the OAuth microservice 1110 (indicated by the audience token claim). Cloud Gate 1104 receives these tokens from the OAuth2 microservice 1110.

[0146] Cloud Gate 1104 uses the identity token to map the authenticated user's identity to its internal account representation, which 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 is repeated.

[0147] Cloud Gate 1104 also retrieves the "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 the 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 application that has OAuth2 integration, 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 the OAuth2 microservice 1110. The OAuth2 microservice The SSO microservice 1110 redirects the user 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 fed into 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 LDAP protocols. 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 via LDAP. Alternatively, the application may be configured to use a database via a different protocol, such as SQL. However, LDAP provides a hierarchical representation of resources in a tree structure, whereas SQL represents data as tables and fields. Thus, LDAP may be more desirable for search functions, whereas SQL may be more desirable for transactional functions.

[0153] In one embodiment, services provided by IDCS can be used by LDAP-based applications, for example, to authenticate users of the application (i.e., identity services) or to 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 to allow 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 multiple customers, each of which may have their 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 the content that is searched at run time.

[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, the cloud cache "flattens" LDAP where it has a set of users and a set of groups running against the cloud. In one embodiment, there may be any number of cloud caches implemented in IDCS.

[0156] Distributed Data Grid In one embodiment, the cache cluster in IDCS is implemented based on a distributed data grid, for example as 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 between 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 in keeping copies of information synchronized across multiple servers to ensure system resilience and continuous availability of data during server failure events.

[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 proprietary, Java-based, in-memory data grid designed to provide higher reliability, scalability, and performance compared to traditional management systems. Coherence is a peer-to-peer (i.e., no central manager) in-memory distribution system. Provides a distributed cache.

[0158] 12 illustrates an example of a distributed data grid 1200 that stores data and 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 in a distributed or clustered environment. Although the distributed data grid 1200 is shown as including four servers 1220a, 1220b, 1220c, 1220d with five data nodes 1230a, 1230b, 1230c, 1230d, and 1230e in cluster 1200a, 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, the 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 32-bit or 64-bit application platform. Each server (e.g., 1220a, 1220b, 1220c, and 1220d) is configured with one or more CPUs, a network interface card ("NIC"), and memory, e.g., a minimum of 4 GB RAM and a maximum of 64 GB RAM or more. Server 1220a is shown as having a CPU 1222a, memory 1224a, and a NIC 1226a (these elements are also present on the other servers 1220b, 1220c, 1220d but are not shown). Optionally, excess storage capacity may be provided by providing each server with flash memory (e.g., SSD 1228a). As 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 contains a minimum of four physical servers to avoid the possibility of data loss during failures, although a typical installation will have many more servers. 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 the servers. Thus, the cluster is limited by the number of ports on the switch 1202. Thus, a typical cluster will contain 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 of 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 demands of the distributed data grid. JVMs running Oracle Coherence automatically join and cluster on 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 magnetic or optical disks, 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 may be any available media that can be accessed by a processor and includes volatile and nonvolatile media, removable and non-removable media, and communication media. Communication media 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 provide functionality when executed by the processor. 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 the cloud data.

[0168] 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 around the world by making resources such as applications, services, and storage available to the general public over the Internet. Public clouds are known to have 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 as "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 consolidated into a single "island" managed by one or more "control plane" deployments (denoted as "CP"). An island is a collection of regions consolidated 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, and 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 the situation where a control plane component serves more than one region, the component requires authority to interact with all regions with one identity.

[0170] A customer account is managed by the cloud 1300 for each user / customer who purchases / acquires various public cloud services. One type of service available to the customer can be the multi-tenant identity management service, or IDCS, disclosed above, which can be realized as a control plane component and deployed separately in every region (i.e., every data center) to protect resources in that region. As mentioned above, in one embodiment, a control plane that is 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 is established between these deployments so that components / customers assigned to the IDCS in one region can make IDCS API calls (e.g., to access specific microservices among the IDCS microservices 614 in FIG. 6) to the IDCS in the other region. Known solutions currently allow a user who is designated and assigned to a region to only access resources in that region and not in other regions, and to only be authenticated from that region and not from other regions.

[0171] In contrast, in embodiments, a user who has 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). The 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. In general, a global access token needs to be given to the user to enable the 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 to access a user or service) may only be present 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 have a presence or 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. Thus, 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 will request recovery of the global access token in Sydney. Chicago DC 1307 generates the token and signs it with a global private key. The global private key is available in all DCs. In embodiments, the global access token is used to access only IDCS REST APIs, and therefore, when the token is used to access non-IDCS REST APIs across multiple regions, An error will occur.

[0173] The IDCS deployment in Sydney DC1303 consumes and validates the token when it is presented. The client can then access resources in Sydney, even though it is not specified in Sydney. In an embodiment, the client need only be specified 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 an embodiment. In one embodiment, the functions of the flow diagram of FIG. 14 are implemented by software stored in a 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 the 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. The client of the embodiment may be a PaaS Service Manager (PSM), a tenant automation system, or a service provider. The control plane may be an Oracle cloud control plane instance, such as the 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" validates 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 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 the request to a cloud gate (e.g., cloud gate 702 in FIG. 7) to the actual resource (i.e., IDCS in the remote region). The token is consumed by forwarding it to an AZfilter in the remote region and then having the AZfilter consume the token. 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 requested resource The Cloud Gate Agent protecting the service endpoint verifies that the token was issued by an IDCS deployment that belongs 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 all IDCS deployments in the various regions of a given island are 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 the globally trusted entity. Because the trust is pre-established, the token can be validated in any region of the island, or in other embodiments, in any region of the public cloud.

[0180] In one embodiment, each IDCS deployment in an island is configured to be a global access token issuer. In one embodiment, a global access token is only valid in 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. Doing so also allows for signing key rollover in regional IDCS deployments. In another embodiment, one or more global token issuers are deployed separately rather than combined as part of an 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 configured with the IDCS App with app id "idcs-cloudinfra- <region>" tenancy only, and "idcs-cloudinfra- <region>" The Global IDCS Client role 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 an IDCS seeding tool that 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 can equally recover this token in the local IDCS deployment as well as in 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 an embodiment, 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 has a different global key pair from 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 with a global key. In one embodiment, an OAuth access token or "identity token" contains at least a claim / statement indicating the user tenant name (i.e., where the user resides). A "claim" (as those skilled in the security field use it) in the context of an authentication token is a statement that one entity makes about itself or another entity. The statement may be about a name, identity, key, group, authority, or capability, for example. The claim is issued by the provider and given one or more values, and then 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 reinstated 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 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: 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 with the "global signing key" and returns the "global token" to the requesting client.

[0192] In one embodiment, to validate the global access token, the following sequence of events is performed in the remote regions of the 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 a "global token." 2. This request is intercepted by IDCS CG (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 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.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 needed in case different global keys are given to different deployments. Otherwise, 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 be given only to the CG, as this call is made only by the CG.

[0196] c. The IDCS CG validates various aspects of the token, including signature and revocation. Any failure to validate will result 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 to 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>), 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 for https: / / idcs- <tenant>.identity.oraclecloud.com / <endpoint>of Reach the IDCS service.

[0201] Once the token is validated, the CG will forward the request to the actual resource, in this case IDCS, to recover the global access token, which will be consumed by the AZ filter. 1. The Authz filter in "Region 2" evaluates the authorization for the token a. Next the AZ filter 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 don't 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 AZ filter and written to Audit by 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 would lead to errors in the remote IDCS deployment.

[0205] As disclosed, embodiments allow 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 (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 intended to be covered by and fall within the scope of the following claims without departing from the spirit and scope of the present invention.< / endpoint> < / tenant> < / endpoint> < / tenant> < / tenant> < / text> < / text> < / region> < / region> < / region> < / region>

Claims

1. 1. A multi-tenant cloud system, comprising: 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 receiving 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 validates 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 with the global access token, and the multi-tenant cloud system further comprises: 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. 2. The multi-tenant cloud system of claim 1, wherein issuing the global access token includes signing the global access token with a global signing key stored at the first data center and the second data center.

3. 2. The multi-tenant cloud system of claim 1, wherein issuing the global access token includes signing the global access token with a signing key retrieved from a central authority using a first authentication key stored only at the first data center.

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

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

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

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

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

9. 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 region; and 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 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 at the first data center, validating the request from the first client and issuing a global access token, the global access token being a normal 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.

10. 10. The method of claim 9, wherein issuing the global access token comprises signing the global access token with a global signing key stored at the first data center and the second data center.

11. 10. The method of claim 9, wherein issuing the global access token comprises signing the global access token with a signing key retrieved from a central authority using a first authentication key stored only at the first data center.

12. The method of any of claims 9 to 11, wherein the additional token claims include a client tenant name, the location identifier, and a flag indicating that the OAuth token claims is the global access token.

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

14. The method according to any of claims 9 to 13, wherein after validation of the request, the global access token is consumed by an authentication filter.

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

16. The method according to any one of claims 9 to 15, wherein the first data center and the second data center are located on the same control plane.

17. A program for causing at least one processor out of a plurality of processors to execute the method according to any one of claims 9 to 16.

Images