Multi-tenant identity cloud service with on-premises authentication integration

Abstract

Embodiments relate 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 at an on-premises active directory (“AD”) via a bridge. Embodiments wait for a cache callback and receive a target action response including a result of the authentication action upon the cache callback.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Patent Application Serial No. 62 / 899,888, filed on September 13, 2019, the disclosure of which is incorporated herein by reference. Technical Field

[0003] One embodiment relates generally to identity management, and more particularly to identity management in cloud systems. Background Art

[0004] In general, the use of cloud-based applications (e.g., enterprise public cloud applications, third-party cloud applications, etc.) is growing rapidly, with access coming from a variety of devices (e.g., desktop and mobile devices) and a variety of users (e.g., employees, partners, customers, etc.). The rich diversity and accessibility of cloud-based applications have led to identity management and access security becoming central issues. Typical security issues in cloud environments are unauthorized access, account hijacking, malicious insiders, etc. Therefore, there is a need to securely access cloud-based applications or applications located anywhere, regardless of the type of device or type of user accessing the application. Summary of the invention

[0005] Embodiments relate 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 at an on-premises active directory (“AD”) via a bridge. Embodiments wait for a cache callback, and upon the cache callback, receive a target action response including a result of the authentication action. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Figure 1-Figure 5 is a block diagram of an example embodiment that provides cloud-based identity management.

[0007] Figure 6 is a block diagram providing a system view of an embodiment.

[0008] Fig. 6A is a block diagram providing a functional view of an embodiment.

[0009] Figure 7 is a block diagram of an embodiment of implementing Cloud Gate.

[0010] Figure 8 An example system that implements multiple tenants in one embodiment is illustrated.

[0011] Fig. 9 is a block diagram of a network view of an embodiment.

[0012] Fig.10 is a block diagram of a system architectural view of single sign-on ("SSO") functionality in one embodiment.

[0013] Fig.11 is a message sequence flow for the SSO function in one embodiment.

[0014] Fig.12 An example of a distributed data grid in one embodiment is illustrated.

[0015] Fig.13 Illustrated is 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.

[0016] Fig.14 Illustrated is the functionality between IDCS and an on-premises Active Directory via a bridge from the Active Directory perspective when performing delegated authentication according to an embodiment. DETAILED DESCRIPTION

[0017] Embodiments provide an identity cloud service that implements a microservices-based architecture and provides multi-tenant identity and data security management and secure access to cloud-based applications. Embodiments utilize in-memory data grid cache callbacks to optimize the request / response flow between cloud-based authentication services and on-premises authentication systems. Embodiments reduce latency when a cloud-based authentication system (e.g., IDCS) interfaces with an on-premises authentication system using cache callbacks.

[0018] Embodiments provide identity cloud services that implement a microservices-based architecture and provide multi-tenant identity and data security management and secure access to cloud-based applications. Embodiments support secure access to hybrid cloud deployments (i.e., cloud deployments that include a combination of public and private clouds). Embodiments protect applications and data in the cloud and on-premises. Embodiments support multi-channel access via web, mobile, and application programming interfaces ("APIs"). Embodiments manage access to different users (such as customers, partners, and employees). Embodiments manage, control, and audit access across the entire cloud and on-premises. Embodiments integrate with new and existing applications and identities. Embodiments are horizontally scalable.

[0019] One embodiment is a system that implements multiple microservices in a stateless middle-tier environment to provide cloud-based multi-tenant identity and access management services. In one embodiment, each requested identity management service is decomposed into real-time tasks and near real-time tasks. Real-time tasks are processed by microservices in the middle tier, while near real-time tasks are offloaded to message queues. An embodiment implements access tokens that are consumed by the routing layer and the middle tier to enforce a security model for accessing microservices. Thus, an embodiment provides a cloud-scale identity and access management ("IAM") platform based on a multi-tenant, microservices architecture.

[0020] 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 multiple core services, each of which addresses unique challenges faced by many enterprises. In one embodiment, the identity cloud service supports administrators in the following aspects, such as initial on-boarding / importing users, importing groups with user members, creating / updating / disabling / enabling / deleting users, assigning / unassigning users to / from groups, creating / updating / deleting groups, resetting passwords, managing policies, sending activations, and the like. The identity cloud service also supports end users in the following aspects, such as modifying profiles, setting primary / recovery emails, verifying emails, unlocking their accounts, changing passwords, recovering passwords when they are forgotten, and the like.

[0021] Unified security for access

[0022] One embodiment protects applications and data in a cloud environment as well as in an on-premises environment. The embodiment protects access to any application by anyone from any device. Since an inconsistency in security between the two environments can result in a higher risk, the embodiment provides protection across both environments. For example, such an inconsistency could allow a salesperson to continue to access their customer relationship management ("CRM") account even after they have defected to a competitor. Thus, an embodiment extends the security controls provided in an on-premises environment to a cloud environment. For example, if a person leaves the company, the embodiment ensures that their account is disabled both on-premises and in the cloud.

[0023] Generally speaking, users can access applications and / or data through many different channels, such as web browsers, desktops, mobile phones, tablets, smart watches, other wearable devices, etc. Thus, one embodiment provides secure access across all of these channels. For example, a user can use their mobile phone to complete a transaction they started on a desktop.

[0024] One embodiment also manages access to various users, such as customers, partners, employees, and the like. Generally speaking, applications and / or data may be accessed not only by employees, but also by customers or third parties. While many known systems take security measures when employees log in, the same level of security measures are generally not taken when giving access to customers, third parties, partners, and the like, leading to the potential for security breaches caused by improperly managed parties. However, an embodiment ensures that adequate security measures are provided for access by each type of user, not just employee access.

[0025] Identity Cloud Service

[0026] Embodiments provide Identity Cloud Service ("IDCS") as a multi-tenant, cloud-scale IAM platform. IDCS provides authentication, authorization, auditing, and federation. IDCS manages access to custom applications and services running on public clouds and on-premises systems. In alternative or additional embodiments, IDCS can also manage access to public cloud services. For example, IDCS can be used to provide single sign-on ("SSO") functionality in such various services / applications / systems.

[0027] Embodiments are based on a multi-tenant, microservices architecture for designing, building, and delivering cloud-scale software services. Multi-tenancy refers to having one physical implementation of a service securely support multiple customers purchasing that service. A service is a software function or set of software functions that can be used by different clients for different purposes (such as retrieving specified information or performing a set of operations), as well as policies that control the use of the software function or set of software functions (e.g., based on the identity of the client requesting the service). In one embodiment, a service is a mechanism that enables access to one or more capabilities, where access is provided using a specified interface and is exercised in accordance with the constraints and policies specified by the service description.

[0028] In one embodiment, microservices are independently deployable services. In one embodiment, the term microservices envisions 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, highly decoupled services, and each microservice can focus on doing a small task. In one embodiment, the microservice architecture style is the practice of 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., HTTP resource API). In one embodiment, microservices are easier to replace than single-piece services that perform all or many of the same functions. Moreover, each microservice can be updated without adversely affecting other microservices. In contrast, an update to a part of a single-piece service can unexpectedly or unintentionally have a negative impact on other parts of the single-piece service. In one embodiment, microservices can be beneficially organized around their capabilities. In one embodiment, the startup time of each microservice in a microservice set is much less than the startup time of a single application that generally executes all services of those microservices. In some embodiments, the startup time of each microservice in such a microservice is about one second or less, while the startup time of such a single application can be about one minute, several minutes, or longer.

[0029] In one embodiment, microservice architecture refers to the specialization (i.e., separation of tasks within a system) and implementation practices for service-oriented architecture ("SOA") to build flexible, independently deployable software systems. Services in a microservice architecture are processes that communicate with each other over a network to fulfill a goal. In one embodiment, these services use technology-agnostic protocols. In one embodiment, services have small granularity and use lightweight protocols. In one embodiment, services are independently deployable. By distributing the functionality of a system into different small services, the cohesion of the system is enhanced and the coupling of the system is reduced. This makes it easier to change the system and add functionality and quality to the system at any time. It also allows the architecture of individual services to emerge through continuous refactoring, thereby reducing the need for large upfront design and allowing software to be released early and continuously.

[0030] In one embodiment, in a microservice architecture, an application is developed as a collection of services, and each service runs a corresponding process and communicates using a lightweight protocol (e.g., a unique API for each microservice). In a microservice architecture, decomposing the software into individual services / capabilities can be performed at different levels of granularity, depending on the services to be 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 unnamed universal port that can be contacted by other microservices. In one embodiment, the unnamed universal port of a microservice is a standard communication channel (e.g., as a conventional hypertext transfer protocol ("HTTP") port) that a microservice exposes by convention and allows any other module / microservice in the same service to talk to it. Microservices or any other self-contained functional modules can be collectively referred to as "services."

[0031] Embodiments provide multi-tenant identity management services. Embodiments are based on open standards to ensure easy integration with various applications, thereby delivering IAM capabilities through standards-based services.

[0032] Embodiments manage the lifecycle of user identities, which requires determining and enforcing what an identity can access, who can be given such access, who can manage such access, etc. For applications that are not necessarily in the cloud, embodiments run identity management workloads in the cloud and support security functions. Identity management services provided by embodiments can be purchased from the cloud. For example, an enterprise can purchase such services from the cloud to manage their employees' access to their applications.

[0033] Embodiments provide system security, massive scalability, end-user availability, and application interoperability. Embodiments address the growth of the cloud and customer usage of identity services. A microservices-based foundation addresses horizontal scalability requirements, while careful orchestration of services addresses functional requirements. Achieving these two goals requires decomposing business logic (as much as possible) to achieve statelessness with eventual consistency, while most operational logic that is not subject to real-time processing is moved to near real-time with guaranteed delivery and processing by offloading to a highly scalable asynchronous event management system. Embodiments are fully multi-tenant from the network layer to the data layer to achieve cost efficiency and ease of system management.

[0034] Embodiments are based on 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.) to facilitate integration with various applications. One embodiment provides a cloud-scale API platform and implements horizontally scalable microservices for elastic scalability. The embodiment fully leverages cloud principles and provides a multi-tenant architecture with per-tenant data separation. The embodiment also provides per-tenant customization with tenant self-service. The embodiment can be used for on-demand integration with other identity services via APIs and provides continuous feature releases.

[0035] One embodiment provides interoperability and leverages investments in identity management ("IDM") capabilities in the cloud and on-premises. The embodiment provides automated identity synchronization from on-premises 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 and allows different options for hybrid cloud deployments (e.g., identity federation and / or synchronization, SSO proxy, user provisioning connectors, etc.).

[0036] Thus, one embodiment is a system that implements multiple microservices in a stateless middle tier to provide cloud-based multi-tenant identity and access management services. In one embodiment, each requested identity management service is decomposed into real-time tasks and near real-time tasks. Real-time tasks are handled by microservices in the middle tier, while near real-time tasks are offloaded to message queues. An embodiment implements tokens that are consumed by the routing layer to enforce a security model for accessing microservices. Thus, an embodiment provides a cloud-scale IAM platform based on a multi-tenant, microservices architecture.

