Multi-tenant identity cloud service with integrated on-premise authentication

Abstract

Embodiments are directed to a multi-tenant cloud system. The embodiments receive a request for an authentication action for a user and create an authentication target action. The embodiments register a cache listener to listen for a target action response in response to the authentication target action and initiate the authentication action for the user through a bridge in an on-premises Active Directory ("AD"). The embodiments wait for a cache callback and receive the target action response in the cache callback, which includes the results of the authentication action.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Provisional Patent Application No. 62 / 899,888, filed September 13, 2019, 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 Embodiments are directed to a multi-tenant cloud system. Embodiments receive a request for an authentication action for a user and create an authentication target action. Embodiments register a cache listener to listen for a target action response in response to the authentication target action and initiate an authentication action for the user through a bridge with an on-premise active directory ("AD"). Embodiments wait for a cache callback and receive a target action response in the cache callback that includes a result of the authentication action. [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 the functionality between Identity Cloud Service ("IDCS") and an on-premises active directory via a bridge from the perspective of IDCS when performing delegated authentication, according to an embodiment. [Figure 14] FIG. 1 illustrates the functionality between IDCS and an on-premises active directory via a bridge from the perspective of the active directory when performing delegated authentication, according to an embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0006] Detailed Description The identity cloud service provided by the embodiments enables a microservices-based architecture and provides multi-tenant identity and data security management and secure access to cloud-based applications. The embodiments optimize the request / response flow between the cloud-based authentication service and the on-premise authentication system by promoting an in-memory data grid cache callback. The embodiments reduce the latency when the cloud-based authentication system (e.g., IDCS) interfaces with the on-premise authentication system using the cache callback.

[0007] 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 manage access for a variety of users, such as customers, partners and employees. Embodiments manage, control and audit both access through the cloud and on-premise. Embodiments integrate with new and existing applications and identities. Embodiments are horizontally scalable.

[0008] One embodiment is a system that provides cloud-based multi-tenant identity and access management services by implementing multiple microservices in a stateless 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.