[0037] Generally speaking, known systems provide siloed access to applications provided by different environments (e.g., 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 de-provisioning schemes, disparate auditing, etc. However, one embodiment implements IDCS to provide unified IAM functionality across such applications. Figure 11 is a block diagram 100 of an example embodiment with an IDCS 118 that provides a unified identity platform 126 for logging in 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. The applications 102, 104, 110, 112 can be accessed through different channels, for example, by a mobile phone user 108 via a mobile phone 106, by a desktop computer user 116 via a browser 114, and so on. A web browser (commonly referred to as a browser) is a software application used to retrieve, present, and traverse information resources on the World Wide Web. An example of a web browser is Mozilla Firefox. Google Microsoft Internet and Apple

[0038] IDCS 118 provides a unified view 124 of a user's applications, unified security credentials across devices and applications (via identity platform 126), and a unified management approach (via management console 122). IDCS services can be obtained by calling IDCS API 142. Such services can include, for example, login / SSO services 128 (e.g., OpenID Connect), federation services 130 (e.g., SAML), token services 132 (e.g., OAuth), directory services 134 (e.g., SCIM), provisioning services 136 (e.g., SCIM or any transport over multiple protocols ("ATOM")), event services 138 (e.g., REST), and authorization services 140 (e.g., SCIM). IDCS 118 can also provide reports and dashboards 120 related to the services provided.

[0039] Integrated Tools

[0040] Generally speaking, large companies often have IAM systems to protect access to their on-premises applications. Business practices are often mature and standardized around internal IAM systems, such as the "Oracle IAM Suite" from Oracle Corporation. Even small and medium-sized enterprises often design their business processes around managing user access through simple directory solutions, such as Microsoft Active Directory ("AD"). To enable on-premises integration, an embodiment provides tools that allow customers to integrate their applications with IDCS.

[0041] Figure 22 is a block diagram 200 of an example embodiment with IDCS 202 in a cloud environment 208, which provides integration with AD 204 on-premises 206. The embodiment provides a seamless user experience across all applications including on-premises and third-party applications (e.g., on-premises applications 218 and various applications / services in cloud 208 such as cloud services 210, cloud applications 212, partner applications 214, and customer applications 216). Cloud applications 212 may include, for example, human capital management (“HCM”), CRM, talent acquisition (e.g., Oracle Taleo Cloud Service from Oracle Corporation), configure price and quote (“CPQ”), and the like. Cloud services 210 may include, for example, platform as a service (“PaaS”), Java, databases, business intelligence (“BI”), documents, and the like.

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

[0043] 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 based on standard HTTP-based mechanisms (such as web services, web server proxies, etc.). Communications in an identity bus can be based on corresponding protocols (e.g., SCIM, SAML, OpenID Connect, etc.). For example, a SAML bus is an HTTP-based connection between two systems for transmitting messages for SAML services. Similarly, a SCIM bus is used to transmit SCIM messages according to the SCIM protocol.

[0044] Figure 2An embodiment of IDCS implements an identity ("ID") bridge 230, which is a small binary file (e.g., 1MB in size) that can be downloaded and installed on the on-premises 206 along with the customer's AD 204. The ID bridge 230 listens for users and groups (e.g., user groups) from an organizational unit ("OU") selected by the customer and synchronizes those users to the cloud 208. In one embodiment, the user's password 232 is not synchronized to the cloud 208. Customers can manage the user's application access by mapping the IDCS user's groups to the cloud applications managed in IDCS 208. Whenever a user's group membership is changed on the on-premises 206, its corresponding cloud application access automatically changes.

[0045] For example, an employee who moves from engineering to sales can have almost instant access to the sales cloud and lose access to the developer cloud. When this change is reflected in the on-premises AD 204, the cloud application access change is done in near real time. Similarly, for users who leave the company, access to cloud applications managed in IDCS 208 is revoked. To be fully automated, customers can set up SSO between on-premises AD 204 and IDCS 208 through, for example, AD Federation Services ("AD / FS" or some other mechanism that implements SAML federation) so that end users can access cloud applications 210, 212, 214, 216 as well as on-premises applications 218 with a single corporate password 332.

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

[0047] exist Figure 3In an embodiment of the invention, an Oracle Identity Manager ("OIM") connector 302 from Oracle Corporation and an Oracle Access Manager ("OAM") federation module 306 from Oracle Corporation are implemented as extension modules of Oracle IDM 304. A connector is a module that has physical awareness about how to talk to a system. OIM is an application configured to manage user identities (e.g., managing user accounts in different systems based on what the user should and should not have access to). OAM is a security application that provides access management functions 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, then the OIM connector 302 and OAM federation 306 can be used with Oracle IDM 304 to create / delete that account and manage access from that account.

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

[0049] Generally speaking, applications that are configured to communicate over LDAP require an LDAP connection. Since LDAP needs to be on the local network, such applications cannot establish an LDAP connection via a URL (unlike, for example, "www.google.com" to connect to Google). Figure 4 In an embodiment of the present invention, the LDAP-based application 218 makes a connection to the cloud cache 402, and the cloud cache 402 establishes a connection to the IDCS 202 and then pulls data from the IDCS 202 when it is requested. The communication between the IDCS 202 and the cloud cache 402 can be implemented according to the SCIM protocol. For example, the cloud cache 402 can use the SCIM bus 234 to send SCIM requests to the IDCS 202 and receive corresponding data in return.

[0050] Generally speaking, fully implementing an application includes building a consumer portal, running marketing campaigns on external user groups, supporting web and mobile channels, and handling user authentication, sessions, user profiles, user groups, application roles, password policies, self-service / registration, social integration, identity federation, etc. Generally speaking, application developers are not identity / security experts. Therefore, on-demand identity management services are desirable.

[0051] Figure 5 is included with Figure 2-Figure 4 500 of an example embodiment of the same components 202, 220, 222, 224, 226, 234, 402 in FIG. Figure 5 In an embodiment of the present invention, IDCS 202 provides secure identity management on demand. This embodiment provides integration with the identity service of IDCS 202 on demand (e.g., based on standards such as OpenID Connect, OAuth2, SAML2, or SCIM). Applications 505 (which can be deployed on-premises, in a public cloud, or in a private cloud) can call identity service APIs 504 in IDCS 202. Services provided by IDCS 202 can include, for example, self-service registration 506, password management 508, user profile management 510, user authentication 512, token management 514, social integration 516, and the like.

[0052] In this embodiment, the SCIM identity bus 234 is used to synchronize data in IDCS 202 with data in an on-premises LDAP cloud cache 402. In addition, a "Cloud Gate" 502 running on a web server / agent (e.g., NGINX, Apache, etc.) can be used by applications 505 to obtain user web SSO and REST API security from IDCS 202. Cloud Gate 502 is a component that protects access to multi-tenant IDCS microservices by ensuring that the client application provides a valid access token and / or the user successfully authenticates in order to establish an SSO session. Cloud Gate 502 is further disclosed below. Cloud Gate 502 (an enforcement point similar to webgate / webagent) enables applications running behind supported web servers to participate in SSO.

[0053] One embodiment provides SSO and cloud SSO functionality. In many organizations, the general entry point for on-premises IAM and IDCS is SSO. Cloud SSO enables users to access multiple cloud resources with a single user login. Organizations often want to federate their on-premises identities. Thus, embodiments utilize open standards to allow integration with existing SSO to preserve and extend investments (e.g., until a complete final transition to an identity cloud service approach is made).

[0054] One embodiment may provide the following functionality:

[0055] Maintain an identity store to track authorized user accounts, ownership, access, and permissions,

[0056] Integrate with workflow to facilitate the various approvals required for application access (e.g., management, IT, HR, legal, and compliance),

[0057] Provisioning SaaS user accounts for select devices (e.g., mobile and personal computers (“PCs”)) to access a user portal containing many private and public cloud resources,

[0058] ·Facilitate periodic management attestation reviews to comply with regulations and current job responsibilities.

[0059] In addition to these features, embodiments may also provide:

[0060] Cloud account provisioning to manage the account lifecycle in cloud applications,

[0061] More robust multi-factor authentication (“MFA”) integration,

[0062] Extensive mobile security capabilities, and

[0063] Dynamic authentication options.

[0064] One embodiment provides adaptive authentication and MFA. In general, passwords and challenge questions are considered insufficient and vulnerable to common attacks such as phishing. Most commercial entities today are looking for some form of MFA to reduce risk. However, in order to be successfully deployed, the solution needs to be easily provisioned, maintained, and understood by end users, as end users typically resist anything that interferes with their digital experience. Companies are looking for ways to securely combine bring your own device ("BYOD"), social identity, remote users, customers, and contractors, while making MFA an almost transparent component of a seamless user access experience. In MFA deployments, industry standards such as OAuth and OpenID Connect are critical to ensuring the integration of existing multi-factor solutions and the combination of new adaptive authentication technologies. Thus, an embodiment defines dynamic (or adaptive) authentication as the evaluation of available information (i.e., IP address, location, time of day, and biometrics) that proves identity after a user session has been initiated. Embodiments provide an MFA solution that can be easily adopted, upgraded, and integrated in an IT organization as part of an end-to-end secure IAM deployment through an integrated and extensible identity management framework with appropriate standards (e.g., Open Authentication ("OATH") and Fast Identity Online ("FIDO")). When considering MFA and adaptive policies, organizations must implement consistent policies across on-premises and cloud resources, which requires integration between systems in a hybrid IDCS and on-premises IAM environment.

[0065] One embodiment provides user provisioning and certification. In general, the basic function of an IAM solution is to enable and support the entire user provisioning lifecycle. This includes providing users with application access appropriate to their identity and role within the organization, verifying that they have the correct ongoing access permissions (for example, when their role or the tasks or applications used within their role change over time), and quickly releasing the provisioning when they leave the organization. This is important not only to meet various compliance requirements, but also because inappropriate insider access is a major source of security vulnerabilities and attacks. The automated user provisioning capabilities in the identity cloud solution can be used not only as an important component in itself, but also as part of a hybrid IAM solution, whereby IDCS provisioning can provide greater flexibility than on-premises solutions for transitions when companies downsize, scale up, merge, or look to integrate existing systems with IaaS / PaaS / SaaS environments. The IDCS approach can save time and effort for one-time upgrades and ensure proper integration between necessary departments, divisions, and systems. The need to scale this technology is often quietly discovered in enterprises, and the ability to deliver scalable IDCS capabilities immediately across enterprises can provide benefits in terms of flexibility, cost, and control.

[0066] Generally speaking, an employee is granted additional privileges over the years as her / his job changes (i.e., "privilege creep"). Lightly regulated companies generally lack an "attestation" process that requires managers to regularly audit employee privileges (e.g., access to networks, servers, applications, and data) to stop or slow down privilege creep that leads to super-privileged accounts. Thus, one embodiment may provide for an attestation process that is performed regularly (at least once a year). In addition, with mergers and acquisitions, the demand for these tools and services will grow exponentially as users are on SaaS systems, on-premises, across different departments, and / or are being de-provisioned or reassigned. Migration to the cloud can further complicate this situation, and the process can quickly escalate beyond existing, often manually managed attestation methods. Thus, one embodiment automates these functions and applies sophisticated analytics to user profiles, access history, provisioning / de-provisioning, and fine-grained empowerment.

[0067] One embodiment provides identity analytics. In general, being able to integrate identity analytics with an IAM engine for comprehensive verification and attestation is critical to ensuring an organization's risk profile. Properly deployed identity analytics can require comprehensive internal policy enforcement. In a proactive governance, risk, and compliance ("GRC") enterprise environment, identity analytics that provide a unified single management view across cloud and on-premises deployments are highly desirable and can help provide a closed-loop process to reduce risk and meet compliance regulations. Thus, one embodiment provides identity analytics that can be easily customized by the client to accommodate specific industry requirements and government regulations for reporting and analysis required by managers, executives, and auditors.

[0068] One embodiment provides self-service and access request capabilities to improve end-user experience and efficiency and reduce the cost of help desk calls. In general, while many companies have deployed on-premises self-service access requests for employees, many companies have not fully extended these systems outside of the formal company scope. In addition to employee use, a positive digital customer experience increases business reputation and ultimately helps increase revenue, and companies can not only save customer service desk calls and costs, but also improve customer satisfaction. Thus, one embodiment provides an identity cloud service environment that is based on open standards and seamlessly integrates with existing access control software and MFA mechanisms when necessary. The SaaS delivery model saves time and energy previously invested in system upgrades and maintenance, allowing professional IT personnel to focus on more core business applications.

[0069] One embodiment provides privileged account management ("PAM"). In general, whether using SaaS, PaaS, IaaS or on-premises applications, every organization is vulnerable to the abuse of unauthorized privileged accounts by insiders (such as system administrators, supervisors, HR managers, contractors, system integrators, etc.) with super user access credentials. Moreover, external threats usually first break through low-level user accounts to ultimately reach and exploit privileged user access controls within enterprise systems. Thus, one embodiment provides PAM to prevent such unauthorized use of insider accounts. The main component of a PAM solution is a password vault that can be delivered in various ways, such as software installed on an enterprise server, as a virtual appliance on the same enterprise server, as a packaged hardware / software appliance, or as part of a cloud service. The PAM function is similar to a physical safe for storing passwords that are kept in envelopes and changed regularly, with a checklist for signing in and out. One embodiment allows password verification (password checkout) as well as setting time limits, enforcing periodic changes, automatically tracking verification, and reporting all activities. One embodiment provides a way to connect directly to the requested resource without the user even knowing the password. This capability also paves the way for session management and additional functionality.

[0070] In general, most cloud services utilize APIs and management interfaces, which provide opportunities for infiltrators to bypass security. Thus, one embodiment considers these vulnerabilities in PAM practices because the move to the cloud brings new challenges to PAM. Many small and medium-sized enterprises are now managing their own SaaS systems (e.g., Office 365), while larger enterprises increasingly have their own business units that are spinning up their own SaaS and IaaS services. These customers find themselves with PAM capabilities in the identity cloud service solution or its IaaS / PaaS provider, but are inexperienced in handling this responsibility. Moreover, in some cases, many different geographically dispersed business units are trying to isolate management responsibilities for the same SaaS application. Thus, one embodiment allows customers in these cases to link existing PAM into the overall identity framework of the identity cloud service and move toward greater security and compliance with requirements to ensure scaling to cloud loads as dictated by business needs.

[0071] API Platform

[0072] An embodiment provides an API platform that exposes a collection of capabilities as services. APIs are aggregated into microservices, and each microservice exposes one or more of the APIs. That is, each microservice can expose different types of APIs. In one embodiment, each microservice communicates only through its API. In one embodiment, each API can be a microservice. In one embodiment, multiple APIs are aggregated into the service based on the target capabilities to be provided by the service (e.g., OAuth, SAML, administrator, etc.). Therefore, similar APIs are not exposed as separate runtime processes. APIs are what make it possible for service consumers to use the services provided by IDCS.

[0073] Generally speaking, in the web environment of IDCS, the URL includes three parts: host, microservice, and resource (e.g., host / microservice / resource). In one embodiment, the microservice is characterized by having a specific URL prefix, such as "host / oauth / v1", where the actual microservice is "oauth / v1", and there are multiple APIs under "oauth / v1", such as the API for requesting a token: "host / oauth / v1 / token", the API for authenticating a user: "host / oauth / v1 / authorization", etc. That is, the URL implements the microservice, and the resource part of the URL implements the API. Thus, multiple APIs are aggregated under the same microservice. In one embodiment, the host part of the URL identifies the tenant (e.g., "https: / / tenant3.identity.oraclecloud.com: / oauth / v1 / token").

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

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

[0076] In one embodiment, HTTP requests for applications / services 602 requiring IDCS services pass through Oracle Public Cloud BIG-IP application 604 and IDCS BIG-IP application 606 (or similar technology, such as a load balancer, or a component known as 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 IDCS BIG-IP application 606 (or similar technology, such as a load balancer or cloud LBaaS, as applicable), cloud provisioning engine 608 performs tenant and service orchestration. In one embodiment, cloud provisioning engine 608 manages internal security artifacts associated with new tenants being onboarded into the cloud or new service instances purchased by customers.

[0077] The HTTP request is then received by the IDCS web routing layer 610, which implements the security gate (i.e., cloud gate) and provides service routing as well as microservice registration and discovery 612. Depending on the requested service, the HTTP request is forwarded to the IDCS microservice in the IDCS middle layer 614. The IDCS microservice handles external and internal HTTP requests. The IDCS microservice implements platform services and infrastructure services. The IDCS platform service is a separately deployed Java-based runtime service that implements the business of IDCS. The IDCS infrastructure service is a separately deployed runtime service that provides infrastructure support for IDCS. IDCS also includes an infrastructure library, which is a common code packaged as a shared library used by IDCS services and shared libraries. Infrastructure services and libraries provide the support capabilities required by platform services to implement their functions.

[0078] Platform Services

[0079] In one embodiment, IDCS supports standard authentication protocols, so IDCS microservices include platform services such as OpenID Connect, OAuth, SAML2, System for Cross-Domain Identity Management++ ("SCIM++"), and the like.

[0080] The OpenID Connect platform service implements the standard OpenID Connect login / logout flow. Interactive, web-based native applications leverage the standard browser-based OpenID Connect flow to request user authentication, receiving a standard identity token that is a JavaScript Object Notation ("JSON") 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 (including the JWT identity token). Authentication interactions initiated via the OpenID Connect protocol are delegated to a trusted SSO service, which implements the user login / logout ceremonies for local and federated logins. See below for more information. Fig.10 and Fig.11 More details of this functionality are disclosed. In one embodiment, the OpenID Connect functionality is implemented according to, for example, the OpenID Foundation standard.

[0081] The OAuth2 platform service provides token authorization services. It provides a rich API infrastructure for creating and verifying access tokens that convey user permissions to make API calls. It supports a range of useful token grant types, enabling customers to securely connect clients to their services. It implements standard two-legged and three-legged OAuth2 token grant types. Support for OpenID Connect ("OIDC") enables compatible applications (OIDC relay parties ("RPs")) to integrate with IDCS as identity providers (OIDC OpenID providers ("OPs")). Similarly, integrating IDCS as an OIDC RP with social OIDC OPs (e.g., Facebook, Google, etc.) enables customers to allow access to applications based on social identity policies. In one embodiment, OAuth functionality is implemented according to, for example, Internet Engineering Task Force ("IETF") request for comments ("RFC") document 6749.

[0082] The SAML2 platform service provides identity federation services. It enables customers to establish federation agreements with their partners based on the SAML Identity Provider ("IDP") and SAML Service Provider ("SP") relationship model. In one embodiment, the SAML2 platform service implements the standard SAML2 browser POST login and logout profiles. In one embodiment, the SAML functionality is implemented according to, for example, IETF, RFC7522.

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

[0084] All IDCS configuration artifacts are resources, and the management service's API allows management of IDCS resources (e.g., users, roles, password policies, applications, SAML / OIDC identity providers, SAML service providers, keys, certifications, notification templates, etc.). The management service leverages and extends the SCIM standard to implement a schema-based REST API for create, read, update, delete, and query ("CRUDQ") operations on all IDCS resources. In addition, all IDCS internal resources used to manage and configure IDCS itself are exposed as SCIM-based REST APIs. Access to the identity repository 618 is isolated to the SCIM++ API.

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

[0086] The Management Service supports SCIM 2.0 standard endpoints using the standard SCIM 2.0 core schema and schema extensions where needed. In addition, the Management Service supports several SCIM 2.0 compatible endpoint extensions to manage other IDCS resources, such as users, groups, applications, settings, etc. The Management 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", "serPasswordValidator", etc.

[0087] The IDCS management API uses the OAuth2 protocol for authentication and authorization. IDCS supports common OAuth2 scenarios, such as those for web servers, mobile, and JavaScript applications. Access to the IDCS API is protected by access tokens. In order to access the IDCS management API, the application needs to register the application as an OAuth2 client or IDCS application through the IDCS management console (in this case, the OAuth2 client is automatically created) and 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 the token, the application sends the access token to the IDCS API by including it in the HTTP Authorization header. Applications can use the IDCS management REST API directly, or use the IDCS Java client API library.

[0088] Infrastructure Services

[0089] IDCS infrastructure services support the functionality of IDCS platform services. These runtime services include: Event Processing Service (for asynchronous processing of user notifications, application subscriptions, and database audits); Job Scheduler Service (for scheduling and executing jobs, e.g., long-running tasks that execute immediately or at a configured time and do not require user intervention); Cache Management Service; Storage Management Service (for integration with public cloud storage services); Reporting Service (for generating reports and dashboards); SSO Service (for managing internal user authentication and SSO); User Interface ("UI") Service (for hosting different types of UI clients); and Service Manager Service. The Service Manager is the internal interface between Oracle Public Cloud and IDCS. The Service Manager manages commands issued by Oracle Public Cloud that need to be implemented by IDCS. For example, when a customer signs up for an account before purchasing something in the Cloud Store, the Cloud sends a request to IDCS to create a tenant. In this case, the Service Manager implements the cloud-specific operations that the Cloud expects IDCS to support.

[0090] An IDCS microservice can call another IDCS microservice through a network interface (i.e., HTTP request).

[0091] In one embodiment, IDCS can also provide a schema service (or persistence service) that allows the use of database schemas. The schema service allows the responsibility of managing the 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 that functionality. For example, a user can use a database to persist schemas on a per-tenant basis, and when there is no more space in the database, the schema service will manage the functionality of obtaining another database and adding space so that the user does not have to manage the database themselves.

[0092] IDCS also includes data stores, which are repositories of data required / generated by IDCS, including identity repository 618 (stores users, groups, etc.), global database 620 (stores configuration data used by IDCS to configure itself), operation mode 622 (provides schema separation per tenant and stores customer data on a per-customer basis), audit mode 624 (stores audit data), cache cluster 626 (stores cached objects to accelerate performance), etc. All internal and external IDCS consumers integrate with the identity service via standards-based protocols. This enables the use of the Domain Name System ("DNS") to resolve where to route requests, and decouples consuming applications from understanding the internal implementation of the identity service.

[0093] Real-time and near-real-time tasks

[0094] IDCS separates the tasks of the requested service into synchronous real-time tasks and asynchronous near-real-time tasks, where real-time tasks include only the operations required for the user to move forward. In one embodiment, a real-time task is a task that is executed with minimal delay, while a near-real-time task is a task that is executed in the background without the user having to wait for it. In one embodiment, a real-time task is a task that is executed with essentially no delay or with negligible delay and is executed almost instantaneously for the user.

[0095] Real-time tasks perform the primary business functions of a specific identity service. For example, when a login service is requested, the application sends a message to authenticate the user's credentials and obtains a session cookie in return. What the user experiences is logging into the system. However, several other tasks may be performed in conjunction with the user's login, such as verifying who the user is, auditing, sending notifications, and so on. Thus, verifying credentials is a task that is performed in real time, so that the user is given an HTTP cookie to start a session, but tasks related to notifications (e.g., sending an email to notify the account creation), auditing (e.g., tracking / logging), etc. are near real-time tasks that can be performed asynchronously so that the user can move on with minimal delay.

[0096] When an HTTP request for a microservice is received, the corresponding real-time task is performed by the microservice in the middle tier, while the remaining near real-time tasks (such as operational logic / events that do not have to be processed in real time) are offloaded to the message queue 628, which 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 to enable IDCS to provide advanced services to customers by reducing latency in response time. For example, login processing may include verification of credentials, submission of log reports, updating of last login time, etc., but these tasks can be offloaded to the message queue and performed in near real time rather than real time.

[0097] In one example, the 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 that when the user is created in the identity repository 618, the user gets a notification email that includes a link to reset their password. When IDCS receives a request to register or create a new user, the corresponding microservice looks in the operational database (located at Figure 6 The microservice reads the configuration data in the global database 620 in the config data and determines that the "create user" operation is marked with a "create user" event, which is identified as an asynchronous operation in the configuration data. The microservice returns to the client and indicates that the creation of the user was completed successfully, but the actual sending of the notification email is deferred and pushed to the backend. To do this, the microservice uses the messaging API 616 to queue the message in the queue 628 as storage.

[0098] To dequeue from queue 628, the messaging microservice, which is an infrastructure microservice, runs continuously in the background and scans queue 628 to find events in queue 628. Events in queue 628 are processed by event subscribers 630, such as auditing, user notification, application subscription, data analysis, etc. Depending on the task indicated by the event, event subscriber 630 can communicate with, for example, audit mode 624, user notification service 634, identity event subscriber 632, etc. For example, when the messaging microservice finds a "create user" event in queue 628, it executes the corresponding notification logic and sends a corresponding email to the user.

[0099] In one embodiment, queue 628 queues operational events published by microservices 614 and resource events published by API 616 that manages IDCS resources.

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

[0101] In one embodiment, the IDCS runtime components publish health and operational metrics to a public cloud monitoring module 636, which collects such metrics from a public cloud, such as the Oracle Public Cloud from Oracle Corporation.

[0102] In one embodiment, IDCS can be used to create users. For example, client application 602 can issue a REST API call to create a user. The management service (platform service in 614) delegates the call to the user manager (infrastructure library / service in 614), which in turn creates the user in the tenant-specific ID storage stripe in the ID repository 618. On "user creation success", the user manager audits the operation of the audit table in audit mode 624 and publishes the "identity.user.create.success" event to the message queue 628. The identity subscriber 632 picks up the event and sends a "welcome" email to the newly created user, including the newly created login details information.

[0103] In one embodiment, IDCS can be used to grant roles to users, resulting in user provisioning actions. For example, a client application 602 can issue a REST API call that grants a user role. The management service (platform service in 614) delegates the call to the role manager (infrastructure library / service in 614), which stripes the granted user role in the ID store specific to the tenant in the ID repository 618. When "role grant success", the role manager audits the operation of the audit table in audit mode 624 and publishes the "identity.user.role.grant.success" event to the message queue 628. The identity subscriber 632 picks up the event and evaluates the provisioning authorization policy. If there is an active application grant when the role is granted, the provisioning subscriber performs some kind of verification, initiates account creation, calls out the target system, creates an account on 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 aggregating the number of accounts created in the target system in the past N days.

[0104] In one embodiment, IDCS can be used for user login. For example, client application 602 can request a user's login using one of the supported authentication flows. IDCS authenticates the user and, upon success, audits the operation in the audit table in audit mode 624. Upon failure, IDCS audits the failure in audit mode 624 and publishes a "login.user.login.failure" event in message queue 628. The login subscriber picks up the event, updates its metrics for the user, and determines whether additional analysis of the user's access history needs to be performed.

[0105] Thus, by implementing "inversion of control" functionality (e.g., changing the flow of execution to schedule the execution of an operation at a later time so that the operation is under the control of another system), embodiments enable additional event queues and subscribers to be added dynamically in order to test new functionality against a small sample of users before deploying to a broader user base, or to handle specific events for specific internal or external customers.

[0106] Stateless functions

[0107] IDCS microservices are stateless, meaning that the microservices themselves do not maintain state. "State" refers to the data used by the application in order to perform its functions. IDCS provides multi-tenancy capabilities by persisting all state to tenant-specific repositories in the IDCS data layer. The middle layer (i.e., the code that handles requests) does not have data stored in the same location as the application code. As a result, IDCS is highly scalable both horizontally and vertically.

[0108] Vertical scaling (or scaling up / down) means adding resources to (or removing resources from) a single node in a system, typically involving adding CPU or memory to a single computer. Vertical scalability allows an application to scale to the limits of its hardware. Horizontal scaling (or scaling up / down) means adding more nodes to (or removing nodes from) a system, such as adding a new 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.

[0109] The statelessness of the IDCS middle tier enables horizontal scaling simply by adding more CPUs, and the IDCS components that perform the work of the application do not need to have a designated physical infrastructure to run a specific application. The statelessness of the IDCS middle tier makes IDCS highly available, even when providing identity services to a large number of customers / tenants. Each time through the IDCS application / service, only CPU usage is focused on executing the application transaction itself, without using hardware to store data. Scaling is accomplished by adding more slices while the application is running, and the data used for the transaction is stored on the persistence layer, where more replicas can be added when needed.

[0110] IDCS network layer, middle layer and data layer can be scaled independently and separately. The web layer can be scaled to handle more HTTP requests. The middle layer can be scaled to support more service functions. The data layer can be scaled to support more tenants.

[0111] IDCS Functional View

[0112] Fig. 6A 600b is an example block diagram of a functional view of IDCS in one embodiment. In block diagram 600b, the IDCS functional stack includes services, shared libraries, and data storage. Services include IDCS platform services 640b, IDCS advanced services 650b, and IDCS infrastructure services 662b. In one embodiment, IDCS platform services 640b and IDCS advanced services 650b are separately deployed, Java-based runtime services that implement the business of IDCS, while IDCS infrastructure services 662b are separately deployed runtime services that provide infrastructure support for IDCS. Shared libraries include IDCS infrastructure libraries 680b, which are common code packaged as shared libraries used by IDCS services and shared libraries. Data storage is a repository of data required / generated by IDCS, including identity storage 698b, global configuration 700b, message storage 702b, global tenants 704b, personalization settings 706b, resources 708b, user transient data 710b, system transient data 712b, per-tenant mode (managed ExaData) 714b, operational storage (not shown), cache storage (not shown), etc.

[0113] 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 advanced services include, for example, cloud SSO and governance 652b, enterprise governance 654b, AuthN broker 656b, federation broker 658b, and private account management 660b.

[0114] IDCS infrastructure services 662b and IDCS infrastructure library 680b provide the support capabilities that IDCS platform services 640b need to do their job. In one embodiment, IDCS infrastructure services 662b include job scheduler 664b, UI 666b, SSO 668b, reporting 670b, cache 672b, storage 674b, service manager 676b (public cloud control), and event processor 678b (user notification, application subscription, audit, data analysis). In one embodiment, IDCS infrastructure library 680b includes data manager API 682b, event API 684b, storage API 686b, authentication API 688b, authorization API 690b, cookie API 692b, key API 694b, and credential API 696b. In one embodiment, cloud computing services 602b (internal Nimbula) support the functions of IDCS infrastructure services 662b and IDCS infrastructure library 680b.

[0115] In one embodiment, IDCS provides various UIs 602b for consumers of IDCS services, such as customer end-user UI 604b, customer management UI 606b, DevOps management UI 608b, and login UI 610b. In one embodiment, IDCS allows integration 612b and firmware integration 620b of applications (e.g., customer applications 614b, partner applications 616b, and cloud applications 618b). In one embodiment, various environments can be integrated with IDCS to support their access control requirements. This integration can be provided by, for example, identity bridge 622b (providing AD integration, WNA, and SCIM connectors), Apache agent 624b, or MSFT agent 626b.

[0116] In one embodiment, internal and external IDCS consumers integrate with IDCS's identity service via standards-based protocols 628b, such as OpenIDConnect 630b, OAuth2 632b, SAML2 634b, SCIM 636b, and REST / HTTP 638b. This enables the use of the Domain Name System ("DNS") to resolve where to route requests, and decouples consuming applications from understanding the internal implementation of the identity service.

[0117] Fig. 6A The IDCS functional view in also includes public cloud infrastructure services, which provide common functionality that IDCS relies on for user notifications (Cloud Notification Service 718b), file storage (Cloud Storage Service 716b), and metrics / alerts for DevOps (Cloud Monitoring Service (EM) 722b and Cloud Metrics Service (Graphite) 720b).

[0118] Cloud Gate

[0119] In one embodiment, IDCS implements "Cloud Gate" in the web tier. Cloud Gate is a web server plugin that enables web applications to externalize user SSO to an identity management system (e.g., IDCS), similar to the WebGate or WebAgent technology that works with an enterprise IDM stack. Cloud Gate acts as a security guard to protect access to the IDCS API. In one embodiment, Cloud Gate is implemented by a web / proxy server plugin that provides a web policy enforcement point ("PEP") for protecting HTTP resources based on OAuth.

[0120] Figure 7 700 is a block diagram of an embodiment of an implementation of a Cloud Gate 702 that runs in a web server 712 and acts as a Policy Enforcement Point ("PEP") configured to integrate with an IDCS Policy Decision Point ("PDP") using open standards (e.g., OAuth2, OpenID Connect, etc.) while protecting access to an application's REST API resources and a web browser 714. In some embodiments, the PDP is implemented on an OAuth and / or OpenID Connect microservice 704. For example, when a user browser 706 sends a request to IDCS for a login for a user 710, the corresponding IDCS PDP validates the credentials and then decides whether the credentials are sufficient (e.g., whether to request further credentials such as a second password). Figure 7 In the embodiment of the present invention, Cloud Gate 702 can act as both a PEP and a PDP because it has a local policy.

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

[0122] During web 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. The flow ends with the delivery of the JWT as an identity token. Cloud Gate 708 verifies the JWT (e.g., checks the signature, expiration, destination / audience, etc.) and issues a local session cookie for the user 710. It acts as a session manager 716 to protect web browser access to protected resources and to issue, update, and verify local session cookies. It also provides a logout URL for removing its local session cookie.

[0123] Cloud portal 702 also acts as HTTP basic authentication authenticator, thereby verifying HTTP basic authentication credentials for IDCS. This behavior is supported in both sessionless and session-based (local session cookie) modes. In this case, the IDCS session on the server side is not created.

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

[0125] In general, 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 these embodiments, the implementation of OAuth in Cloud Gate is based on JWT, which defines a format for web tokens, such as provided by, for example, IETF, RFC 7519.

[0126] When a user logs in, a JWT is issued. The JWT is signed by IDCS and supports multi-tenancy capabilities in IDCS. Cloud Gate verifies the JWT issued by IDCS to allow multi-tenancy capabilities in IDCS. Thus, IDCS provides multi-tenancy in the physical structure as well as in the logical business processes that support the security model.

[0127] Lease Type

[0128] IDCS specifies three types of leases: customer leases, client leases, and user leases. Customer or resource leases specify who the customer of IDCS is (i.e., for whom the work is being performed). Client leases specify which client application is trying to access the data (i.e., which application is doing the work). User leases specify which user is using the application to access the data (i.e., who is doing the work). For example, when a professional services company provides system integration capabilities for a warehouse club and uses IDCS to provide identity management for the warehouse club system, the user lease corresponds to the professional services company, the client lease is the application used to provide the system integration capabilities, and the customer lease is the warehouse club.

[0129] The separation and identification of these three leases enables multi-tenancy capabilities in cloud-based services. Generally speaking, for on-premises software installed on an on-premises physical machine, there is no need to specify three different leases because the user needs to physically log in on the machine. However, in a cloud-based service structure, an embodiment uses tokens to determine who is using what application to access which resources. These three leases are encoded by the tokens, enforced by Cloud Gate and used by the business services in the middle tier. In one embodiment, an OAuth server generates the tokens. In various embodiments, the tokens can be used in conjunction with any security protocol other than OAuth.

[0130] Decoupling users, clients, and resource leasing provides substantial business advantages to users of the services provided by IDCS. For example, it allows service providers to understand the needs of a business (e.g., a healthcare business) and their identity management issues to purchase services provided by IDCS, develop their own back-end applications that consume the services of IDCS, and provide the back-end applications to the target business. Thus, service providers can extend the services of IDCS to provide their desired capabilities and provide those capabilities to certain target businesses. Service providers do not need to build and run software to provide identity services, but can instead extend and customize the services of IDCS to suit the needs of the target business.

[0131] Some known systems only address a single tenancy, that of a customer. However, such systems are inadequate when handling access by a combination of users, such as a customer user, a customer's partner, a customer's client, the client itself, or a client to whom the customer delegates access. Defining and enforcing multiple tenancies in an embodiment facilitates identity management functionality for these various users.

[0132] In one embodiment, an entity in IDCS does not belong to multiple tenants at the same time; it belongs to only one tenant, and the "lease" is where the artifacts live. In general, there are multiple components that implement certain functions, and these components can belong to tenants, or they can also belong to the infrastructure. When the infrastructure needs to act on behalf of a tenant, it interacts with the entity services on behalf of the tenant. In that case, the infrastructure itself has its own lease, and the customer has its own lease. When submitting a request, multiple leases can be involved in the request.

[0133] For example, a client belonging to "Tenant 1" may perform a request for obtaining a token that lets "Tenant 2" specify 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". Therefore, the user needs to go to the resource namespace of "Tenant 2" and request a token for themselves. Thus, delegation of authorization is accomplished by identifying "who" can do "what" to "who". As yet 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 have access to documents hosted by a third organization ("Tenant 3").

[0134] In one example, a client in "Tenant 1" can request an access token that lets users in "Tenant 2" access an application in "Tenant 3". The client can invoke an OAuth request for a token by going to "http: / / tenant3 / oauth / token". The client identifies itself as a client present in "Tenant 1" by including a "client assertion" in the request. The client assertion includes the client ID (e.g., "client 1") and the client lease "Tenant 1". As "Client 1" in "Tenant 1", the client is authorized to invoke the request for a token on "Tenant 3", and the client wants a token for a user in "Tenant 2". Thus, the "user assertion" is also passed as part of the same HTTP request. The generated access token will be issued in the context of the target lease which is the application lease ("Tenant 3"), and will include the user lease ("Tenant 2").

[0135] In one embodiment, in the data layer, each tenant is implemented as a separate stripe. From a data management perspective, artifacts exist within a tenant. From a service perspective, a service knows how to work with different tenants, and multi-tenancy is a different dimension in the business functionality of a service. Figure 8 An example system 800 that implements multi-tenancy in an embodiment is illustrated. 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, and each tenant includes artifacts for a corresponding lease. In one embodiment, microservice 804 is an OAuth microservice requested through https: / / tenant3 / oauth / token to obtain a token. The function of the OAuth microservice that verifies that the request of client 802 is legitimate is performed in microservice 804 using data from database 806, and if so, a token is constructed using data from a different lease 808. Thus, system 800 is multi-tenant because it can work in a cross-tenant environment by supporting not only services that enter each lease, but also services that act on behalf of different tenants.

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

[0137] In one embodiment, microservice 804 is stateless, meaning that the machine running microservice 804 does not maintain any markings that point the service to any specific tenant. Instead, for example, the lease can be marked on the host portion of the URL of the incoming request. That lease points to one of tenants 808 in database 806. When supporting a large number of tenants (e.g., millions of tenants), microservice 804 cannot have the same number of connections to database 806, but instead uses a connection pool 810, which provides actual physical connections to database 806 in the context of a database user.

[0138] Generally speaking, a connection is constructed by supplying a connection string to the underlying driver or provider, which is used to address a specific database or server and provide instance and user authentication credentials (e.g., "Server=sql_box; Database=Common; User ID=uid; Pwd=Password;"). Once a connection has been established, it can be opened and closed, and properties can be set (e.g., command timeout length, or transaction (if any)). The connection string includes a collection of key-value pairs specified by the data provider's data access interface. 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 a connection pool, after a connection is created, it is placed in a pool and used again so that a new connection does not have to be established. For example, when 10 connections are needed between microservice 804 and database 808, there will be 10 open connections in the connection pool 810, all in the context of a database user (e.g., associated with a specific database user, such as who is the owner of that connection, whose credentials are being verified, is it a database user, is it a system credential, etc.).

[0139] The connections in the connection pool 810 are created for a system user that can access everything. Therefore, in order to properly handle auditing and privileges by the microservice 804 that handles requests on behalf of a tenant, database operations are performed in the context of a "proxy user" 812 associated with a schema owner assigned to a specific tenant. This schema owner can only access the lease for which the schema was created, and the value of the lease is the value of the schema owner. When data in the database 806 is requested, the microservice 804 uses a connection in the connection pool 810 to provide that data. Thus, multi-tenancy is achieved by having a stateless, elastic middle-tier service handle incoming requests in the context of (e.g., associated with) a tenant-specific data store binding, where the tenant-specific data store binding is established on a per-request basis over data connections created in the context of (e.g., associated with) a data store proxy user associated with a resource lease, and the database can be scaled independently of the service.

[0140] The following provides example functionality for implementing proxy user 812:

[0141] dbOperation=<prepare DB command to execute>

[0142] dbConnection=getDBConnectionFromPool()

[0143] dbConnection.setProxyUser(resourceTenant)

[0144] result=dbConnection.executeOperation(dbOperation)

[0145] In this functionality, microservice 804 sets the “Proxy User” setting on the connection pulled from connection pool 810 to “Tenant” and performs database operations in the context of the tenant while using the database connection in connection pool 810.

[0146] When each table is striped to configure different columns in the same database for different tenants, a table can include data for all tenants mixed together. In contrast, one embodiment provides a tenant-driven data layer. This embodiment does not stripe the same database for different tenants, but instead provides a different physical database for each tenant. For example, multi-tenancy can be achieved by using a pluggable database (e.g., Oracle Database 12c from Oracle Corporation), where each tenant is assigned a separate partition. At the data layer, the resource manager processes the request and then requests the data source for the request (separate from the metadata). The embodiment performs a runtime switch to the corresponding data source / storage based on the request. By isolating each tenant's data from other tenants, this embodiment provides improved data security.

[0147] In one embodiment, various tokens encode different leases. A URL token may identify the lease of an application requesting a service. An identity token may encode the identity of a user to be authenticated. An access token may identify multiple leases. For example, an access token may encode the lease that is the target of such access (e.g., an application lease) and the user lease of the user being given access. A client assertion token may identify a client ID and a client lease. A user assertion token may identify a user and a user lease.

[0148] In one embodiment, the identity token includes at least a claim / assertions indicating the user's tenant name (i.e., where the user is located). A "claim" (as used by those of ordinary skill in the security arts) in relation to authorization tokens is a statement that a subject makes about itself or another subject. For example, a claim can be about a name, identity, key, group, privilege, or capability. Claims are issued by providers, and they are given one or more values ​​and then packaged in a security token issued by an issuer, commonly referred to as a security token service ("STS").

[0149] In one embodiment, the access token includes at least a claim / claim indicating the resource tenant name (e.g., client) 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 OAuth client making the request, and a claim indicating the client tenant name. In one embodiment, the access token can be implemented according to the following JSON function:

[0150]

[0151]

[0152] 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 OAuth client making the request.

[0153] The tokens and / or multiple leases described herein can be implemented in any other multi-tenant cloud-based service other than IDCS. For example, the tokens and / or multiple leases described herein can be implemented in SaaS or enterprise resource planning ("ERP") services.

[0154] Fig. 9 is a block diagram of a network view 900 of an IDCS in one embodiment. Fig. 9 The diagram illustrates the network interactions performed between application "zones" 904 in one embodiment. Applications are divided into zones based on the level of protection required and the implementation of connections to various other systems (e.g., SSL zone, no-SSL zone, etc.). Some application zones provide services that need to be accessed from within IDCS, while some application zones provide services that need to be accessed from outside of IDCS, and some application zones are open access. Thus, a corresponding level of protection is enforced for each zone.

[0155] exist Fig. 9 In one embodiment, service-to-service communication is performed using HTTP requests. In one embodiment, IDCS uses the access tokens described herein to not only provide services, but also to protect access to and within IDCS itself. In one embodiment, IDCS microservices are exposed through RESTful interfaces and protected by the tokens described herein.

[0156] exist Fig. 9 In an embodiment of the invention, any of the various applications / services 902 can make HTTP calls to the IDCS API to use the IDCS service. In one embodiment, the HTTP request of the application / service 902 passes through the Oracle public cloud load balancing external virtual IP address ("VIP") 906 (or other similar technologies), the public cloud web routing layer 908, and the IDCS load balancing internal VIP application 910 (or other similar technologies) to be received by the IDCS web routing layer 912. The IDCS web routing layer 912 receives requests from the outside or inside of IDCS and routes them across the IDCS platform service layer 914 or the IDCS infrastructure service layer 916. The IDCS platform service layer 914 includes IDCS microservices called from the outside of IDCS, such as OpenIDConnect, OAuth, SAML, SCIM, etc. The IDCS infrastructure service layer 916 includes microservices that support calls from the inside of IDCS to support the functions of other IDCS microservices. Examples of IDCS infrastructure microservices are UI, SSO, reporting, caching, job scheduler, service manager, functions for making keys, etc. The IDCS cache layer 926 supports cache functionality for the IDCS platform services layer 914 and the IDCS infrastructure services layer 916 .

[0157] By enforcing security both externally accessing IDCS and internally within IDCS, IDCS customers can be provided with outstanding security compliance for the applications they run.

[0158] exist Fig. 9 In an embodiment of the invention, in addition to the data layer 918 based on structured query language ("SQL") communication and the ID storage layer 920 based on LDAP communication, the OAuth protocol is also used to protect the communication between IDCS components (e.g., microservices) within IDCS, and the same token used to protect access from outside IDCS is also used for security within IDCS. That is, the web routing layer 912 uses the same token and protocol to process the request it receives, regardless of whether the request is received from outside IDCS or from inside IDCS. Thus, IDCS provides a single consistent security model for protecting the entire system, thereby allowing excellent security compliance because the fewer security models implemented in the system, the more secure the system is.

[0159] In the IDCS cloud environment, applications communicate by making network calls. Network calls can be based on applicable network protocols, such as HTTP, Transmission Control Protocol ("TCP"), User Datagram Protocol ("UDP"), etc. For example, by exposing application "Y" as an HTTP uniform resource locator ("URL"), application "X" can communicate with application "Y" based on HTTP. In one embodiment, "Y" is an IDCS microservice that exposes multiple resources that each correspond to a capability. When "X" (e.g., another IDCS microservice) needs to call "Y", it constructs a URL (e.g., https: / / host / Y / resource) including "Y" and the resource / capability that needs to be called, and makes a corresponding REST call, which passes through the web routing layer 912 and is directed to "Y".

[0160] In one embodiment, callers outside of IDCS may not need to know where "Y" is, but web routing layer 912 needs to know where application "Y" is running. In one embodiment, IDCS implements a discovery function (implemented by the OAuth service's API) to determine where each application is running, so the availability of static routing information is not required.

[0161] In one embodiment, an enterprise manager ("EM") 922 provides a "single pane of glass" that extends on-premises and cloud-based management to IDCS. In one embodiment, a "Chef" server 924, which is a configuration management tool from Chef Software, provides configuration management capabilities for the various IDCS layers. In one embodiment, the service deployment infrastructure and / or persistent storage module 928 can send OAuth2 HTTP messages to the IDCS web routing layer 912 for tenant lifecycle management operations, public cloud lifecycle management operations, or other operations. In one embodiment, the IDCS infrastructure service layer 916 can send ID / password HTTP messages to the public cloud notification service 930 or the public cloud storage service 932.

[0162] Cloud Access Control – SSO

[0163] One embodiment supports lightweight cloud standards for implementing cloud-scale SSO services. Examples of lightweight cloud standards are HTTP, REST, and any standard that provides access through a browser (because web browsers are lightweight). In contrast, SOAP is an example of a heavyweight cloud standard that requires more management, configuration, and tools to build clients. This embodiment uses OpenID Connect semantics for applications to request user authentication for IDCS. This embodiment uses lightweight HTTP cookie-based user session tracking to track a user's active session at IDCS without the need for stateful server-side session support. This embodiment uses JWT-based identity tokens for applications to use when mapping authenticated identities back to their own local sessions. This embodiment supports integration with a federated identity management system and exposes SAML IDP support for enterprise deployments to request user authentication for IDCS.

[0164] Fig.10 1000 is a block diagram of a system architecture view of the SSO function in IDCS in one embodiment. This embodiment enables client applications to take full advantage of standard-based web protocols to initiate user authentication flows. Applications that need to integrate SSO with cloud systems can be located in enterprise data centers, remote partner data centers, or even operated by customer internal deployments. In one embodiment, different IDCS platform services implement SSO services, such as OpenID Connect, for processing login / logout requests from connected native applications (i.e., applications integrated with IDCS using OpenID Connect); SAML IDP services for processing browser-based login / logout requests from connected applications; SAML SP services for orchestrating user authentication for external SAML IDPs; and internal IDCS SSO services for orchestrating end-user login ceremonies including local or federated login flows and for managing IDCS host session cookies. In general, HTTP can work with or without forms. When it works with forms, the form is seen in the browser. When it works without forms, it acts as a client-to-server communication. Both OpenID Connect and SAML require the ability to present a form, which can be achieved by having a browser present, or by virtually executing an application that acts as a browser. In one embodiment, an application client that implements user authentication / SSO through IDCS needs to register in IDCS as an OAuth2 client, and needs to obtain a client identifier and credentials (e.g., ID / password, ID / certificate, etc.).

[0165] Fig.10 The example embodiment includes three components / microservices that collectively provide login capabilities, including two platform microservices: OAuth2 1004 and SAML2 1006, and one infrastructure microservice: SSO 1008. Fig.10 In an embodiment of the present invention, IDCS provides an "identity meta-system" in which SSO services 1008 are provided on different types of applications, such as browser-based web or native applications 1010 that require three-party OAuth flows and act as OpenID Connect Relay Parties ("RPs", applications that outsource their user authentication functionality to IDPs), native applications 1011 that require two-party OAuth flows and act as OpenID Connect RPs, and web applications 1012 that act as SAML SPs.

[0166] In general, an identity metasystem is an interoperable architecture for digital identities, allowing a collection of digital identities to be employed based on a variety of underlying technologies, implementations, and 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 can be configured to provide a unified security system on top of such applications. The LDAP security model specifies specific mechanisms for handling identities and strictly protects all passes through the system. SAML was developed to allow one set of applications to securely exchange information with another set of applications belonging to different organizations in different security domains. Since there is no trust between the two applications, SAML was developed to allow one application to authenticate another application that does not belong to the same organization. OAuth provides OpenIDConnect, which is a lightweight protocol for performing web-based authentication.

[0167] exist Fig.10 In the embodiment of , when the OpenID application 1010 connects to the OpenID server in IDCS, its "channel" requests the SSO service. Similarly, when the SAML application 1012 connects to the SAML server in IDCS, its "channel" also requests the SSO service. In IDCS, the corresponding microservices (e.g., OpenID microservice 1004 and SAML microservice 1006) will handle each application, and these microservices request SSO capabilities from the SSO microservice 1008. By adding microservices for each protocol and then using the SSO microservice 1008 for SSO capabilities, this architecture can be extended to support any number of other security protocols. The SSO microservice 1008 publishes the session (i.e., provides the SSO cookie 1014) and is the only system in the architecture that has the authority to publish the session. The IDCS session is implemented by the browser 1002 using the SSO cookie 1014. The browser 1002 also uses the local session cookie 1016 to manage its local session.

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

[0169] 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 implements SSO functionality based on customer settings and / or application context, and can be configured based on local forms (i.e., basic Auth), external SAML IDP, external OIDC IDP, etc. The ID / password recovery 1020 is used to recover the user's ID and / or password. When the user logs in for the first time (i.e., when the SSO session does not exist yet), the first login flow 1022 is implemented. The authentication manager 1024 issues an authentication token upon successful authentication. The HTTP cookie manager 1026 saves the authentication token in the SSO cookie. The event manager 1028 publishes events related to the SSO functionality.

[0170] In one embodiment, the interaction between OAuth microservice 1004 and SSO microservice 1008 is based on browser redirection, so that SSO microservice 1008 challenges the user using an HTML form, verifies the credentials, and issues a session cookie.

[0171] In one embodiment, for example, the OAuth microservice 1004 may receive an authorization request from the browser 1002 to authenticate the user of the application according to the three-party OAuth flow. The OAuth microservice 1004 then acts as an OIDC provider 1030, redirects the browser 1002 to the SSO microservice 1008, and passes along the application context. Depending on whether the user has a valid SSO session, the SSO microservice 1008 verifies the existing session or performs a login ceremony. After successful authentication or verification, the SSO microservice 1008 returns the authentication context to the OAuth microservice 1004. The OAuth microservice 1004 then redirects the browser 1002 to the callback URL with an authorization ("AZ") code. The browser 1002 sends the AZ code to the OAuth microservice 1004 to request the required token 1032. The browser 1002 also includes its client credentials (obtained when registering as an OAuth2 client in IDCS) in the HTTP Authorization header. In return, the OAuth microservice 1004 provides the required token 1032 to the browser 1002. In one embodiment, the token 1032 provided to the browser 1002 includes a JW identity and access token signed by the IDCS OAuth2 server. Further details of this functionality are provided below. Fig.11 public.

[0172] In one embodiment, for example, OAuth microservice 1004 may receive an authorization request from native application 1011 to authenticate a user according to a two-party OAuth flow. In this case, authentication manager 1034 in OAuth microservice 1004 performs corresponding authentication (e.g., based on ID / password received from client 1011), and token manager 1036 issues corresponding access tokens after successful authentication.

[0173] In one embodiment, for example, the SAML microservice 1006 can receive an SSO POST request from a browser to authenticate a user of a web application 1012 acting as a SAML SP. The SAML microservice 1006 then acts as a SAML IDP 1038, redirecting the browser 1002 to the SSO microservice 1008 and passing along 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. Upon successful authentication or verification, the SSO microservice 1008 returns the authentication context to the SAML microservice 1006. The SAML microservice then redirects to the SP with the required token.

[0174] In one embodiment, for example, the SAML microservice 1006 can act as a SAML SP 1040 and go to a remote SAML IDP 1042 (e.g., Active Directory Federation Services ("ADFS")). One embodiment implements a standard SAML / AD flow. In one embodiment, the interaction between the SAML microservice 1006 and the SSO microservice 1008 is based on browser redirection, so that the SSO microservice 1008 challenges the user using an HTML form, verifies the credentials, and issues a session cookie.

[0175] In one embodiment, interaction between components within IDCS (eg, 1004 , 1006 , 1008 ) and components outside IDCS (eg, 1002 , 1011 , 1042 ) is performed through firewall 1044 .

[0176] Login / Logout Flow

[0177] Fig.11 1100 is a message sequence flow for the SSO functionality provided by IDCS in one embodiment. When a user uses a browser 1102 to access a client 1106 (e.g., a browser-based application or a mobile / native application), the cloud gate 1104 acts as an application enforcement point and executes the policies defined in the local policy text file. If the cloud gate 1104 detects that the user does not have a local application session, then the user needs to be authenticated. To do so, the cloud gate 1104 redirects the browser 1102 to the OAuth2 microservice 1110 to initiate an OpenID Connect login flow (three-party AZ grant flow with scope="openid profile") to the OAuth2 microservice 1110.

[0178] The request from the browser 1102 traverses the IDCS routing layer web service 1108 and the cloud gate 1104 and reaches the OAuth2 microservice 1110. The OAuth2 microservice 1110 constructs the application context (i.e., metadata describing the application, such as the identity of the connected application, the client ID, the configuration, what the application can do, etc.) and redirects the browser 1102 to the SSO microservice 1112 for login.

[0179] If the user has a valid SSO session, the SSO microservice 1112 validates the existing session without starting a login ceremony. If the user does not have a valid SSO session (i.e., there is no session cookie), the SSO microservice 1112 initiates a user login ceremony based on 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 implemented in JavaScript. The login application service 1114 provides a login page in the browser 1102. The browser 1102 sends a REST POST to the SSO microservice 1112 including the login credentials. The SSO microservice 1112 generates an access token and sends it to the cloud gate 1104 in a REST POST. The cloud gate 1104 sends the authentication information to the management SCIM microservice 1116 to verify the user's password. The management SCIM microservice 1116 determines a successful authentication and sends a corresponding message to the SSO microservice 1112.

[0180] 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 stated on the login page to inform the user about certain profile attributes exposed to the application. During the login ceremony, the SSO microservice 1112 respects the customer's IDP preference and, if configured, redirects to the IDP to authenticate against the configured IDP.

[0181] After successful authentication or verification, 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") containing the user's authentication token. The OAuth2 microservice 1110 returns an AZ code (e.g., an OAuth concept) to the browser 1102 and redirects to the cloud gate 1104. The browser 1102 sends the AZ code to the cloud gate 1104, and the cloud gate 1104 sends a REST POST to the OAuth2 microservice 1110 to request an access token and an identity token. Both tokens are confined to the OAuth microservice 1110 (indicated by the audience token claim). The cloud gate 1104 receives the token from the OAuth2 microservice 1110.

[0182] Cloud Gate 1104 uses the identity token to map the user's authenticated identity to its internal account representation, and it can save this mapping in its own HTTP cookie. Cloud Gate 1104 then redirects the browser 1102 to the client 1106. The browser 1102 then reaches the client 1106 and receives a corresponding response from the client 1106. From this point on, the browser 1102 can seamlessly access the application (i.e., the client 1106) as long as the local cookie of the application is valid. Once the local cookie expires, the authentication process repeats.

[0183] Cloud Gate 1104 also uses the access token received in the request to obtain "userinfo" from the OAuth2 microservice 1110 or the SCIM microservice. The access token is sufficient to access the "userinfo" resource for attributes allowed by the "profile" scope. It is also sufficient to access the " / me" resource via the SCIM microservice. In one embodiment, by default, the received access token is only applicable to user profile attributes allowed under the "profile" scope. Access to other profile attributes is authorized based on additional (optional) scopes submitted in the AZ grant login request issued by Cloud Gate 1104.

[0184] The same process is repeated when the user accesses another OAuth2 integrated connected app.

[0185] 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 already initiated logout on the IDCS side. Cloud Gate 1104 terminates the user session specific to the application and initiates an OAuth2 OpenID Provider ("OP") logout request to OAuth2 microservice 1110. OAuth2 microservice 1110 redirects to SSO microservice 1112, which kills the user's host SSO cookie. SSO microservice 1112 initiates a set of redirects (OAuth2OP and SAML IDP) to known logout endpoints as tracked in the user's SSO cookie.

[0186] In one embodiment, if the cloud gate 1104 uses the SAML protocol to request user authentication (e.g., login), a similar process begins between the SAML microservice and the SSO microservice 1112.

[0187] Cloud Cache

[0188] One embodiment provides a service / capability called Cloud Cache, which is an LDAP front end. Cloud Cache is provided in IDCS to support communication with LDAP-based applications (e.g., email servers, calendar servers, some business applications, etc.) because IDCS does not communicate based on LDAP, and such applications are configured to communicate only based on LDAP. Typically, cloud directories are exposed via REST APIs and do not communicate based on the LDAP protocol. Generally speaking, managing LDAP connections across corporate firewalls requires special configurations that are difficult to establish and manage.

[0189] To support LDAP-based applications, Cloud Cache translates LDAP communications into a protocol suitable for communicating with the cloud system. Generally speaking, LDAP-based applications use the database via LDAP. The application may alternatively be configured to use the database via a different protocol such as SQL. However, LDAP provides a hierarchical representation of resources in a tree structure, while SQL represents data as tables and fields. Thus, LDAP may be more suitable for search functions, while SQL may be more suitable for transaction functions.

[0190] In one embodiment, the services provided by IDCS can be used in LDAP-based applications to, for example, authenticate users of the application (i.e., identity services) or enforce security policies for the application (i.e., security services). In one embodiment, the interface to 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 the communications implement Secure Sockets Layer ("SSL"), and 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 the services provided by IDCS, and the firewall will be open to HTTP.

[0191] In general, an LDAP directory can be used in a range of businesses, such as marketing and development, and defines users, groups, jobs, and the like. In one example, the marketing and development business can have different targeted customers, and for each customer, can have its own applications, users, groups, jobs, and the like. Another example of a range of businesses that can run 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 can be synchronized with the billing system. In these examples, LDAP provides the ability to physically isolate the content being searched at runtime.

[0192] In one example, a wireless service provider may handle its own identity management services for its core business (e.g., regular calls) while using services provided by IDCS to support short-term marketing campaigns. In this case, the cloud cache will "flatten" LDAP when it has a single set of users and a single set of groups that it runs against the cloud. In one embodiment, any number of cloud caches may be implemented in IDCS.

[0193] Distributed Data Grid

[0194] In one embodiment, the cache cluster in IDCS is implemented based on a distributed data grid, as disclosed in, for example, 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 work together in one or more clusters to manage information and related operations (such as calculations) in a distributed or clustered environment. A distributed data grid can be used to manage application objects and data shared across servers. A distributed data grid provides low response time, high throughput, predictable scalability, continuous availability, and information reliability. In a specific example, a distributed data grid (such as Oracle Coherence data grid from Oracle Corporation) stores information in memory to achieve higher performance, and employs redundancy when keeping copies of that information synchronized across multiple servers, thereby ensuring the resilience of the system and the continuous availability of data in the event of a server failure.

[0195] In one embodiment, IDCS implements a distributed data grid such as Coherence, so that each microservice can request access to a shared cache object without being blocked. Coherence is a proprietary Java-based in-memory data grid designed to have better reliability, scalability, and performance than traditional relational database management systems. Coherence provides a peer-to-peer (i.e., no central manager), in-memory distributed cache.

[0196] Fig.12 An example of a distributed data grid 1200 is illustrated that stores data and provides data access to a client 1250 and implements an embodiment 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 and manage information and related operations (such as calculations) in a distributed or clustered environment. Although the distributed data grid 1200 is shown as including four servers 1220a, 1220b, 1220c, 1220d in cluster 1200a, with five data nodes 1230a, 1230b, 1230c, 1230d, and 1230e, the distributed data grid 1200 may include any number of clusters and any number of servers and / or nodes in each cluster. In an embodiment, the distributed data grid 1200 implements the present invention.

[0197] like Fig.12 As shown in, the distributed data grid provides data storage and management capabilities by distributing data on multiple servers (e.g., 1220a, 1220b, 1220c, and 1220d) working together. Each server of the data grid cluster can be a conventional computer system, such as 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 a memory, wherein the memory includes, for example, at least 4GB of RAM, up to 64GB RAM or more. Server 1220a is shown as having a CPU 1222a, a memory 1224a, and a NIC 1226a (these elements also exist in other servers 1220b, 1220c, and 1220d, but not shown). Optionally, each server may also be provided with flash memory (e.g., SSD 1228a) to provide spillover storage capacity. When provided, the SSD capacity is preferably ten times the size of the RAM. The servers (e.g., 1220a, 1220b, 1220c, 1220d) in the data grid cluster 1200a are connected to a high-performance network switch 1220 (e.g., Gigabit Ethernet or better) using a high-bandwidth NIC (e.g., PCI-X or PCIe).

[0198] Cluster 1200a preferably contains a minimum of four physical servers to avoid the possibility of losing data during a failure, but a typical installation has many more servers. The greater the number of servers present in each cluster, the more efficient failover and failback are, and the less impact a server failure has on the cluster. To minimize communication time between servers, each data grid cluster is ideally limited to a single switch 1202 that provides single-hop communication between servers. Therefore, the cluster can be limited by the number of ports on the switch 1202. Therefore, a typical cluster will include 4 to 96 physical servers.

[0199] In most wide area network ("WAN") configurations of distributed data grid 1200, each data center in the WAN has a separate but interconnected data grid cluster (e.g., 1200a, 1200b, and 1200c). The WAN may, for example, include Fig.12 In addition, by using interconnected but independent clusters (e.g., 1200a, 1200b, 1200c) coupled via links 1206 and / or locating interconnected but independent clusters in data centers that are remote from each other, the distributed data grid can protect data and services to clients 1250 from the simultaneous loss of all servers in a cluster due to natural disasters, fires, floods, extended power outages, etc.

[0200] One or more nodes (e.g., 1230a, 1230b, 1230c, 1230d, and 1230e) operate 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, a hypervisor, etc. (not shown) on which the node operates. In an Oracle Coherence data grid, each node is a Java virtual machine ("JVM"). Depending on the CPU processing power and memory available on the server, multiple JVMs / nodes may be provided on each server. JVMs / nodes may be added, started, stopped, and deleted as needed for the distributed data grid. A JVM running Oracle Coherence automatically joins a cluster when it is started. A JVM / node that joins a cluster is referred to as a cluster member or cluster node. Each cluster may also be connected to a standard database 1210 storing accessible data 1212.

[0201] Architecture

[0202] Each client or server includes a bus or other communication mechanism for transmitting information, and a processor coupled to the bus for processing information. The processor can be any type of general or special processor. Each client or server may also include a memory for storing information and instructions to be executed by the processor. The memory may be composed of any combination of random access memory ("RAM"), read-only memory ("ROM"), static memory such as a disk or optical disk, or any other type of computer-readable medium. Each client or server may also include a communication device, such as a network interface card, to provide access to the network. Therefore, a user can interface directly with each client or server, or remotely interface through a network or any other means.

[0203] Computer readable media can be any available media that can be accessed by a processor, and includes volatile and non-volatile 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 transmission mechanism), and includes any information delivery media.

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

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

[0206] The client can access a network service, such as a cloud service. In one embodiment, the web service can be implemented on a webLogic Server from Oracle Corporation. In other embodiments, other implementations of the web service can be used. The web service accesses a database that stores cloud data.

[0207] IAM Functionality Examples

[0208] In one embodiment, the IAM functionality is implemented by software stored in a memory or other computer-readable or tangible medium and executed by a processor.

[0209] A request for performing an identity management service is received. In one embodiment, the request includes a call to an API identifying the identity management service and a microservice configured to perform the identity management service. In one embodiment, a microservice is a self-contained module that can communicate with other modules / microservices, and each microservice has an unnamed common port that can be contacted by other microservices. For example, in one embodiment, various applications / services 602 can make HTTP calls to the IDCS API to use the IDCS microservice 614, such as Figure 6 In one embodiment, a microservice is a runtime component / process.

[0210] 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 lease of the resource associated with the request. For example, in a URL such as "host / microservice / resource" in the web environment of IDCS, the microservice is characterized by having a specific URL prefix, such as "host / oauth / v1", where the actual microservice is "oauth / v1", and there are multiple APIs under "oauth / v1", for example, an API for requesting a token: "host / oauth / v1 / token", an API for authenticating a user: "host / oauth / v1 / authorize", etc. That is, the URL implements the microservice, and the resource portion of the URL implements the API. Accordingly, 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).

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

[0212] Then, access the microservice based on the API, for example, as referenced in this article Figure 6 The access microservices in the IDCS middle layer 614 and the IDCS "API platform" are described. In one embodiment, communication with the microservice is configured through the unnamed universal port of the microservice. In one embodiment, the unnamed universal port of the microservice is a standard communication channel that the 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, the microservice provides one or more capabilities by exposing one or more APIs. In one embodiment, communication with the microservice is achieved only through one or more APIs. That is, the microservice can only be reached / contacted by calling such APIs. In one embodiment, communication with the microservice is configured according to a lightweight protocol. In one embodiment, the lightweight protocol includes HTTP and REST. In one embodiment, the request includes a call to a RESTful HTTP API. Therefore, one embodiment provides a dispatch function. Each HTTP request contains a URI and a verb. The embodiment parses the endpoint (host / service / resource) from the URI and combines it with an HTTP verb (e.g., POST, PUT, PATCH, or Delete) to dispatch (or call) the appropriate method of the appropriate module. This pattern is common to REST and is supported by various packages (e.g., Jersey).

[0213] The identity management service is then performed by the microservice, for example, as referenced in this article Figure 6 The IDCS middle layer 614 in the IDCS "API platform" is described in detail. In one embodiment, the microservices are stateless, horizontally scalable, and independently deployable. In one embodiment, each physical implementation of the microservice is configured to securely support multiple tenants. In one embodiment, the identity management service includes a login service, an SSO service, a federation service, a token service, a directory service, a provisioning service, or an RBAC service.

[0214] On-premises integration

[0215] As above combined Figure 2 As disclosed, an on-premises application 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, generally speaking, clients may be hesitant to allow a third-party cloud service to send commands to the client through the client's firewall. In contrast, in an embodiment, the client first contacts IDCS 202 and requests an action (referred to as a "target action"), rather than receiving an unsolicited action from IDCS 202 through the client's firewall. This functionality is often referred to as "delegated authentication."

[0216] Embodiments address the problem of how to manage client-side on-premises resources from the cloud, given the reality that the client may not "trust" the cloud service and therefore may not open the client's firewall to the cloud service. Embodiments are based on asynchronous responses of the Java API for RESTful Web Services ("JAX-RS"). Asynchronous callbacks are performed because these asynchronous callbacks are used to delegate authentication. For example, if a user logs into IDCS 202, instead of authenticating through a local identity stored in IDCS 202, the user is passed to a server such as Figure 2 An on-premises Active Directory system such as Active Directory (“AD”) 204 of the IDCS 202 may be used. In this pass-through scenario, AD 204 will perform the authentication instead of IDCS 202.

[0217] However, using pass-through for authentication introduces latency from the communication between two different systems, i.e., IDCS 202 and AD 204, as well as latency from the authentication process. For example, the user must go to IDCS 202 and then fall back through the firewall to AD 204. Due to latency, it may take approximately 5-10 seconds to authenticate the user.

[0218] One possible solution to reduce latency is to use HTTP request / response. Specifically, post the login request directly to the bridge / AD 204 and wait for a response. However, this solution will not be optimized to prevent latency because it will use database persistence.

[0219] In contrast, to avoid latency, an embodiment uses a cache listener, such as using Coherence 1200, rather than persistence in a database, to provide notifications to both ends (i.e., IDCS 202 and AD 204). In an embodiment, the cache listener is a feature of the Coherence cache service, which is one of the microservices of IDCS 202. In addition to Coherence, the cache listener can also be implemented by other types of in-memory distributed data grids. Notifications (i.e., request / response) include when authentication needs to be completed and whether authentication has been completed (i.e., authentication success or failure). Therefore, a customer who has stored the username / password of all of the customer's users in AD 204 can use IDCS 202 as a pass-through mechanism to authenticate without having to store a copy of the username / password on IDCS 202.

[0220] In the embodiment, AD bridge 230 (in Figure 2 The disclosed target action framework can be used to take any action on an internally deployed target, but for the authentication delegation function disclosed herein, speed and reduced latency are required.

[0221] In general, AD bridge 230 provides a link between the AD enterprise directory structure and IDCS 202 or any other cloud-based identity service. IDCS 202 can synchronize with the directory structure so that any new, updated, or deleted user or group records are transferred to IDCS 202 if desired. For example, AD bridge 230 can poll AD 204 for any changes to these records and bring these changes into IDCS 202. If a user is deleted in AD 204, then this change or any other type of change will be propagated to IDCS 202. Due to this synchronization, the state of each record is synchronized between AD 204 and IDCS 202. However, as described above, synchronization is not required in some cases because user information can be stored only in AD 204.

[0222] Fig.13 Illustrated is the functionality between IDCS 202 and an on-premises active directory 204 via bridge 230 from the perspective of IDCS 202 when performing delegated authentication according to an embodiment. Fig.14 The functionality between IDCS 202 and the on-premises Active Directory 204 via bridge 230 from the perspective of Active Directory 204 when performing delegated authentication according to an embodiment is illustrated. In general, Fig.13 and Fig.14 The functions shown in are as follows:

[0223] The caller performs an action (such as POST / TargetActions or GET / AsyncTargetActions);

[0224] The caller registers a listener with a specific cache.

[0225] When the expected event has occurred, the listener will interrupt the caller.

[0226] If the expected event did not occur, the caller will perform a DB search via a GET / AsyncTargetAction request for the pending TargetAction (such as authentication, change password for the AD domain managed by the AD bridge polling) to complete the work.

[0227] Regarding which entity is considered the "caller", for POST / TargetActions, the call is initiated / invoked 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 / invoked by the AD bridge 230 to initiate a poll for a TargetAction, such as authentication, change password, update user, etc. (collectively referred to as "authentication actions").

[0228] Fig.13 and Fig.14 The elements shown in include an SSO service 1350 and a management service 1351. The SSO service 1350 and the management service 1351 in the embodiment are implemented by separate IDCS microservices. The management service 1351 includes all the endpoints shown, including a password authenticator 1352, a user 1353, a target action ("TA") 1301, a target action result ("TAR") 1302, and an asynchronous target action ("ATA") 1354. The elements also include a tenant database ("DB") 1355 and a cache 1356, which is a Coherence cache in the embodiment and is implemented as a microservice in IDCS. The cache 1356 includes three different caches that communicate with the management service 1351: a TA cache, a TAR cache, and an ATA cache. On the other side of the "pipeline" between IDCS and the internally deployed elements, the AD bridge 230 and the AD 204 are internally deployed.

[0229] TA is the endpoint that the IDCS client will use to initiate requests to the target, and includes any actions requested on the target. TAR is the result of the request. For delegated authorization, the bridge 230 posts the TAR back to the IDCS server. In general, TA is the request and TAR is the response. Each TA contains the appID (i.e., AD domain ID) of the target application. In an embodiment, each synchronous TA 1301 thread blocks until a responsive TAR 1302 is obtained. In contrast, the asynchronous TA 1354 thread polls (i.e., does not block) until a responsive TAR 1302 is obtained.

[0230] refer to 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 to an end user, perform IDCS administrator work as an administrator, access other applications they are authorized to access, etc.). At 1311, the resulting SSO service thread calls the management service http client POST / UPA (i.e., user password authenticator) and blocks until the management service 1351 returns to get management service thread 1 at 1312. At 1313, UPA calls GET / Users, which obtains a DB connection and calls a DB search via a GET / AsyncTargetAction request (e.g., searches for pending TargetActions, such as authentication, changing passwords for AD domains managed by AD bridge polling) to complete the work. At 1314, the user returns to PA 1352.

[0231] At 1315, PA 1352 calls POST / TargetAction, which creates an "authentication" 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 for callback when the associated TargetActionResult is created / cached, and the post transaction handler sleeps for the configured authorization action timeout (30 seconds in one embodiment) at 1318 until there is a cache callback or timeout. The cache listener registered at 1317 listens for TARs for the appid (application identifier) ​​for which the TA was sent.

[0232] refer to Fig.14 , in response to 1316, at 1410, the bridge 230 previously called GET / AsyncTargetAction for a given appId, so the bridge thread will block until the asynResponse times out or the TargetAction is returned. The bridge thread will poll until either the TargetAction is returned to it for processing or the polling timeout (e.g., 60 seconds) is reached. While polling, the http thread on the IDCS server is released, but the AD bridge thread is blocked. In response, at 1411, the server (i.e., the IDCS management service that services the AsyncTargetAction REST request) GET / AsyncTargetActions and management service threads are created to block until either the asyncResponse timeout (60 seconds) is reached at 1412, or the AsyncTargetAction is called back by the coherence cache listener when an authentication TargetAction is created for the appId managed by the bridge. At 1413, a cache listener is registered to be called when a TargetAction is created for an appld managed by the bridge. When an authentication TargetAction is created for an appld managed by the bridge, the coherence cache listener calls back the AsyncTargetAction.

[0233] At 1415, the management service 1351 searches for and returns an "in progress" authentication TargetAction for the appID to bridge. If one exists, then at 1416, the management service thread bridge is released, and at 1417, an authentication request is sent to AD 204. At 1418, AD 204 processes the request and responds to the bridge 230. At 1419, the bridge 230 calls POST / TargetActionResult to the management service TAR1302. At 1420, TargetActionResult obtains a DB connection, calls DB create to store the TAR, and updates the cache with the TAR at 1422 to indicate that there are TargetActionResults to process.

[0234] Reference again Fig.13 At 1319, when the authentication TargetActionResult is created for the appId managed by the bridge, the coherence cache listener calls back the TargetAction. At 1320, the TargetActionResult matching the authentication TargetActionid is obtained from the cache, the TargetActionResult is added to the TargetAction response, and the TargetAction response is returned to the UPA at 1321.

[0235] At 1325, the UPA returns a response to the SSO service, releasing the management service thread 1, and the SSO service returns a response to the user. The SSO service thread is then released.

[0236] According to an embodiment, the following example pseudo code implements the delegated authentication function:

[0237]

[0238]

[0239]

[0240] In an embodiment, there are two modes (synchronous and asynchronous) for client-initiated target action ("TA") requests:

[0241] Synchronous (POST / TargetActions{"mode":"sync",...});

[0242] Asynchronous (POST / TargetActions{"mode":"async",...}).

[0243] "Synchronous" is used for target actions such as delegated authentication, which are expected to have very short latency and return to the client as soon as possible regardless of success or failure (for example, user login). "Asynchronous" is used for target actions that do not need to respond as quickly as synchronous requests, such as changing an AD user's password, updating AD user profile attributes, etc.

[0244] The embodiment ensures that synchronous TA has priority over asynchronous TA in sending to the bridge, but at the same time, sending asynchronous TA is not blocked by synchronous TA for too long. Asynchronous TA is allowed to take longer to be sent to the bridge, in favor of sending synchronous TA to the bridge first as long as asynchronous TA is sent to the bridge within a reasonable time.

[0245] Thus, at a high level, embodiments handle synchronous target actions separately from asynchronous target actions:

[0246] Synchronous target actions require a "fast path" because the requester is blocking.

[0247] Asynchronous target actions take a slower path, making:

[0248] ο Synchronous target actions can take precedence over asynchronous actions;

[0249] o The target actions can be sorted as needed.

[0250] The following table summarizes the synchronization target action process according to the embodiment. In the following table, each bridge performs long polling and waits for the synchronization TargetAction. The IDCS client posts the synchronization TargetAction and then blocks and waits for the TargetActionResult.

[0251]

[0252] The following table summarizes the asynchronous target action flow according to an embodiment. In the following table, each bridge performs long polling, waiting for an asynchronous TargetAction. The IDCS client posts an asynchronous TargetAction, and then polls to wait for a TargetActionResult.

[0253]

[0254]

[0255]

[0256] As disclosed, embodiments utilize coherence cache callbacks to optimize request / response flows. Embodiments reduce latency when a cloud-based authentication system (e.g., IDCS) interfaces with an on-premises authentication system (e.g., AD) using cache callbacks.

Claims

1. A method for operating a multi-tenant cloud system, the method comprising: receiving a request for an authentication action for a user, the request being received at the multi-tenant cloud system from an on-premises active directory (AD) via a firewall, the request being received by searching a database for a target action to be processed, the request being generated by the on-premises AD via a bridge; In response to the request, creating an authentication target action at the multi-tenant cloud system, the authentication target action including an AD domain identifier of a target application; registering a cache listener at the multi-tenant cloud system to listen for a target action response in response to the authentication target action, the cache listener generating a cache callback when a cache event occurs; Initiate the authentication action for the user at the internally deployed AD via the bridge; Wait for cache callback; as well as Upon cache callback, receiving, at the multi-tenant cloud system via the on-premises AD, a target action response including a result of the authentication action; The authentication target action includes a synchronous target action or an asynchronous target action, the synchronous target action thread blocks until the target action response is received, and the asynchronous target action thread polls until the target action response is received.

2. The method of claim 1, further comprising: While waiting for the cache callback, polling the thread created for the authentication target action; The polling continues until the cache is called back or times out.

3. The method of claim 1, wherein the cache listener is implemented by an in-memory distributed data grid. The method of claim 1 , wherein the authentication action comprises changing a password. The method of claim 4 , wherein the synchronization action comprises a response to a user login.

6. The method of claim 3, wherein the in-memory distributed data grid comprises a Coherence cache.

7. A computer-readable medium storing instructions that, when executed by at least one processor among a plurality of processors, cause the processor to operate a multi-tenant cloud system, the operations comprising: receiving a request for an authentication action for a user, the request being received at the multi-tenant cloud system from an on-premises active directory (AD) via a firewall, the request being received by searching a database for a target action to be processed, the request being generated by the on-premises AD via a bridge; In response to the request, creating an authentication target action at the multi-tenant cloud system, the authentication target action including an AD domain identifier of a target application; registering a cache listener at the multi-tenant cloud system to listen for a target action response in response to the authentication target action, the cache listener generating a cache callback when a cache event occurs; Initiate the authentication action for the user at the internally deployed AD via the bridge; Wait for cache callback; as well as Upon cache callback, receiving, at the multi-tenant cloud system via the on-premises AD, a target action response including a result of the authentication action; The authentication target action includes a synchronous target action or an asynchronous target action, the synchronous target action thread blocks until the target action response is received, and the asynchronous target action thread polls until the target action response is received.

8. The computer readable medium of claim 7, the operations further comprising: While waiting for the cache callback, polling the thread created for the authentication target action; The polling continues until the cache is called back or times out.

9. The computer-readable medium of claim 7, wherein the cache listener is implemented by an in-memory distributed data grid.

10. The computer-readable medium of claim 7, wherein the authentication action comprises changing a password.

11. The computer-readable medium of claim 10, wherein the synchronization action comprises a response to a user login.

12. The computer-readable medium of claim 9, wherein the in-memory distributed data grid comprises a Coherence cache.

13. A multi-tenant cloud system for multiple user accounts, the system comprising: One or more processors in communication with a client system that receives an authentication action for a user, the processors: receiving a request for an authentication action for a user, the request being received at the multi-tenant cloud system from an on-premises active directory (AD) via a firewall, the request being received by searching a database for a target action to be processed, the request being generated by the on-premises AD via a bridge; In response to the request, creating an authentication target action at the multi-tenant cloud system, the authentication target action including an AD domain identifier of a target application; registering a cache listener at the multi-tenant cloud system to listen for a target action response in response to the authentication target action, the cache listener generating a cache callback when a cache event occurs; Initiate the authentication action for the user at the internally deployed AD via the bridge; Wait for cache callback; as well as Upon cache callback, receiving, at the multi-tenant cloud system via the on-premises AD, a target action response including a result of the authentication action; The authentication target action includes a synchronous target action or an asynchronous target action, the synchronous target action thread blocks until the target action response is received, and the asynchronous target action thread polls until the target action response is received.

14. The system of claim 13, further comprising: While waiting for the cache callback, polling the thread created for the authentication target action; The polling continues until the cache is called back or times out.

15. The system of claim 13, wherein the cache listener is implemented by an in-memory distributed data grid.

16. The system of claim 13, wherein the authentication action comprises changing a password.

17. The system of claim 16, wherein the synchronization action comprises a response to a user login.

18. The system of claim 15, wherein the in-memory distributed data grid comprises a Coherence cache.

19. A computer program product for operating a multi-tenant cloud system, comprising instructions, which, when executed by a computer, cause the computer to perform the method according to any one of claims 1 to 6.

Images