[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 cloud and on-premise systems. In alternative or additional embodiments, IDCS may also manage access to public cloud services. For example, IDCS can be used to provide Single Sign On ("SSO") capabilities across such diverse services / applications / systems.

[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 architecture 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 focus 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 of which runs in its own process and communicates with a lightweight mechanism (e.g., a Hypertext Transfer Protocol ("HTTP") resource API). In one embodiment, microservices are easier to replace compared to monolithic services that perform all or much of the same functionality. 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 for each such microservice may be on the order of one second or less, whereas the startup time for 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 (i.e., separation of tasks within a system) and implementation of service oriented architecture ("SOA") for building flexible, independently deployable software systems. 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. Distributing the functionality of a system into different small services increases the cohesion of the system and reduces coupling of the system. It facilitates system changes and makes it easier to add functionality 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 enabling earlier and continuous releases of software.

[0017] In one embodiment, in a microservices architecture, an application is developed as a collection of services, each running its own process and communicating using a lightweight protocol (e.g., a specific API per microservice). In a microservices architecture, the decomposition of a piece of software into individual services / functions can be done at different levels of granularity depending on the services provided. A service is a runtime component / process. Each microservice is a self-contained module that can talk to other modules / microservices. Each microservice has an anonymous universal port that can be contacted by others. In one embodiment, the anonymous universal port of a microservice is a standard communication channel that a microservice traditionally exposes (e.g., as 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] An embodiment adheres to industry standards (e.g., OpenID Connect, OAuth2, Security Assertion Markup Language 2 ("SAML2"), System for Cross-domain Identity Management ("SCIM"), Representational State Transfer ("REST"), etc.) for ease of integration with various applications. An embodiment provides a cloud-scale API platform and enables horizontally scalable microservices for elastic scalability. An embodiment provides a multi-tenant architecture with data isolation per tenant, leveraging cloud principles. An embodiment further provides per-tenant customization via tenant self-service. An embodiment is available via APIs for on-demand integration with other identity services and provides continuous feature releases.

[0022] One embodiment provides interoperability and leverages investments in cloud and on-premise identity management ("IDM") capabilities. The embodiment provides automated identity synchronization from on-premise Lightweight Directory Access Protocol ("LDAP") data to cloud data and vice versa. The embodiment provides a SCIM identity bus between the cloud and the enterprise, enabling various options for hybrid cloud deployments (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 Apple® Safari®.

[0025] The IDCS 118 provides a unified view 124 of a user's applications, unified and secure credentials across devices and applications (via the identity platform 126), and a unified management methodology (via the management console 122). IDCS services may be obtained by calling the IDCS API 142. Such services may include, for example, a login / SSO service 128 (e.g., OpenID Connect), a federation service 130 (e.g., SAML), a token service 132 (e.g., OAuth), a directory service 134 (e.g., SCIM), a provisioning service 136 (e.g., SCIM or Any Transport over Multiprotocol ("AToM")), an event service 138 (e.g., REST), and a role-based access control ("RBAC") service 140 (e.g., SCIM). The IDCS 118 may further 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] FIG. 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 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 include, for example, Human Capital Management ("HCM"), CRM, talent acquisition (e.g., Oracle Taleo cloud services from Oracle Corporation), Configure Price and Quote ("CPQ"), etc. Cloud services 210 may include, for example, Platform as a Service ("PaaS"), Java, databases, business intelligence ("BI"), documents, etc.

[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 transmitting messages from one system to another. It is a controlled mechanism for exchanging information between trusted systems, for example in a service oriented architecture ("SOA"). 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 respective protocol (e.g., SCIM, SAML, OpenID Connect, etc.). For example, a SAML bus is an HTTP-based connection between two systems to transmit messages related to SAML services. Similarly, a SCIM bus is used to transmit SCIM messages according to the SCIM protocol.

[0030] The embodiment of FIG. 2 provides a small binary (e.g., 1 MB in size) identity ("ID") bridge 230 that can be downloaded and installed on-premise 206 along with the customer's AD 204. The identity bridge 230 listens to users and groups (e.g., groups of users) of organizational units ("OUs") selected by the customer and synchronizes these users to the cloud 208. In one embodiment, users' passwords 232 are not synchronized to the cloud 208. Customers can manage users' application access 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 Corporation's Oracle Identity Manager ("OIM") Connector 302 and Oracle Corporation's Oracle Access Manager ("OAM") Federation Module 306 are implemented as extension modules of Oracle IDM 304. Connectors are modules that have physical knowledge of how to talk to a system. OIM is an application configured to manage user identities (e.g., manage 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 IDCS 202, 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, a "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 is a component that secures access to multi-tenant IDCS microservices by ensuring that client applications provide valid access tokens and / or users successfully authenticate to build an SSO session. Cloud Gate 502 is disclosed further below. Cloud Gate 502 (an enforcement point similar to webgate / webagent) allows applications running behind supported web servers 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. Generally, passwords and challenge questions have 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 for ways to securely incorporate bring your own device ("BYOD"), social identities, remote users, customers, and contractors while making MFA a nearly transparent component of a seamless user access experience. 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 technologies. 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. With integration of appropriate standards (e.g., open authentication ("OATH") and fast identity online ("FIDO"), and an extensible identity management framework, embodiments provide an MFA solution that can be easily adopted, upgraded, and integrated 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 provides privileged account management ("PAM"). 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. Additionally, 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, such as 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] Generally, in the IDCS web environment, a URL contains three parts: host, microservice, and resource (e.g., host / microservice / resource). In one embodiment, a microservice is characterized by having a specific URL prefix (e.g., "host / oauth / v1"), and the actual microservice is "oauth / v1". There are multiple APIs under "oauth / v1", such as an API for requesting a token: "host / oauth / v1 / token", an API for authorizing a user: "host / oauth / v1 / authorize", etc. That is, the URL realizes the microservice, and the resource part of the URL realizes the API. Thus, multiple APIs are aggregated under the same microservice. In one embodiment, the host part of the URL identifies a 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> / .well-known / idcs-configuration) including IDCS, SAML, SCIM, OAuth, and OpenID Connect configurations, and (for example <idcs-url>The IDCS configuration is an industry standard OpenID Connect configuration ( / .well-known / openid-configuration) that allows applications to retrieve discovery documents by configuring them at a single IDCS URL.

[0052] Figure 6 is a block diagram that provides a system view 600 of IDCS in one embodiment. In Figure 6, any of a variety of applications / services 602 can use the IDCS service by making HTTP calls to the IDCS API. Examples of such applications / services 602 are web applications, native applications (e.g., applications built to run on a particular operating system, such as Windows applications, iOS applications, Android applications, etc.), web services, customer applications, partner applications, or services provided by a public cloud, such as Software as a Service ("SaaS"), PaaS, and Infrastructure as a Service ("IaaS").

[0053] In one embodiment, an HTTP request for an application / service 602 requesting an IDCS service goes through an Oracle Public Cloud BIG-IP appliance 604 and an IDCS BIG-IP appliance 606 (or similar technology such as a load balancer or a component called 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 tenant and service reconciliation. In one embodiment, the cloud provisioning engine 608 manages the internal security artifacts associated with new tenants being onboarded to the cloud or new service instances purchased by customers.

[0054] 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 service realizes the standard OpenID Connect login / logout flow. Interactive web-based and native applications facilitate a standard browser-based OpenID Connect flow to request user authentication and receive a standard identity token, which is a JavaScript Object Notation ("JSON") Web Token (Web Token "JWT") that conveys the user's authenticated identity. Internally, the runtime authentication model is stateless, maintaining the user's authentication / session state in the form of a host HTTP cookie (containing the JWT identity token). Authentication interactions initiated via the OpenID Connect protocol are delegated to a trusted SSO service that realizes 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 realized in accordance with, for example, OpenID Foundation standards.

[0057] The OAuth2 Platform Service provides token authorization services. It provides a rich API infrastructure for creating and validating access tokens that convey user rights to make API calls. It supports a range of useful token grant types, allowing customers to securely connect clients to its services. It implements standard two-party and three-party OAuth2 token grant types. Supporting 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 implemented in accordance with, for example, Internet Engineering Task Force ("IETF"), Request for Comments ("RFC") 6749.

[0058] The SAML2 Platform Service provides identity federation services. It enables customers to set up federation agreements with their partners based on a SAML identity provider ("IDP") 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, 7644. The SCIM++ Platform Service provides identity management services and allows customers to access the IDP features of IDCS. The management services expose a set of stateless REST interfaces (i.e., APIs) covering identity lifecycle, password management, group management, etc., and expose artifacts such as web-accessible resources.

[0060] All IDCS configuration artifacts are resources, and the Administration Service APIs enable 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 a schema-based REST API for Create, Read, Update, Delete, and Query ("CRUDQ") operations on all IDCS resources. In addition, all internal resources of IDCS 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 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 supports a set of remote procedure call-style ("RPC-style") REST interfaces that do not perform CRUDQ operations but instead provide functional services, such as "UserPasswordGenerator", "UserPasswordValidator", etc.

[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 as an OAuth2 client or IDCS application (in which case the OAuth2 client is created automatically) through the IDCS Admin console and must be granted the desired IDCS Management role. When making an IDCS Management API call, the application first requests an access token from the IDCS OAuth2 service. After obtaining this token, the application sends the access token in an HTTP Authorization header. Applications can use the IDCS Management 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 allows the use of database schema. The schema service allows the responsibility of managing database schema to be delegated to IDCS. Thus, users of IDCS do not need to manage databases because there is an IDCS service that provides this functionality. For example, a user may persist a schema per tenant using a database, and when there is no space 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 further includes data stores, which are data repositories required / generated by IDCS. This includes Identity Store 618 (which stores users, groups, etc.), Global Database 620 (which stores configuration data that IDCS uses to configure itself), Operational Schema 622 (which stores customer data per customer with separate schema per tenant), Audit Schema 624 (which stores audit data), Caching Cluster 626 (which stores cached objects to speed up execution), etc. All IDCS consumers, internal and external, integrate with the identity service following standards-based protocols. This allows the domain name system ("DNS") 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 that includes a link for the user to reset their password when the user is created in the identity store 618. When IDCS receives a request to register or create a new user, the corresponding microservice looks at the configuration data in the operational database (located in the global database 620 in FIG. 6) and determines that the operation "user creation" is marked with a "user creation" event. This operation is identified in the configuration data as an asynchronous operation. The microservice returns to the client indicating that the user creation was successful, but the actual sending of the notification email is postponed and pushed to the backend. To do so, the microservice uses the messaging API 616 to queue this message into the 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 the user manager (infrastructure libraries / services at 614). The user manager then creates this user in the identity store stripe for the specific tenant in the identity store 618. In case of "User Create Success", 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 with the newly created login details.

[0077] In one embodiment, IDCS may be used to grant roles to users resulting in user provisioning 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), which grants the role 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 audit schema 624 and publishes "identity.user.role.grant.success" to message queue 628. An identity subscriber 632 picks up this event and evaluates the provisioning grant policies. If there is an active application grant for the granted role, the provisioning subscriber performs some validation, initiates an 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 the publication of a corresponding event, such as "prov.account.create.initiate", "prov.target.create.initiate", "prov.target.create.success" or "prov.account.create.success". These events may have their own business metric, which sums the number of accounts created in the target system in the last N days.

[0078] In one embodiment, IDCS can be used for user login. For example, client application 602 may request a user login using one of the supported authentication flows. IDCS authenticates the user and, if successful, audits the operation against an audit table in audit schema 624. If unsuccessful, IDCS audits the failure in audit schema 624 and publishes a "login.user.login.failure" event in message queue 628. 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 statelessness of the IDCS middle tier makes it horizontally scalable by simply adding more CPUs; the IDCS components that perform the work for an application do not need to have the designated physical infrastructure where the particular application is running. 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 the application transaction, but does not use hardware to store the data. Scaling is achieved by adding more slices while the application is running, while the data for the transaction is stored in the 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 require 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 notification, application submission, 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, a cookie API 692b, a key API 694b, and a credential API 696b. In one embodiment, cloud computing services 602b (internal Nimbula) support 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] FIG. 7 is a block diagram 700 of an embodiment implementing Cloud Gate 702. Cloud Gate 702 executes in a web server 712 and acts as a Policy Enforcement Point ("PEP"). The Policy Enforcement Point is configured to integrate with an IDCS Policy Decision Point ("PDP") using open standards (e.g., OAuth2, OpenID Connect, etc.) while securing access to REST API resources 714 for web browsers and applications. In some embodiments, the PDP is implemented in an OAuth and / or OpenID Connect microservice 704. For example, when a user browser 706 sends a request to IDCS to log in a user 710, the corresponding IDCS PDP validates the credentials and then 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 can act as both a PEP and a PDP because it has a local policy.

[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, supporting multi-tenancy in IDCS. Cloud Gate enables multi-tenancy in IDCS by validating the JWT issued by IDCS. Thus, IDCS provides multi-tenancy in both the physical structure and 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 structures, embodiments use 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 at the same time, and a "tenancy" is where an artifact resides. In general, there are multiple components that realize a particular function, and these components can belong to multiple tenants or can belong to the infrastructure. When the infrastructure needs to act on behalf of a tenant, it interacts with entity services on behalf of the tenant. In this case, the infrastructure itself has its own tenancy, and the customer has its own tenancy. When a request is submitted, there are multiple tenancies involved in this request.

[0103] For example, a client belonging to "Tenant 1" may 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 implemented as an independent stripe. From a data management perspective, artifacts reside in the tenant. From a service perspective, the service knows how to work with heterogeneous tenants, and multiple tenancies are different dimensions in the business capabilities of the service. FIG. 8 illustrates an example system 800 that implements multiple tenancies in one embodiment. The system 800 includes a client 802 that requests a service provided by a microservice 804 that understands how to work with data in a database 806. The database includes multiple tenants 808, each of which includes artifacts for a corresponding tenancy. In one embodiment, the microservice 804 is an OAuth microservice that requests via https: / / tenant3 / oauth / token to obtain a token. The OAuth microservice functionality is executed in the microservice 804 with data from the database 806 to verify whether the request of the client 802 is valid, and if so, data from the different tenancies 808 is used to construct the token. Thus, system 800 is multi-tenant in that it can operate in a cross-tenant environment by supporting services that are provided to each tenancy as well as services that can act on behalf of various tenants.

[0106] System 800 is advantageous because 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 composing different columns for different tenants in the same database by striping all tables, one table may contain data of all tenants mixed. In contrast, one embodiment provides a tenant-driven data tier. This embodiment provides a different physical database for each tenant instead of striping the same database for different tenants. For example, multitenancy may be achieved using a pluggable database (e.g., Oracle's Oracle Database 12c), where each tenant is assigned a separate partition. In the data tier, a resource manager processes a request and then asks for the data source for that request (apart 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 IDCS services by making HTTP calls to the IDCS API. In one embodiment, the HTTP requests of the applications / services 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 and routes them through an IDCS platform services tier 914 or an IDCS infrastructure services tier 916. The IDCS platform services tier 914 includes IDCS microservices that are called from outside of IDCS, such as OpenID Connect, OAuth, SAML, SCIM, etc. The IDCS infrastructure services tier 916 includes support microservices that are called from inside IDCS to support the functionality of other IDCS microservices. Examples of IDCS infrastructure microservices are UI, SSO, reporting, cache, job scheduler, service manager, functionality for creating keys, etc. 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, other than the data layer 918, which communicates based on Structured Query Language ("SQL"), 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 received requests, whether the requests are received from outside or inside 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. The network calls may be based on an applicable network protocol, such as HTTP, Transmission Control Protocol ("TCP"), User Datagram Protocol ("UDP"), etc. 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 a number of 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, a Chef server 924, a configuration management tool from Chef Software, Inc., provides configuration management functionality for the various IDCS tiers. In one embodiment, a service deployment infrastructure and / or persistent storage module 928 may send an OAuth2 HTTP message to the IDCS web routing tier 912 for tenant lifecycle management operations, public cloud lifecycle management operations, or other operations. In one embodiment, the IDCS infrastructure services tier 916 may send an ID / password HTTP message to a public cloud notification service 930 or a 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 includes three components / microservices that collectively provide login functionality, including OAuth2 1004 and SAML2 1006 as two platform microservices, 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-party 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-party 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 provides a login ceremony 1018, an ID / password recovery 1020, a first login flow 1022, an authentication manager 1024, an HTTP cookie manager 1026, and an event manager 1028. The login ceremony 1018 realizes the SSO functionality based on customer settings and / or application context and may be configured according to a local form (e.g., Basic Auth), an external SAML IDP, an external OIDC IDP, etc. The ID / password recovery 1020 is used to recover a user's ID and / or password. The first login flow 1022 is realized 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, the OAuth microservice 1004 receives an authorization request from the browser 1002 and authenticates the user of the application according to a three-way OAuth flow. Thus, the OAuth microservice 1004, acting as an OIDC provider 1030, 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 or not, the SSO microservice 1008 validates the existing session or performs a login ceremony. If the authentication or validation is successful, the SSO microservice 1008 returns the authentication context to the 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 provides the requested token 1032 to the browser 1002. In one embodiment, the token 1032 provided 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.

[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 validates the existing session or performs a login ceremony. If the authentication or validation is successful, the SSO microservice 1008 returns the authentication context to the SAML microservice 1006. The SAML microservice then redirects to the SP with the necessary token.

[0139] In one embodiment, for example, the SAML microservice 1006 may act as a SAML SP 1040 and may go to 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 browser redirection, and the SSO microservice 1008 challenges the user with an HTML form, validates the credentials, and issues a session cookie.

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

[0141] Login / Logout Flow Figure 11 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's authentication. 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 (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 logout. Alternatively, the user may have initiated logout on the IDCS side. Cloud Gate 1104 terminates the application-specific user session and initiates an OAuth2 OpenID Provider ("OP") logout request to OAuth2 microservice 1110. OAuth2 microservice 1110 redirects to SSO microservice 1112, which deletes the user's host SSO cookie. 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, which is an LDAP front-end. 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 its own applications, users, groups, tasks, etc. Another example of a line of business that may implement an LDAP cache directory is a wireless service provider. In this case, each call made by a user of the wireless service provider authenticates the user's device against the LDAP directory, and some of the corresponding information in the LDAP directory may be synchronized with a billing system. In these examples, LDAP provides the ability to physically separate the content that is searched at runtime.

[0155] In one example, a wireless service provider may use services provided by IDCS to support short-term marketing campaigns while handling its own identity management services for its core business (e.g., regular calls). In this case, 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 enables a distributed data grid, such as Coherence, to allow any microservice to request access to a shared cache object without being blocked. Coherence is a proprietary, Java-based, in-memory data grid designed for higher reliability, scalability, and performance compared to traditional relational database management systems. Coherence provides a peer-to-peer (i.e., no central manager), in-memory 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 FIG. 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 a conventional computer system, such as, for example, a “commodity x86” server hardware platform with one to two processor sockets and two to four CPU cores per processor socket. Each server (e.g., 1220a, 1220b, 1220c, and 1220d) is configured with one or more CPUs, a Network Interface Card (“NIC”), and memory, including, for example, a minimum of 4 GB 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, and 1220d but are not shown). Optionally, each server may be provided with flash memory (e.g., SSD 1228a) to provide excess storage capacity. When provided, the SSD capacity is preferably 10 times the size of the RAM. The servers (e.g., 1220a, 1220b, 1220c, 1220d) of the data grid cluster 1200a are connected to a high performance network switch 1220 (e.g., Gigabit Ethernet or higher) using high bandwidth NICs (e.g., 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] In most Wide Area Network ("WAN") configurations of a distributed data grid 1200, 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) coupled via links 1206 and / or by locating the interconnected but independent clusters in data centers 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 needs of the distributed data grid. JVMs running Oracle Coherence automatically join and cluster upon startup. JVMs / nodes that join a cluster are referred to as cluster members or cluster nodes. Each cluster may further connect to a standard database 1210 that stores accessible data 1212.

[0163] architecture Each client or server includes 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 instructions and information executed by the processor. The memory may consist 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 communication 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] IAM feature examples In one embodiment, the IAM functions are implemented by software stored in memory or other computer readable or tangible medium and executed by a processor.

[0169] A request to run an identity management service is received. In one embodiment, the request includes a call to an API that identifies the identity management service and the microservice configured to run the identity management service. In one embodiment, the microservices are self-contained modules that can communicate with other modules / microservices, and each microservice has an anonymous universal port that can be contacted by the others. For example, in one embodiment, as shown in FIG. 6, various applications / services 602 can make HTTP calls to the IDCS API to use the IDCS microservice 614. In one embodiment, the microservices are runtime components / processes.

[0170] In one embodiment, the request includes a URL. In one embodiment, the microservice is identified in the prefix of the URL. In one embodiment, the resource portion of the URL identifies the API. In one embodiment, the host portion of the URL identifies the tenancy of the resource associated with the request. For example, in a URL such as "host / microservice / resource" in the IDCS web environment, a microservice is characterized by having a specific URL prefix (e.g., "host / oauth / v1"), the actual microservice is "oauth / v1", and there are multiple APIs under "oauth / v1", e.g., an API for requesting a token: "host / oauth / v1 / token", an API for authorizing a user: "host / oauth / v1 / authorize", etc. That is, the URL realizes the microservice 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").

[0171] The request is then authenticated. In one embodiment, the request is authenticated by a security gate, such as Cloud Gate, as described herein with reference to, for example, web routing layer 610 of FIG. 6 and / or Cloud Gate 702 of FIG.

[0172] Microservices are then accessed based on APIs, for example as described herein with reference to the IDCS "API Platform" of FIG. 6 and IDCS middle tier 614 accessing microservices. In one embodiment, communication with a microservice is configured through the microservice's anonymous universal port. In one embodiment, the microservice's anonymous universal port is a standard communication channel that a microservice traditionally exposes (e.g., as a traditional HTTP port) and allows any other module / microservice within the same service to talk to it. In one embodiment, a microservice provides one or more functions by exposing one or more APIs. In one embodiment, communication with a microservice is achieved exclusively through one or more APIs. That is, contact with a microservice is achieved exclusively by making calls to such APIs. In one embodiment, communication with a microservice is configured according to a lightweight protocol. In one embodiment, the lightweight protocol includes HTTP and REST. In one embodiment, the requests include calls to a RESTful HTTP API. Thus, one embodiment provides a dispatch function. Each HTTP request includes a URI and a verb. The embodiment parses the URI's endpoint (host / service / resource) and dispatches (or invokes) the appropriate method on the appropriate module by combining it with an HTTP verb (e.g., POST, PUT, PATCH, or Delete). This pattern is common in REST and is supported by various packages (e.g., Jersey).

[0173] Identity management services are then performed by the microservices, for example as described herein with reference to the IDCS “API platform” of FIG. 6 and access to microservices in IDCS middle tier 614. In one embodiment, the microservices are stateless, horizontally scalable, and independently deployable. In one embodiment, each physical implementation of a microservice is configured to securely support multiple tenants. In one embodiment, the identity management services include a login service, an SSO service, a federation service, a token service, a directory service, a provisioning service, or an RBAC service.

[0174] On-Premises Integration As disclosed above in connection with FIG. 2, on-premise applications 218 that may reside at a client location may be managed by a cloud-based third-party identity management system, such as IDCS 202. However, typically, clients may be hesitant to allow third-party cloud services to send commands to the client through the client's firewall. In response, in an embodiment, the client first contacts IDCS 202 on its behalf to request an action (referred to as a "targeted action"), as opposed to receiving an unrequested action from IDCS 202 through the client's firewall. This feature is commonly referred to as "delegated authentication."

[0175] The embodiments solve the problem of how to manage resources on the client's premises from the cloud, given the reality that the client may not "trust" the cloud service and therefore may not open its firewall to the cloud service. The embodiments use asynchronous responses based on Java API for RESTful Web Services ("JAX-RS"). Asynchronous callbacks are performed because asynchronous callbacks are used for delegated authentication. For example, when a user logs into IDCS 202, the user is not authenticated by a local identity stored in IDCS 202, but is passed through to an on-premise active directory, such as active directory ("AD") 204 in FIG. 2. In this pass-through scenario, AD 204 will perform the authentication on behalf of IDCS 202.

[0176] However, using pass-through for authentication introduces latency from the communication between two different systems (i.e., IDCS 202 and AD 204) and from the authentication process. For example, a user must go to IDCS 202 and then back through a firewall to AD 204. Because of this latency, user authentication may take approximately 5-10 seconds.

[0177] One possible solution to reduce latency is to use HTTP request / response, specifically posting a login request directly to the Bridge / AD 204 and waiting for a response, however this solution is not optimized to prevent latency as it uses database persistence.

[0178] In contrast, the embodiment uses a cache listener as in Coherence 1200 to notify both sides (i.e., IDCS 202 and AD 204) to avoid latency, rather than persistence in a database. In the embodiment, the cache listener is a feature of the Coherence cache service, which is one of the microservices of IDCS 202. The cache listener can be realized by other types of in-memory distributed data grids in addition to Coherence. The notification (i.e., request / response) includes the time when authentication needs to be done and the completion of the authentication (i.e., whether authentication was successful or failed). Thus, a customer who already has all of their user's usernames / passwords stored in AD 204 can use IDCS 202 as a pass-through mechanism for authentication and does not need to store a duplicate username / password in IDCS 202.

[0179] In an embodiment, the AD Bridge 230 (shown in FIG. 2 as “ID” Bridge 230) is already optimized for low latency. Using the disclosed target action framework, actions can be taken against on-premise targets, but speed and low latency are required for the delegated authentication disclosed herein.

[0180] In general, the AD bridge 230 provides a link between the AD enterprise directory structure and the IDCS 202 or any other cloud-based identity service. The IDCS 202 can synchronize with this directory structure to forward any new, updated, or deleted user or group records to the IDCS 202 as needed. For example, the AD bridge 230 can poll the AD 204 for any changes to these records and bring these changes to the IDCS 202. If a user is deleted in the AD 204, this change, or any other type of change, will be communicated to the IDCS 202. Thanks to this synchronization, the state of each record is synchronized between the AD 204 and the IDCS 202. However, as disclosed above, in some cases, synchronization is not necessary since the user information may be stored only in the AD 204.

[0181] Figure 13 illustrates the functionality between IDCS 202 and on-premise active directory 204 via bridge 230 from the perspective of IDCS 202 when performing delegated authentication, according to an embodiment. Figure 14 illustrates the functionality between IDCS 202 and on-premise active directory 204 via bridge 230 when performing delegated authentication, according to an embodiment, from the perspective of active directory 204. Generally, the functionality illustrated in Figures 13 and 14 is as follows: The caller performs an action (such as POST / TargetActions or GET / AsyncTargetActions) The caller registers a listener with a particular cache. When the desired event occurs, the listener interrupts the caller. If the desired event did not occur, the caller performs a DB search via a GET / AsyncTargetAction request for pending TargetActions to be done, e.g. authentication, password change targeting AD domains managed by AD bridge polling, etc.

[0182] With regards to which entity is considered the "caller", for POST / TargetActions, the call is initiated / called when the user logs in and the login is configured for pass-through / delegated authentication to the AD domain. For GET / AsyncTargetActions, the call is initiated / called by the AD bridge 230 to initiate polling for TargetActions such as authentication, password change, user updates, etc. (collectively "authentication actions").

[0183] The elements shown in Figures 13 and 14 include SSO service 1350 and Admin service 1351. SSO service 1350 and Admin service 1351 in an embodiment are realized in separate IDCS microservices. Admin service 1351 includes all the endpoints shown, including password authenticator 1352, user 1353, target actions ("TA") 1301, target action results ("TAR") 1302, and async target actions ("ATA") 1354. These elements further include tenant database ("DB") 1355 and cache 1356, which in an embodiment is a Coherence cache and is realized as a microservice in IDCS. Cache 1356 includes three different caches that communicate with Admin service 1351: TA cache, TAR cache, and ATA cache. On the other side of the “pipe” between IDCS and the on-premises elements, the AD bridge 230 and AD 204 are on-premises.

[0184] The TA is the endpoint that the IDCS client uses to initiate a request to a target and contains any action that is requested on this target. The TAR is the result of the request. In the case of delegated authentication, the TAR is posted back to the IDCS server by the bridge 230. In general, the TA is the request and the TAR is the response. Every TA contains the appID (i.e., AD domain ID) of the targeted application. In an embodiment, all synchronous TA 1301 threads block until they get the TAR 1302 for the response. In contrast, the asynchronous TA 1354 threads poll (i.e., do not block) until they get the TAR 1302 for the response.

[0185] Referring to the functionality of FIG. 13, at 1310 the user logs into the SSO service 1350 (e.g., the user can log into IDCS 202 so that they can modify their profile as an end user, perform IDCS administrator tasks as an administrator, access other applications to which they have been granted access, etc.). At 1311 the resulting SSO service thread calls the admin service http client POST / UPA (i.e., User Password Authenticator) and blocks until the admin service 1351 returns to the admin service get thread 1 at 1312. At 1313 the UPA calls GET / Users which gets a DB connection and calls DB search (e.g., search via GET / AsyncTargetAction request for pending TargetActions such as authentication, password changes targeted to AD domains managed by AD bridge polling for work to be done). At 1314 the user is returned to the PA 1352.

[0186] At 1315, the PA 1352 calls POST / TargetAction which creates an "authenticate" TA. The TA gets a DB connection and calls DB Create at 1316 to store the TA. At 1317, the post transaction handler registers a cache listener to call back when the associated TargetActionResult is created / cached, and sleeps for the configured authentication action timeout (30 seconds in one embodiment) until the cache callback or timeout at 1318. The cache listener registered at 1317 listens for TARs for the appid (application identifier) ​​for which the TA was sent.

[0187] Referring to FIG. 14, in response to 1316, the bridge 230 calls GET / AsyncTargetAction first for the given appId at 1410, so the bridge thread blocks until the asynResponse timeout or TargetActions are returned. The bridge thread polls until the TargetActions are returned for processing or the polling timeout is reached (e.g., 60 seconds). The http thread on the IDCS server is released, but the AD bridge thread is blocked while polling. In response, at 1411, the server (i.e., the IDCS admin service servicing the AsyncTargetAction REST request) does a GET / AsyncTargetActionss and a admin service thread is created and blocks at 1412 until the asyncResponse timeout is reached (60 seconds) or until the coherence cache listener calls back when an authentication TargetAction is created for the appId that the bridge manages. At 1413 we register a cache listener to be called when a TargetAction is created for an appId that the bridge manages. The AsyncTargetAction is called back by the coherence cache listener when an authentication TargetAction is created for an appId that the bridge manages.

[0188] At 1415, the management service 1351 searches for and returns an "in progress" authentication TargetAction for the bridging appID. If there is one, it releases the management service thread bridge at 1416 and sends the authentication request to the AD 204 at 1417. The AD 204 processes the request and responds to the bridge 230 at 1418. The bridge 230 calls POST / TargetActionResult to the management service TAR 1302 at 1419. The TargetActionResult gets a DB connection at 1420, calls DB Create to store the TAR, and updates the cache with the TAR at 1422 to indicate that there are TargetActionResults to process.

[0189] Referring again to 13, at 1319, once an authentication TargetActionResult is created for the appId managed by the bridge, the Coherence cache listener calls back the TargetAction. At 1320, it gets the TargetActionResult from the cache that matches the authentication TargetAction id, adds the TargetActionResult to the TargetAction response, and at 1321 returns the TargetAction response to the UPA.

[0190] The UPA returns a response to the SSO service and releases the manager service thread 1, and the SSO service returns a response to the user at 1325. The SSO service thread is then released.

[0191] The following pseudocode example implements the delegated authentication functionality according to an embodiment.

[0192]

number

[0193] In an embodiment, there are two modes for client-initiated Target Action ("TA") requests: synchronous (sync) and asynchronous (async). · Synchronous (POST / TargetActions { "mode": "sync", ...} ) ·Asynchronous (POST / TargetActions { "mode": "async", ...} ) "Synchronous" is used for target actions, such as delegated authentication, that have very low latency and are expected to be returned to the client (e.g. a logged in user) as soon as possible regardless of success or failure. "Asynchronous" is used for target actions that do not need to respond as quickly as a synchronous request, such as changing an AD user's password, updating an AD user's profile attributes, etc.

[0194] The embodiment ensures that synchronous TAs have a higher priority than asynchronous TAs for sending to the bridge, but at the same time, asynchronous TAs are not blocked for too long by synchronous TAs. Since the priority is to send synchronous TAs to the bridge first, it is acceptable for asynchronous TAs to take longer to send to the bridge, as long as the asynchronous TAs are sent to the bridge in a reasonable time.

[0195] Thus, at a high level, embodiments treat synchronous target actions differently from asynchronous target actions. · Synchronous target actions require a "fast path" since the requestor is blocking. Asynchronous target actions take the slower path, so Synchronous target actions can be prioritized over asynchronous ones. o Target actions can be ordered as needed.

[0196] The following table summarizes the synchronous target action flow according to an embodiment. In the table below, each bridge polls long waiting for synchronous TargetActions. The IDCS client posts a synchronous TargetAction and then blocks waiting for the TargetActionResult.

[0197] [Table 1]

[0198] The following table summarizes the asynchronous target action flow according to an embodiment. In the table below, each bridge polls long waiting for asynchronous TargetActions. The IDCS client posts an asynchronous TargetAction, then polls waiting for the TargetActions.

[0199] [Table 2] TIFF0007602918000007.tif48170

[0200] As disclosed, embodiments optimize request / response flows by promoting Coherence cache callbacks. Embodiments reduce latency when a cloud-based authentication system (e.g., IDCS) interfaces with an on-premise authentication system (e.g., AD) using cache callbacks.

Claims

1. 1. A method of operating a multi-tenant cloud system, the method comprising: receiving a request for an authentication action for a user, the authentication action including processing requested for a target, the method further comprising: In response to the request, creating an authentication target action, the authentication target action including an identifier of an on-premise active directory (AD) as an identifier of a targeted application, the method further comprising: registering a cache listener to listen for target action responses in response to the authenticated target action, the cache listener generating a cache callback upon a cache event occurring, the method further comprising: initiating an authentication action for the user at the on-premises AD via a bridge in response to the authentication target action being generated; waiting for the cache callback; and receiving, in the cache callback, a target action response including a result of the authentication action.

2. The method of claim 1 , wherein the request for the authentication action is received at the multi-tenant cloud system.

3. The method of claim 2 , wherein the result of the authentication action is received from the on-premises AD.

4. while waiting for the cache callback, polling a thread created for the authentication action; The method of claim 1 , wherein the polling continues until the cache callback or a timeout.

5. The method of claim 1 , wherein the cache listener is implemented with an in-memory distributed data grid.

6. The method of claim 1 , wherein the authentication action is an asynchronous action that includes changing a password.

7. The method of claim 6 , wherein the asynchronous actions are assigned a lower priority than synchronous actions, the synchronous actions including logging in the user.

8. The method of claim 1 , wherein the multi-tenant cloud system accesses the on-premises active directory through a firewall.

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

10. 1. A multi-tenant cloud system for multiple user accounts, the system comprising: A memory storing the program according to claim 9; and at least one processor that executes the program.

Images