JP2022547359A - Multi-tenant identity cloud service with integrated on-premises authentication - Google Patents

Abstract

Embodiments are directed to multi-tenant cloud systems. Embodiments receive a request for an authenticated action for a user and create an authenticated target action. Embodiments register cache listeners to listen for target action responses in response to authentication target actions and initiate authentication actions for users via a bridge with an on-premises active directory (“AD”). Embodiments wait for a cache callback and receive a target action response containing the result of the authentication action in the cache callback.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to US Provisional Patent Application No. 62/899,888, filed September 13, 2019, the disclosure of which is incorporated herein by reference.

FIELD An embodiment relates generally to identity management, and more particularly to identity management in cloud systems.

Background Information Cloud-based applications (e.g., corporate public cloud applications, third-party cloud applications) are growing exponentially. Due to the great diversity and accessibility of cloud-based applications, identity management and access security have become central concerns. Typical security issues in cloud environments are unauthorized access, account hijacking, malicious insiders, etc. Therefore, there is a need for secure access to applications, whether cloud-based or wherever they reside, regardless of the type of device or type of user accessing the application.

Overview Embodiments are directed to multi-tenant cloud systems. Embodiments receive a request for an authenticated action for a user and create an authenticated target action. Embodiments register cache listeners to listen for target action responses in response to authentication target actions and initiate authentication actions for users via a bridge with an on-premises active directory (“AD”). Embodiments wait for a cache callback and receive a target action response containing the result of the authentication action in the cache callback.

1 is a block diagram of an example embodiment that provides cloud-based identity management; FIG. 1 is a block diagram of an example embodiment that provides cloud-based identity management; FIG. 1 is a block diagram of an example embodiment that provides cloud-based identity management; FIG. 1 is a block diagram of an example embodiment that provides cloud-based identity management; FIG. 1 is a block diagram of an example embodiment that provides cloud-based identity management; FIG. 1 is a block diagram that provides a system view of an embodiment; FIG. FIG. 3 is a block diagram providing a functional view of an embodiment; FIG. 4 is a block diagram of an embodiment implementing CloudGate. 1 illustrates an example system that implements multiple tenancies in one embodiment; FIG. FIG. 4 is a block diagram of a network view of an embodiment; 1 is a block diagram of a system architecture view of single sign-on (“SSO”) functionality in one embodiment; FIG. FIG. 2 is a diagram of a message sequence flow for SSO functionality in one embodiment. 1 illustrates an example of a distributed data grid in one embodiment; FIG. FIG. 2 illustrates the functionality between an Identity Cloud Service (“IDCS”) over a bridge and an on-premises active directory from the IDCS perspective when performing delegated authentication, according to an embodiment. FIG. 4 illustrates the functionality between IDCS and an on-premise Active Directory over a bridge when performing delegated authentication from an Active Directory perspective, according to an embodiment.

DETAILED DESCRIPTION Embodiments provide an identity cloud service that enables a microservices-based architecture while providing multi-tenant identity and data security management and secure access to cloud-based applications. Embodiments optimize the request/response flow between cloud-based authentication services and on-premises authentication systems by promoting in-memory data grid cache callbacks. Embodiments reduce latency when a cloud-based authentication system (eg, IDCS) interfaces with an on-premises authentication system using cache callbacks.

Embodiments support secure access for hybrid cloud deployments (ie, cloud deployments that include a combination of public and private clouds). Embodiments protect applications and data both in the cloud and on-premises. Embodiments support multi-channel access via the web, mobile devices, and application programming interfaces (“APIs”). Embodiments manage access for various users, such as customers, partners, and employees. Embodiments manage, control, and audit both access through the cloud and on-premises access. Embodiments integrate with new and existing applications and identities. Embodiments are horizontally scalable.

One embodiment is a system that provides cloud-based multi-tenant identity and access management services by implementing a number of microservices in a stateless middle-tier environment. In one embodiment, each identity management service requested is divided into real-time and near-real-time tasks. Real-time tasks are handled by middle-tier microservices, while near-real-time tasks are offloaded to message queues. Embodiments enhance the security model for accessing microservices by implementing access tokens that are consumed by the routing and middle layers. Accordingly, embodiments provide a cloud-scale Identity and Access Management (“IAM”) platform based on a multi-tenant, microservices architecture.

One embodiment provides an identity cloud service that enables organizations to rapidly develop fast, reliable, and secure services for their new business initiatives. In one embodiment, the identity cloud service provides a number of core services. Each core service solves a unique challenge faced by many enterprises. In one embodiment, the identity cloud service, for example, initially onboards/imports a user, imports a group with user members, creates/updates/disables/enables/deletes a user, etc. Assist administrators when assigning/unassigning users to groups, creating/updating/deleting groups, resetting passwords, managing policies, sending activations, etc.

A unified access security embodiment protects applications and data in both cloud and on-premises environments. This embodiment secures access to any application by anyone from any device. The present embodiment provides protection across both of these environments. This is because inconsistencies in security between these two environments can increase risk. For example, in the event of such a conflict, a salesperson would have access to their Customer Relationship Management (“CRM”) account even after defecting and moving to a competitor. may continue to do so. Accordingly, embodiments extend security controls provisioned in on-premises environments to cloud environments. For example, if a person leaves a company, embodiments ensure that their account is disabled both on-premises and in the cloud.

Generally, users may access applications and/or data through a wide variety of channels such as web browsers, desktops, mobile phones, tablets, smartwatches, and other wearable devices. Therefore, one embodiment secures access through all these channels. For example, a user can use their mobile phone to complete a transaction initiated on their desktop.

An embodiment further manages access for various users, such as customers, partners, and employees. Generally, applications and/or data may be accessed not only by employees, but also by customers or third parties. Many known systems have safeguards in place when onboarding employees, but these safeguards are usually not at the same level of security when granting access to customers, third parties, partners, etc. , as a result, security can be breached by those who are not properly managed. However, embodiments ensure that adequate security measures are provided for access for each type of user, not just employees.

The Identity Cloud Service embodiment provides the Identity Cloud Service (“IDCS”), which is 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 may also manage access to public cloud services. For example, IDCS can be used to provide Single Sign On (“SSO”) functionality across such diverse services/applications/systems.

Embodiments are based on a multi-tenant microservices architecture for designing, building, and delivering cloud-scale software services. Multi-tenancy means that there is a physical realization of a service that securely supports multiple customers who have purchased the service. A service is a software function or set of software functions that can be reused by different clients for different purposes (such as retrieving specified information or performing a set of actions) (e.g., requesting a service). (based on the client's identity) and the policy governing its use. In one embodiment, a service is a mechanism that allows access to one or more functions, provided using a predetermined interface, and performed according to the constraints and policies specified by the service description. be.

In one embodiment, microservices are independently deployable services. In one embodiment, the term microservices is intended for a software architectural design pattern in which complex applications are composed of small independent processes that communicate with each other using language-independent APIs. In one embodiment, microservices are small, finely-separated services, each of which may focus on performing a small task. In one embodiment, the microservices architectural style is an approach to developing a single application as a set of small services, each running in its own process and using lightweight mechanisms such as the Hypertext Transfer Protocol (Hypertext Transfer Protocol). Transfer Protocol) (“HTTP”) resource API). In one embodiment, microservices are easier to replace as compared to monolithic services that perform all or many of the same functions. Additionally, each microservice can be updated without adversely affecting other microservices. In contrast, updating one part of a monolithic service can have undesirable or unintended adverse effects on other parts of the monolithic service. In one embodiment, microservices may be beneficially organized around their functionality. In one embodiment, the startup time of each microservice in a collection of microservices is much less than the startup time of a single application that collectively runs all of these microservices. In some embodiments, each such microservice has a startup time of about 1 second or less, whereas a single such application has a startup time of about a minute, several minutes, or longer. Sometimes.

In one embodiment, a microservices architecture is a specialization of a service oriented architecture (“SOA”) to build flexible, independently deployable software systems (i.e. tasks within a system). separation) and implementation techniques. Services in a microservices architecture are processes that communicate with each other through a network to accomplish a purpose. In one embodiment, these services use technology-agnostic protocols. In one embodiment, the service uses a low-granularity, lightweight protocol. In one embodiment, the services are independently deployable. By distributing the functionality of the system to different smaller services, the cohesion of the system is improved and the coupling of the system is reduced. This makes it easy 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 constant refactoring, thus reducing the need for extensive up-front design and enabling early software releases. become.

In one embodiment, in a microservices architecture, an application is developed as a collection of services, each running its own process and communicating using lightweight protocols (eg, a unique API per microservice). In a microservices architecture, decomposing a piece of software into individual services/functions can be done 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 anonymous universal port that can be contacted by others. In one embodiment, a microservice's anonymous universal port is a standard communication channel that a microservice traditionally exposes (eg, as a traditional HTTP port) to which other modules/microservices within the same service can talk. It is a standard communication channel that allows Microservices or other built-in functional modules can be collectively referred to as "services."

Embodiments provide multi-tenant identity management services. Embodiments are based on open standards that ensure easy integration with various applications and provide IAM functionality through standards-based services.

Embodiments manage the lifecycle of user identities, which involves determining and enforcing what an identity can access, who can grant such access, who can manage such access, and so on. Embodiments run identity management workloads in the cloud and support security functions for applications that may or may not reside in this cloud. The identity management services provided by these embodiments may be purchased from the cloud. For example, a company may purchase such a service from the cloud to manage its employees' access to the company's applications.

Embodiments provide system security, massive scalability, end-user usability, and application interoperability. Embodiments address the growth of the cloud and the use of identity services by customers. A microservices-based foundation deals with lateral scalability requirements, whereas service fine-tuning deals with functional requirements. Achieving both of these goals involves decomposing business logic (as much as possible) so that, while ultimately achieving consistent statelessness, most of the behavioral logic that is not subject to real-time processing is distributed and processing is offloaded to a highly scalable asynchronous event management system with guaranteed processing to shift to near real-time. Embodiments are fully multi-tenant from the web tier to the data for cost efficiency and ease of system management.

Embodiments incorporate industry standards (e.g., OpenID Connect, OAuth2, Security Assertion Markup Language 2 (“SAML2”), cross-domain identity management, etc., to facilitate integration with various applications). System for Cross-domain Identity Management (“SCIM”), Representational State Transfer (“REST”), etc.). One embodiment provides a cloud-scale API platform to enable laterally scalable microservices for elastic scalability. The present embodiment enhances cloud principles and provides a multi-tenant architecture with data segregation for each tenant. The embodiment further provides per-tenant customization via tenant self-service. This embodiment is available via an API for on-demand integration with other identity services and provides continuous feature releases.

One embodiment provides interoperability and enhances investments in identity management (“IDM”) capabilities in the cloud and on-premises. The present embodiments provide automated identity synchronization from on-premises Lightweight Directory Access Protocol (“LDAP”) data to cloud data and vice versa. The present embodiments provide a SCIM identity bus between the cloud and the enterprise, enabling various options for hybrid cloud deployments (eg, identity federation and/or synchronization, SSO agents, user provisioning connectors, etc.).

Accordingly, one embodiment is a system that provides cloud-based multi-tenant identity and access management services by implementing multiple microservices in a stateless middle tier. In one embodiment, each identity management service requested is divided into real-time and near-real-time tasks. Real-time tasks are handled by middle-tier microservices, while near-real-time tasks are offloaded to message queues. Embodiments implement tokens that are consumed by the routing layer to implement a security model for accessing microservices. Accordingly, embodiments provide a cloud-scale IAM platform based on a multi-tenant, microservices architecture.

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

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

Integration Tools It is common for large enterprises to have IAM systems in place for secure access to their on-premises applications. Business practices are usually matured and standardized around in-house IAM systems such as Oracle's "Oracle IAM Suite". Even small to medium sized organizations typically have their business processes designed around managing user access through a simple directory solution such as Microsoft Active Directory (“AD”). To enable on-premises integration, embodiments provide tools that allow customers to integrate their applications with IDCS.

FIG. 2 is a block diagram 200 of an example embodiment using IDCS 202 in cloud environment 208 to provide integration with on-premises 206 AD 204 . This embodiment includes various applications/services in cloud 208 such as, for example, cloud services 210, cloud applications 212, partner applications 214, and customer applications 216, as well as on-premises applications and third-party applications such as on-premises application 218. provide a seamless user experience across multiple applications. Cloud applications 212 include, for example, Human Capital Management (“HCM”), CRM, Talent Acquisition (eg, Oracle Taleo cloud services 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.

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

Generally, an identity bus is a service bus for identity related services. A service bus provides a platform for passing messages from one system to another. It is a controlled mechanism for exchanging information between trusted systems, for example in a service oriented architecture ("SOA"). An identity bus is a logical bus built according to standard HTTP-based mechanisms such as web services, web server proxies. Communication on the identity bus may be performed according to respective protocols (eg SCIM, SAML, OpenID Connect, etc.). For example, a SAML bus is an HTTP-based connection between two systems for conveying messages about SAML services. Similarly, the SCIM bus is used to convey SCIM messages according to the SCIM protocol.

The embodiment of FIG. 2 implements a small binary (eg, 1 MB in size) identity (“ID”) bridge 230 that can be downloaded and installed on-premise 206 with the customer's AD 204 . Identity bridge 230 listens for users and groups (eg, groups of users) in organizational units (“OUs”) selected by the customer and synchronizes these users to cloud 208 . In one embodiment, user's password 232 is not synchronized to cloud 208 . Customers can manage user application access by mapping groups of IDCS users to cloud applications managed in IDCS 208 . Whenever a user's group membership is changed on-premises 206, the corresponding cloud application access is automatically changed.

For example, an employee who moves from the technical department to the sales department can gain access to the sales cloud almost instantly and lose access to the developer cloud. When this change is reflected in the on-premises AD 204, cloud application access changes are realized in near real time. Similarly, access to cloud applications managed by IDCS 208 is revoked for users leaving the enterprise. For full automation, the customer sets up SSO between on-premises AD 204 and IDCS 208, for example through an AD federation service (“AD/FS” or some other mechanism that enables SAML federation), so that end users can A single corporate password 332 may be used to allow access to cloud applications 210 , 212 , 214 , 216 and on-premise applications 218 .

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

In the embodiment of FIG. 3 , Oracle's Oracle Identity Manager (“OIM”) connector 302 and Oracle's Oracle Access Manager (“OAM”) federation module 306 are connected to Oracle IDM 304 . Implemented as an extension module. A connector is a module that has physical awareness of how to talk to the system. OIM is an application configured to manage user identities (eg, manage user accounts in different systems based on what a user should or 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 and auditing. OAM has built-in support for SAML. If a user has an account in IDCS 202, OIM Connector 302 and OAM Federation 306 can be used with Oracle IDM 304 to create/delete this account and manage access from this account.

FIG. 4 is a block diagram 400 of an example embodiment including the same components 202, 206, 208, 210, 212, 214, 216, 218, 220, 222, 224, 226, 234 as in FIGS. . However, in the FIG. 4 embodiment, IDCS 202 provides functionality for extending 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. In the FIG. 4 embodiment, SCIM identity bus 234 is used to synchronize data in IDCS 202 with on-premises LDAP data called “cloud cache” 402 . Cloud cache 402 is disclosed in greater detail below.

Applications configured to communicate based on LDAP generally require an LDAP connection. Such an application may not establish an LDAP connection using a URL (unlike "www.google.com", which connects to Google® for example). This is because LDAP must be on the local network. In the FIG. 4 embodiment, LDAP-based application 218 connects to cloud cache 402 , which connects to IDCS 202 before retrieving the requested data from IDCS 202 . Communication between IDCS 202 and cloud cache 402 may be implemented according to the SCIM protocol. For example, cloud cache 402 may use SCIM bus 234 to send SCIM requests to IDCS 202 and receive corresponding data.

In general, a full realization of an application consists of building a consumer portal, running marketing campaigns to external user populations, supporting web and mobile channels, user authentication, sessions, user and handling profiles, user groups, application roles, password policies, self-service/registration, social integration, identity federation, and the like. Application developers are generally not identity/security experts. This is why on-demand identity management services are desirable.

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

In this embodiment, SCIM identity bus 234 is used to synchronize data in IDCS 202 with data in on-premises LDAP cloud cache 402 . In addition, application 505 may use “Cloud Gate” 502 running on a web server/proxy (eg, NGINX, Apache, etc.) to obtain user web SSO and REST API security from IDCS 202 . Cloud Gate 502 secures access to multi-tenant IDCS microservices by ensuring that client applications provide valid access tokens and/or users successfully authenticate for SSO session establishment. It is a component that works. CloudGate 502 is further disclosed below. Cloud Gate 502 (an enforcement point similar to webgate/webagent) allows applications running behind supported web servers to participate in SSO.

One embodiment provides SSO and cloud SSO functionality. In many organizations, a common entry point for both on-premises IAM and IDCS is SSO. Cloud SSO allows users to access multiple cloud resources with a single user sign-in. Organizations often want to federate their on-premises identities. Thus, embodiments enable investment savings and expansion by leveraging open standards to provide integration with existing SSO (e.g., up to eventual full migration to identity cloud service approach). ).

One embodiment may provide the following functionality.
• Track already authorized user accounts, ownership, access, and permissions by maintaining an identity store.
• Integration with workflow simplifies the various approvals required for application access (eg, administration, IT, human resources, legal, and compliance).
• Provision SaaS user accounts for selective devices (eg, mobiles and personal computers (“PCs”)). Access to user portals includes numerous private and public cloud resources.
• Facilitates periodic control verification for compliance with regulations and current responsibilities.

In addition to these features, embodiments further:
provisioning of cloud accounts for account lifecycle management in cloud applications;
integration of more robust multifactor authentication (“MFA”);
• Enhanced mobile security features, and • Dynamic authentication options may be provided.

One embodiment provides adaptive authentication and MFA. Generally, passwords and challenge questions have been viewed as inadequate and susceptible to common attacks such as phishing. Most modern business entities look to some form of MFA to reduce risk. However, in order for a solution to be successfully deployed, it needs to be easily provisioned, maintained, and understood by end users. This is because end-users typically resist anything that interferes with their digital experience. Enterprises can secure bring your own device (“BYOD”), social identity, remote users, customers, and contractors while making MFA a nearly transparent component of a seamless user access experience. Looking for a way to incorporate. In deploying MFA, industry standards such as OAuth and OpenID Connect are essential to ensure the integration of existing multi-factor solutions and the introduction of newer adaptive authentication technologies. Embodiments therefore define dynamic (or adaptive) authentication as the evaluation of available information (ie, IP address, location, time of day, and biometrics) to prove identity after a user session begins. Using suitable standards (e.g., open authentication (“OATH”) and fast identity online (“FIDO”) integration and extensible identity management frameworks, embodiments can: Provides an MFA solution that can be easily adopted, upgraded, and integrated within an IT organization as part of an end-to-end secure IAM deployment.When considering MFA and adaptive policies, organizations can consider hybrid IDCS and on-premise Consistent policies must be achieved across on-premises and cloud resources that require integration between systems in an IAM environment.

One embodiment provides user provisioning and certification. In general, the basic function of IAM solutions is to enable and support the entire user provisioning lifecycle. This means giving users application access appropriate to their identity and role within the organization (e.g., the user's role or the tasks or applications used within that role may change over time). change) and rapid user deprovisioning necessary when a user leaves the organization. This is important not only for meeting various compliance requirements, but because inappropriate insider access is a leading cause of security breaches and attacks. Automated user provisioning capabilities in an identity cloud solution can be important not only in its own right, but also as part of a hybrid IAM solution, thus IDCS provisioning can be useful as enterprises shrink, grow, and grow. When looking to merge or integrate existing systems with an IaaS/PaaS/SaaS environment, it may offer more flexibility than an on-premises solution when migrating. The IDCS approach can save time and effort in one-off upgrades and ensures proper integration of necessary departments, business units and systems. Enterprises often have a hidden need to scale this technology, and the rapid provision of scalable IDCS capabilities across enterprise architectures can provide benefits in terms of flexibility, cost, and control.

Typically, employees are granted additional privileges (ie, "privilege creep") as their job title changes over time. Loosely regulated companies typically lack a “verification” process. This process regularly audits the privileges of corporate employees (e.g. access rights to networks, servers, applications, and data) to prevent privilege creep resulting in over-privileged accounts. Requires an administrator to stop or slow down. Accordingly, one embodiment may provide for an attestation process that is performed periodically (at least once a year). Moreover, with mergers and acquisitions, the need for these tools and services increases exponentially. This is because users reside in SaaS systems, reside on-premises, span different departments, and/or have been deprovisioned or reassigned. A move to the cloud could further disrupt this situation, and things could escalate rapidly beyond existing, often manually managed attestation methods. Accordingly, one embodiment automates these functions and applies advanced analytics to user profiles, access history, provisioning/deprovisioning, and fine-grained entitlements.

One embodiment provides identity analysis. In general, the ability to integrate identity analysis with IAM engines for comprehensive attestation and validation can be essential to secure an organization's risk profile. Properly deployed identity analytics can require the enforcement of entire internal policies. Providing a unified, single management view across cloud and on-premises, identity analytics are highly needed and risk-agnostic in preventive governance, risk, and compliance (“GRC”) enterprise environments. It can help provide a closed loop process for reducing and meeting compliance regulations. Accordingly, one embodiment provides identity analysis. Identity Analytics is easily customized by clients to meet specific industry requirements and government regulations for the reports and analysis required by managers, executives, and auditors.

One embodiment provides self-service and access request capabilities to improve end-user experience and efficiency while reducing the cost of helpdesk calls. While many companies typically deploy on-premises self-service access requests for their employees, many do not adequately extend these systems outside the formal corporate walls. Outside of employee usage, positive digital customer experiences contribute to increased business credibility and ultimately increased revenue, and companies can not only reduce customer helpdesk calls but also increase customer satisfaction. Increase. Accordingly, 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 as needed. The SaaS delivery model eliminates time and effort previously spent on system upgrades and maintenance, freeing IT professionals to focus on more core business applications.

One embodiment provides privileged account management (“PAM”). In general, all organizations, whether using SaaS, PaaS, IaaS or on-premises applications, allow insiders with superuser access credentials such as system administrators, executives, HR executives, contractors, system integrators, etc. Vulnerable to unauthorized use of privileged accounts by In addition, external threats generally first compromise low-level user accounts and eventually reach and exploit privileged user access controls within enterprise systems. Accordingly, one embodiment prevents the use of accounts by such unauthorized insiders by providing PAM. A key component of the PAM solution is the password vault, which can be supplied in various ways. For example, it can be provided in various ways, as software installed on an enterprise server, also as a virtual appliance on the enterprise server, as a packaged hardware/software appliance, or as part of a cloud service. The PAM function is similar to the physical safehouse used to store passwords that are kept within an envelope and changed periodically in manifests for sign-ins and sign-outs. One embodiment allows password checkout as well as setting time limits, forced duration changes, automatic checkout tracking, and reporting on all activity. One embodiment provides a way to connect directly to the requested resource without the user knowing the password. This feature also paves the way for session management and other functions.

Generally, most cloud services utilize APIs and management interfaces. These provide opportunities for intruders to circumvent security. Accordingly, one embodiment bridges these deficiencies in PAM implementations. This is because migration to the cloud will create new challenges for PAM. While many small to medium-sized businesses currently manage their own SaaS systems (e.g. Office 365), larger enterprises increasingly have individual business units that turn their own SaaS and IaaS services. ing. These customers may have PAM functionality included in their identity cloud service solution or obtained from their IaaS/PaaS provider, but have little experience dealing with this responsibility. Additionally, in some cases, many different geographically dispersed business units seek to separate management responsibilities for the same SaaS application. Therefore, one embodiment is for customers in these situations to link their existing PAMs into the overall identity framework of their identity cloud service, for greater security and compliance as their business needs demand. to ensure that it is adjusted to the prevailing cloud load conditions.

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

Generally, in the IDCS web environment, a URL includes three parts: host, microservice, and resource (eg, host/microservice/resource). In one embodiment, the microservice is characterized by having a specific URL prefix (eg, "host/oauth/v1") and the actual microservice is "oauth/v1". There are multiple APIs under 'oauth/v1', for example, an API to request a token: 'host/oauth/v1/token', an API to authorize a user: ' host/oauth/v1/authorize”. That is, the URL implements the microservice and the resource portion of the URL implements the API. Therefore, multiple APIs are aggregated under the same microservice. In one embodiment, the host portion of the URL identifies the tenant (eg https://tenant3.identity.oraclecloud.com:/oauth/v1/token).

Configuring an application that integrates with external services with the required endpoints and keeping that configuration up to date is typically a challenge. To overcome this challenge, embodiments expose a public discovery API to a well-known location from which applications can discover information about IDCS needed to consume the ADCS API. can. In one embodiment, two discovery documents are supported, which include IDCS configurations (e.g. IDCS, SAML, SCIM, OAuth, and OpenID Connect configurations in <IDCS-URL>/.well-known/idcs-configuration ) and the industry standard OpenID Connect configuration (eg, <IDCS-URL>/.well-known/openid-configuration). Applications can retrieve discovery documents by configuring with a single IDCS URL.

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

In one embodiment, HTTP requests of applications/services 602 requesting IDCS services are routed through Oracle Public Cloud BIG-IP Appliance 604 and IDCS BIG-IP Appliance 606 (or similar technology such as load balancers, or appropriate security rules). to protect the traffic through a component called Cloud Load Balancer as a Service (“LBaaS”). However, this request may be received in any manner. In the IDCS BIG-IP appliance 606 (or load balancer or similar technology such as cloud LBaaS where applicable), the cloud provisioning engine 608 performs tenant and service coordination. In one embodiment, the cloud provisioning engine 608 manages internal security artifacts associated with new tenants being onboarded to the cloud or new service instances purchased by customers.

This HTTP request is then received by the IDCS web routing layer 610 . This routing layer implements Security Gate (ie Cloud Gate) and provides service routing and microservice registration and discovery 612 . Depending on the service requested, the HTTP request is forwarded to the IDCS microservice of IDCS middle tier 614 . The IDCS microservice handles external and internal HTTP requests. IDCS microservices implement platform and infrastructure services. The IDCS Platform Services are separately deployed Java-based runtime services that enable the business of IDCS. IDCS infrastructure services are separately deployed runtime services that provide infrastructure support for IDCS. IDCS further includes infrastructure libraries, which are common code packaged as shared libraries used by IDCS services, and shared libraries. Infrastructure services and libraries provide the support functions required by platform services to achieve their functionality.

In one embodiment of Platform Services , IDCS supports standard authentication protocols, thus IDCS microservices support OpenID Connect, OAuth, SAML2, System for Cross-domain Identity Management++ (“SCIM++”). ) and other platform services.

The OpenID Connect platform service implements standard OpenID Connect login/logout flows. Interactive web-based and native applications require user authentication by following standard browser-based OpenID Connect flows, and JavaScript Object Notation to convey the user's authenticated identity. ("JSON") Web Token ("JWT") Internally, the runtime authentication model is stateless and stores the user's authentication/session state in a hosted HTTP cookie (including the JWT identity token). ).Authentication interactions initiated via the OpenID Connect protocol are delegated to a trusted SSO service that facilitates user login/logout ceremonies for local and federated logins.Further details on this feature are disclosed below with reference to Figures 10 and 11. In one embodiment, the OpenID Connect functionality is implemented, for example, in accordance with the OpenID Foundation standards.

OAuth2 platform services provide token authorization services. It provides a rich API infrastructure for creating and validating access tokens that convey user rights and making API calls. It supports a range of useful token grant types and allows customers to securely connect their clients to their services. This implements standard two-way and three-way OAuth2 token grant types. Support for OpenID Connect (“OIDC”) allows compliant applications (OIDC Relay Parties (“RP”)) to integrate with IDCS as an identity provider (OIDC OpenID Provider (“OP ).Similarly, by integrating IDCS as an OIDC RP with social OIDC OPs (e.g. Facebook, Google, etc.), customers can enable social identity policy-based access to applications. In one embodiment, the OAuth functionality is implemented in accordance with Internet Engineering Task Force (“IETF”), Request for Comments (“RFC”) 6749, for example.

The SAML2 platform service provides identity federation services. This allows customers to set up federation agreements with their partners based on the SAML identity provider (“IDP”) and SAML service provider (“SP”) relationship model. do. In one embodiment, the SAML2 platform service implements standard SAML2 browser post-login and logout profiles. In one embodiment, the SAML functionality is implemented according to IETF, RFC7522, for example.

SCIM is an open standard for automating the exchange of user identity information between identity domains or information technology (“IT”) systems provided by, for example, IETF, RFCs 7642, 7643, 7644. . SCIM++ platform services provide identity management services and allow customers to access the IDP features of IDCS. The management service exposes a set of stateless REST interfaces (or APIs) covering identity lifecycle, password management, group management, etc., and exposes artifacts such as web-accessible resources.

All IDCS configuration artifacts are resources, and the Management Service API allows management of IDCS resources (e.g. users, roles, password policies, applications, SAML/OIDC identity providers, SAML service providers, keys, certificates, notification templates, etc.). to enable. The Management Service provides Create, Read, Update, Delete, and Query ("CRUDQ") operations for all IDCS resources by enhancing and extending the SCIM standard. Implement a schema-based REST API for In addition, all internal resources of IDCS used to manage and configure IDCS itself are exposed as SCIM-based REST APIs. Access to the identity store 618 is isolated to the SCIM++ API.

In one embodiment, for example, the SCIM standard is implemented to manage user and group resources defined by the SCIM standard, while SCIM++ uses the language defined by the SCIM standard to implement yet another IDCS implementation. Configured to support internal resources (e.g. password policies, roles, settings, etc.).

The Management Service supports SCIM 2.0 standard endpoints using the standard SCIM 2.0 core schema and schema extensions as needed. In addition, the management service manages other IDC resources such as users, groups, applications, settings, etc. by supporting several SCIM 2.0 compliant endpoint extensions. The management service also has a remote procedure call-style ("RPC-style") REST interface that does not perform CRUDQ operations but instead provides functional services, e.g., "UserPasswordGenerator", "UserPasswordValidator", etc. supports a set of

The IDCS administration API uses the OAuth2 protocol for authentication and authorization. IDCS supports common OAuth2 scenarios such as those for web server, mobile, and JavaScript applications. Access to the IDCS API is protected by access tokens. In order to access the IDCS administration API, an application must be registered as an OAuth2 client through the IDCS administration console or as an IDCS application (in which case the OAuth2 client is automatically created), and must be assigned the desired IDCS administration role. must be given. When making IDCS administration API calls, an application first requests an access token from the IDCS OAuth2 service. After obtaining this token, this application sends the access token with the HTTP Authorization header included in it. Applications can use the IDCS administration REST API directly, or they can use the IDCS Java client API library.

Infrastructure Services IDCS Infrastructure Services support the functionality of the IDCS Platform Services. These runtime services are event processing services (to asynchronously handle user notifications, application submissions, and audits to databases) and event processing services (to schedule and run jobs, e.g. a job scheduler service (to run timed tasks immediately or at set times), a cache management service (to integrate with public cloud storage services), and a storage management service (to generate reports and dashboards). SSO service (for managing internal user authentication and SSO), and user interface (“UI”) (for hosting different kinds of user interface (“UI”) clients) ”) services and service manager services. Service Manager is the internal interface between Oracle Public Cloud and IDCS. The Service Manager manages commands issued by the Oracle Public Cloud, which need to be implemented by IDCS. For example, if a customer signs up for an account in the cloud store before being ready to purchase anything, the cloud sends a request to IDCS to create a tenant. In this case, the service manager implements the cloud-specific behaviors that the cloud expects IDCS to support.

An IDCS microservice may call another IDCS microservice through a network interface (ie, an HTTP request).

In one embodiment, IDCS may also provide a schema service (or persistence service) that allows database schemas to be used. The Schema Service allows delegation of responsibility for managing database schemas to IDCS. Therefore, IDCS users do not need to manage databases. This is because there is an IDCS service that provides this functionality. For example, a user may use a database to persist a schema per tenant, and when the database runs out of space, the schema service will create a separate database so that the user does not have to manage the database themselves. and manages the function of expanding the above space.

IDCS further includes a data store, which is a data repository required/generated by IDCS. This includes an identity store 618 (which stores users, groups, etc.), a global database 620 (which stores configuration data that IDCS uses to configure itself), a schema separation for each tenant and customer data for each customer. ), an audit schema 624 (which stores audit data), a caching cluster 626 (which increases execution speed by storing cached objects), and the like. All internal and external IDCS consumers are integrated with the identity service according to standards-based protocols. This allows the domain name system ("DNS") to be used to determine where requests should be routed, separating consuming applications from understanding the internal implementation of identity services. Release.

Real-Time and Near-Real-Time Tasks IDCS separates the tasks of requested services into synchronous real-time tasks and asynchronous near-real-time tasks. A real-time task contains only those operations that the user needs to proceed with. In one embodiment, real-time tasks are tasks that run with minimal delay, and near-real-time tasks are tasks that run in the background without waiting for the user. In one embodiment, a real-time task is a task that runs with virtually no or negligible delay, and that appears to the user to be running almost instantly.

Real-time tasks perform the primary business functions of a particular identity service. For example, when requesting a login service, an application sends a message to authenticate the user's credentials and obtain a session cookie for it. What the user experiences is logging into the system. However, a user's login may perform several other tasks, such as verifying who the user is, auditing, sending notifications, and so on. Credential validation is therefore a task that is performed in real-time, as a user is given an HTTP cookie to initiate a session, but notification (e.g. sending an email notifying account creation), audit Tasks related to (eg tracking/recording) etc. are near real-time tasks that can be performed asynchronously so that the user can proceed with minimal delay.

When an HTTP request for a microservice is received, the corresponding real-time task is executed by the middle-tier microservice, and the remaining near-real-time tasks, such as computational logic/events that do not necessarily undergo real-time processing, are sent to message queues 628. be offloaded. The message queue 628 supports a highly scalable asynchronous event management system 630 with guaranteed delivery and processing. Thus, certain behaviors are pushed from the frontend to the backend to enable IDCS to provide a high level of service to its customers by reducing latency in response time. For example, a login process might include validating credentials, submitting log reports, updating the last login time, etc., but these tasks should be offloaded to message queues and performed in near real-time instead of real-time. can be done.

In one example, the system may need to register or create new users. The system calls the IDCS SCIM API to create a user. The end result is a notification email containing a link for this user to reset their password when the user was created in the identity store 618 . When IDCS receives a request to register or create a new user, the corresponding microservice looks to the configuration data in the operational database (located in global database 620 in FIG. ' is marked with a 'user-created' event. This operation is identified in the configuration data as an asynchronous operation. The microservice returns to the client to indicate that the user creation was successful, but the actual sending of the notification email is postponed and pushed to the backend. To do so, the microservice uses the messaging API 616 to put this message into a store, queue 628 .

To dequeue from the queue 628, an infrastructure microservice, the messaging microservice, runs continuously in the background, scanning the queue 628 looking for events in it. Events in queue 628 are processed by event subscribers 630, such as audits, user notifications, application subscriptions, and data analysis. Depending on the task indicated by the event, event subscriber 630 may communicate with, for example, audit schema 624, user notification service 634, identity event subscriber 632, and the like. For example, if the messaging microservice finds a "user-created" event in queue 628, it executes corresponding notification logic and sends a corresponding email to the user.

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

IDCS uses a real-time caching structure to improve system performance and user experience. The cache itself is also provided as a microservice. IDCS implements elastic cache clusters 626 that grow as the number of customers supported by IDCS increases. Cache cluster 626 may be implemented in a distributed data grid that is disclosed in more detail below. In one embodiment, write-only resources bypass the cache.

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

In one embodiment, IDCS may be used to create users. For example, client application 602 may issue a REST API call to create a user. The Administration Service (Platform Services at 614) delegates this call to the User Manager (Infrastructure Libraries/Services at 614). The User Manager then creates this user in the identity store stripe for the specific tenant in the identity store 618 . For "User Create Success", the user manager audits a table in audit schema 624 by auditing the operation and publishes "identity.user.create.success" to message queue 628. do. Identity subscriber 632 picks up this event and sends a "welcome" email containing the newly created login details to the newly created user.

In one embodiment, IDCS may be used to grant roles to users so that they can provision actions. For example, client application 602 may issue a REST API call to grant a role to a user. The management service (platform services at 614) may delegate this call to the role manager (infrastructure library/service at 614). This role manager grants roles in the identity store stripe for a particular tenant within identity store 618 . If "Role Grant Success", the role manager audits the operation against the audit table in audit schema 624 and publishes "identity.user.role.grant.success" to message queue 628. Identity subscriber 632 picks up this event and evaluates the provisioning grant policy. If there was an active application grant for the role being granted, the provisioning subscriber performs some validation, initiates account creation, calls out to the target system, creates the account on the target system, and confirms successful account creation. Mark as done. Each of these functions results in a correspondence such as "prov.account.create.initiate", "prov.target.create.initiate", "prov.target.create.success" or "prov.account.create.success" event will be published. These events may have their own business metric summing the number of accounts created in the target system in the last N days.

In one embodiment, IDCS can be used for user login. For example, client application 602 may request a user's login using one of the supported authentication flows. IDCS authenticates the user and, upon success, audits operations against audit tables in audit schema 624 . Upon failure, IDCS audits the failure in audit schema 624 and publishes a “login.user.login.failure” event in message queue 628 . The login subscriber picks up this event and updates its metrics for the user to determine if additional analysis needs to be performed on the user's access history.

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

Stateless Functions IDCS microservices are stateless. This means that microservices themselves do not maintain state. "State" refers to the data an application uses to perform its function. IDCS provides multi-tenancy capabilities by persisting all state to tenant-specific repositories within the IDCS data tier. The middle tier (ie the code that processes the request) has no data co-located with the application code. Therefore, IDCS is highly scalable both horizontally and vertically.

Vertical scaling (or scaling up/down) means adding resources to (or removing resources from) one node in the system, adding CPU or memory to one computer. is commonly accompanied by Vertical scalability allows an application to scale up to its hardware limits. Horizontal scaling (or scaling out/in) means adding more nodes to the system (or removing nodes from the system), such as adding new computers to a distributed software application. . Horizontal scalability allows applications to scale almost infinitely, constrained only by the amount of bandwidth provided by the network.

The stateless nature of the IDCS middle tier makes it laterally scalable by simply adding more CPUs, and the IDCS components that perform the work of an application rely on a designated physical infrastructure on which a particular application runs. don't need to have The statelessness of the IDCS middle tier makes IDCS highly available, even when providing identity services to a large number of customers/tenants. Each pass through IDCS applications/services concentrates CPU usage exclusively to perform application transactions, but does not use hardware to store data. Scaling is achieved by adding more slices as the application is running, while transactional data is stored in a persistence layer that can add more copies as needed.

The IDCS web tier, middle tier, and data tier are each independently and separately scalable. By scaling the web tier, it can handle more HTTP requests. By scaling the middle tier, more service functions can be supported. You can support more tenants by scaling your data tier.

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

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

IDCS infrastructure services 662b and IDCS infrastructure library 680b provide support for the functionality that IDCS platform services 640b needs to perform its work. In one embodiment, IDCS infrastructure services 662b include job scheduler 664b, UI 666b, SSO 668b, reports 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 compute service 602b (internal Nimbula) supports the functionality of IDCS infrastructure service 662b and IDCS infrastructure library 680b.

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 enables application (eg, customer application 614b, partner application 616b, and cloud application 618b) integration 612b and firmware integration 620b. In one embodiment, various environments may be integrated with IDCS to support their access control needs. Such integration is provided by, for example, identity bridge 622b (providing AD integration, WNA, and SCIM connectors), Apache agent 624b, or MSFT agent 626b.

In one embodiment, internal and external IDCS consumers are integrated with IDCS identity services for standards-based protocols 628b such as OpenID Connect 630b, OAuth2 632b, SAML2 634b, SCIM 636b, and REST/HTTP 638b. This allows the domain name system ("DNS") to be used to determine where to route requests, decoupling application consumption from understanding the internal implementation of identity services. .

The IDCS functional view of FIG. 6A further shows that IDCS provides user notification (cloud notification service 718b), file storage (cloud storage service 716b), and metrics/alerts for DevOPs (cloud monitor service (EM) 722b and cloud metrics service). (graphite) 720b), including public cloud infrastructure services that provide the common functions that it relies on.

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

FIG. 7 is a block diagram 700 of an embodiment implementing CloudGate 702 . Cloud Gate 702 runs within web server 712 and acts as a policy enforcement point (“PEP”). The Policy Enforcement Point is integrated with an IDCS Policy Decision Point (“PDP”) that uses open standards (e.g., OAuth2, OpenID Connect, etc.) while allowing web browsers and applications to access REST API resources 714. configured to be secure. In some embodiments, PDP is implemented with OAuth and/or OpenID Connect microservices 704 . For example, when user browser 706 sends a request to IDCS for login of user 710, the corresponding IDCS PDP, after validating the credential, checks whether the credential is sufficient (e.g., a second password or other (whether or not to request credentials). In the embodiment of FIG. 7, Cloud Gate 702 has local policies, so it can act as both a PEP and a PDP.

As part of the one-time deployment, Cloud Gate 702 is registered with IDCS as an OAuth2 client, which allows requesting OIDC and OAuth2 operations against IDCS. It then holds configuration information about the application's protected and unprotected resources subject to request matching rules (how to match URLs against e.g. wildcards, regular expressions, etc.). do. By deploying Cloud Gate 702, different applications with different security policies can be protected, and the protected applications may be multi-tenant.

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

Cloud Gate 702 also acts as an HTTP Basic Auth Authenticator and verifies HTTP Basic Auth credentials against IDCS. This behavior is supported in sessionless and session-based (local session cookie) modes. In this case, no server-side IDCS session is created.

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

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

When a user logs in, a JWT is issued. JWTs are signed by IDCS and support multi-tenancy capabilities in IDCS. Cloud Gate enables multi-tenant functionality in IDCS by validating JWTs issued by IDCS. IDCS thus provides multi-tenancy both in the physical structure and in the logical business processes that support the security model.

Tenancy Types IDCS identifies three types of tenancies: customer tenancy, client tenancy, and user tenancy. A customer or resource tenancy identifies who the IDCS customer is (ie, to whom the work is being performed). Client tenancy identifies which client application is trying to access the data (ie, which application is performing the work). User tenancy identifies which users are using the application to access data (ie, by whom the work is being performed). For example, when a professional services company provides system integration capabilities for a large discount store and uses IDCS to provide identity management for this large discount store's system, user tenancy is equivalent to this professional services company. while the client tenancy corresponds to the application used to provide system integration functionality and the customer tenancy is a large discount store.

Separating and unifying these three tenancies enables multi-tenancy capabilities in cloud-based services. Generally, for on-premises software installed on on-premises physical machines, there is no need to specify these three tenancies. This is because the user must be physically on the machine to log in. However, for cloud-based service structures, embodiments use tokens to determine who uses which application to access which resource. The three tenancies are codified by tokens, enforced by CloudGate, and used by middle-tier business services. In one embodiment, the OAuth server generates the token. In various embodiments, this token may be used with security protocols other than OAuth.

The separation of users, clients, and resource tenancies provides substantial business advantages to users of the services IDCS provides. For example, by doing so, a service provider that understands the needs of a business (e.g., health business) and its identity management issues, purchases the services provided by IDCS and develops its own back-end applications that consume IDCS' services. and provide this backend application to the target business. Thus, service providers can extend IDCS' services to provide their desired functionality and offer them to specific target businesses. Service providers do not have to build and run software to provide identity services, but instead can extend and customize IDCS services to meet the needs of target businesses.

Some known systems describe only a single tenancy, which is the customer tenancy. However, such systems are inadequate when handling access by a combination of users, such as customer users, customers' partners, customers' clients, the clients themselves, or clients to whom access has been delegated by the customer. Defining and enforcing multiple tenancies in the present embodiment facilitates specifying administrative functions for these diverse users.

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

For example, a client belonging to "Tenant 1" may make a request to obtain a token for "Tenant 2" that specifies a user in "Tenant 3". As another example, a user residing in "Tenant 1" may need to perform an action in an application owned by "Tenant 2". Thus, the user needs to go to the resource namespace of "Tenant2" and request a token for it. Thus, delegation of authority is achieved by specifying ``who'' can do ``what'' and ``who''. As another example, a first user working for a first organization ("Tenant 1") could be a second user working for a second organization ("Tenant 2") and a third "Tenant 3") may be allowed to access documents hosted by it.

In one example, a client of "Tenant 1" may request an access token for a user of "Tenant 2" to access an application of "Tenant 3". The client may request the token by going to "http://tenant3/oauth/token" and invoking an OAuth request for this token. The client identifies itself as a client residing in "tenant 1" by including a "client assertion" in the request. This client assertion includes a client ID (eg, "Client 1") and a client tenancy ("Tenant 1"). As 'Client 1' of 'Tenant 1', the client has the right to invoke a request for a token for 'Tenant 3' and wants a token for a user of 'Tenant 2'. Therefore, a "user assertion" is also sent as part of the same HTTP request. The access token that is generated is issued in the context of the target tenancy, which is the application tenancy ("Tenant 3") and includes the user tenancy ("Tenant 2").

In one embodiment, each tenant in the data tier is implemented as an independent stripe. From a data management perspective, artifacts reside in tenants. From the service's perspective, the service knows how to work with heterogeneous tenants, and multiple tenancies are different dimensions in the service's business functionality. FIG. 8 illustrates an example system 800 that implements multiple tenancies in some embodiments. System 800 includes client 802 , which requests services provided by microservices 804 that understand how to work with data in database 806 . This database contains multiple tenants 808, each containing a corresponding tenancy artifact. In one embodiment, microservice 804 is an OAuth microservice requested through https://tenant3/oauth/token to obtain a token. The functionality of the OAuth microservice is executed in the microservice 804 using data from the database 806 to verify whether the client 802 request is valid and, if valid, to a different tenancy 808. data from is used to construct the token. Thus, system 800 is multi-tenant in that it can work in a cross-tenant environment by supporting services that are provided to each tenancy as well as services that can act on behalf of various tenants.

System 800 is convenient. The reason is as follows. Microservices 804 are physically separated from data in database 806, and by replicating data through locations closer to the client, microservices 804 can be offered as local services to clients, system 800 Manage service availability and deliver it globally.

In one embodiment, microservices 804 are stateless. This means that the machine running microservice 804 does not maintain a marker that indicates the service for a particular tenant. Alternatively, the tenancy may be marked, for example, in the host portion of the URL of incoming requests. This tenancy represents one of the tenants 808 of database 806 . When supporting a large number of tenants (eg, millions of tenants), microservices 804 cannot have the same number of connections to database 806 . Microservices 804 instead use connection pools 810 that provide the actual physical connections to databases 806 in the context of database users.

Generally, connections are constructed by providing a connection string to the underlying driver or provider. The connection string is used to address a particular database or server and to provide instance and user authentication credentials (e.g. "Server=sql_box;Database=Common;User ID=uid;Pwd=password; ”). Once a connection is established, it can be opened and closed, and properties (eg, command timeout length, or transaction if one exists) can be set. The connection string contains a set of key-value pairs dictated by the data access interface of the data provider. A connection pool is a cache of database connections that is maintained so that connections can be reused when future requests to the database are needed. In connection pooling, connections are placed in a pool after they are created and reused so that new connections do not need to be established. For example, if 10 connections are required between microservice 804 and database 808, then connection pool 810 has all of them in the context of the database user (e.g., relative to a particular database user, e.g. who owns this connection). There will be 10 connections open (relative to the user, whose credentials are being verified, whether it is a database user, whether it is a system credential, etc.).

Connections in connection pool 810 are created for system users who have access to anything. Therefore, in order to correctly handle auditing and privileges by microservices 804 processing requests on behalf of a tenant, database operations are performed in the context of a "proxy user" 812 associated with the schema owner assigned to a particular tenant. be. This schema owner has access only to the tenancy for which this schema was created, and the value of this tenancy is that of this schema owner. When a request is made for data in database 806 , microservice 804 serves this data using a connection in connection pool 810 . Multi-tenancy is therefore a tenant-specific datastore binding built per request on top of a data connection created in the context of (e.g., in relation to) a datastore proxy user associated with a resource tenancy. By having a stateless, elastic middle-tier service that handles incoming requests in the context of (eg, in relation to) the database, the database can scale independently of the service.

The following provides an example of functionality for implementing proxy user 812 .

In this function, the microservice 804 uses database connections in the connection pool 810 while setting the "Proxy User" setting for connections drawn from the connection pool 810 to "Tenant". and perform data operations in the context of the tenant.

When configuring different columns for different tenants in the same database by striping all tables, one table may contain data for all tenants mixed. In contrast, one embodiment provides a tenant-driven data layer. Rather than striping the same database for different tenants, this embodiment provides a different physical database for each tenant. For example, multi-tenancy may be achieved using pluggable databases (eg, 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 asks for the data source for that request (separate from the metadata). The embodiment performs a runtime switch to each data source/store for each request. By isolating each tenant's data from other tenants, the present embodiment provides improved data security.

In one embodiment, different tokens code different tenancies. A URL token may identify the tenancy of the application requesting the service. An identity token may code the identity of the user to be authenticated. An access token can specify multiple tenancies. For example, an access token may code the tenancy (eg, application tenancy) that is the target of such access and the user tenancy of the user granted access. A client assertion token may identify a client ID and client tenancy. A user assertion token may identify a user and user tenancy.

In one embodiment, the identity token contains at least a "claim/statement" that indicates the user tenant name (ie, where the user resides). A "claim" (as used by those skilled in the security arts) associated with an authentication token is a statement made by one entity about itself or another. Statements may be about names, identities, keys, groups, rights, or capabilities, for example. Claims are issued by a provider, given one or more values, and then packaged into an issuer-issued security token commonly known as a security token service ("STS"). be done.

In one embodiment, an access token is at least a claim/statement that indicates the resource tenant name (e.g., customer) at the time the request for the access token was made, a claim that indicates the user tenant name, and the requesting OAuth client's Includes a name claim and a client tenant name claim. In one embodiment, access tokens may be implemented according to the following JSON functions.

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

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

FIG. 9 is a block diagram of an IDCS network view 900 in one embodiment. FIG. 9 illustrates network interaction between application “zones” 904 in one embodiment. Applications are divided into zones (eg, SSL zones, no SSL zones, etc.) based on the level of protection required and the implementation of connectivity to various other systems. Of the Application Zones, some are Application Zones that provide services that require access from within IDCS, some are Application Zones that provide services that require access from outside IDCS, and some are open access. . Each protection level is thus strengthened for each zone.

In the embodiment of FIG. 9, communication between services is done using HTTP requests. In one embodiment, IDCS uses the access tokens described herein to not only provide services, but also to secure access to IDCS and access within IDCS itself. In one embodiment, IDCS microservices are exposed through a RESTful interface and secured with tokens as described herein.

In the FIG. 9 embodiment, any one of various applications/services 902 may use the IDCS service by making HTTP calls to the IDCS API. In one embodiment, HTTP requests for applications/services 902 are routed to Oracle public cloud load balancing external virtual IP addresses (“VIPs”) 906 (or other similar technology), public cloud web routing layer 908, and IDCS load balancing internal VIPs. It may be received by IDCS web routing layer 912 through appliance 910 (or other similar technology). IDCS web routing layer 912 receives requests from outside or inside IDCS and routes them through IDCS platform services layer 914 or IDCS infrastructure services layer 916 . The IDCS platform services layer 914 contains IDCS microservices called from outside of IDCS such as OpenID Connect, OAuth, SAML, SCIM. The IDCS infrastructure services layer 916 contains supporting microservices invoked from within IDCS to support the functionality of other IDCS microservices. Examples of IDCS infrastructure microservices are UI, SSO, reporting, caching, job scheduler, service manager, functions to create keys, and so on. IDCS cache layer 926 supports caching functionality for IDCS platform services layer 914 and IDCS infrastructure services layer 916 .

By enhancing the security of both external access to IDCS and internal access to IDCS, IDCS customers can be given outstanding security compliance for the applications they run.

In the FIG. 9 embodiment, the OAuth protocol is used except for the data layer 918, which communicates based on Structured Query Language (“SQL”), and the identity store layer 920, which communicates based on LDAP. secures communications between IDCS components (eg, microservices) within IDCS, and uses the same tokens used to secure access from outside IDCS for security within IDCS. That is, the web routing layer 912 uses the same tokens and protocols for processing received requests, whether they come from outside IDCS or inside IDCS. IDCS thus enables outstanding security compliance by providing one consistent security model to protect the entire system. This is because the fewer security models implemented in a system, the more secure the system.

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

In one embodiment, callers external to IDCS may not need to know where 'Y' is, but web routing layer 912 does need to know where application 'Y' is running. In one embodiment, IDCS implements a discovery function (implemented by an OAuth service) to determine where each application is running so that the availability of static routing information is not required.

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, Chef Software's configuration management tool, “Chef” server 924, provides configuration management functions for the various IDCS layers. In one embodiment, the service deployment infrastructure and/or persistent storage module 928 sends OAuth2 HTTP messages to the IDCS web routing layer 912 for tenant lifecycle management operations, public cloud lifecycle management operations, or other operations. You may In one embodiment, IDCS infrastructure services layer 916 may send ID/password HTTP messages to public cloud notification service 930 or public cloud storage service 932 .

Cloud Access Control - SSO
One embodiment supports lightweight cloud standards to enable cloud-scale SSO services. Examples of lightweight cloud standards include HTTP, REST, and standards that provide access through a browser (because web browsers are lightweight). Conversely, SOAP is an example of a heavyweight cloud standard that requires more administration, configuration, and tools to build a client. The present embodiment requires user authentication to IDCS by using OpenID Connect semantics for applications. The present embodiment uses lightweight HTTP cookie-based user session tracking to track a user's active sessions in IDCS without stateful server-side session support. The present embodiment uses JWT-based identity tokens when mapping authenticated identities back to their local sessions for consuming applications. This embodiment supports integration with federated identity management systems and exposes enterprise deployment SAML IDP support for requiring user authentication to IDCS.

FIG. 10 is a block diagram 1000 of a system architecture view of SSO functionality within IDCS in one embodiment. The present embodiments allow client applications to drive standards-based web protocols to initiate user authentication flows. Applications requiring integration of cloud systems with SSO may reside in corporate data centers, remote partner data centers, or may be operated by on-premises customers. In one embodiment, different IDCS platform services are connected, OpenID Connect for handling login/logout requests from native applications to which they are connected (i.e. applications that utilize OpenID Connect to integrate with IDCS). IDCS including a SAML IDP service for handling browser-based login/logout requests from existing applications, a SAML SP service for coordinating user authentication to external SAML IDPs, and a local or federated login flow. Enable the business of SSO, such as internal IDCS SSO services for coordinating end-user login ceremonies for managing host session cookies. In general, HTTP works with or without forms. When working with a form, this form is the form visible in the browser. When working without forms, this works as client-to-server communication. Both OpenID Connect and SAML require the ability to render forms, which is accomplished through the presence of a browser or virtually performed by an application acting as if a browser were present. In one embodiment, an application client that implements user authentication/SSO through IDCS needs to be registered as an OAuth2 client in IDCS to obtain a client identifier and credentials (e.g. ID/password, ID/certificate, etc.) There is a need.

The example embodiment of FIG. 10 has three components/microservices that collectively provide login functionality, including OAuth2 1004 and SAML2 1006 as two platform microservices and SSO 1008 as one infrastructure microservice. include. In the embodiment of Figure 10, IDCS provides an "identity metasystem". In this metasystem, SSO services 1008 are provided for different kinds of applications. These applications are browser-based web or native applications 1010, 2 that require a three-way OAuth flow and act as an OpenID Connect relaying party (“RP”, an application that outsources its user authentication functions to an IDP). For example, a native application 1011 that requires inter-party OAuth flow and functions as an OpenID Connect RP, and a web application 1012 that functions as a SAML SP.

In general, an identity metasystem is an interoperable architecture for digital identities, allowing a collection of multiple underlying technologies, implementations, and providers to be used. LDAP, SAML, and OAuth are examples of different security standards that provide identity functionality and can be the basis for building applications, and an identity metasystem is unified for such applications. may be configured to provide a security system with The LDAP security model specifies specific mechanisms for handling identities, and all paths through the system must be strictly protected. SAML was developed to allow a 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 these two applications, SAML was developed to allow one application to authenticate another application that does not belong to the same organization. OAuth provides OpenID Connect, a lightweight protocol for performing web-based authentication.

In the embodiment of FIG. 10, when an OpenID application 1010 connects to an OpenID server in IDCS, its "channel" requests SSO services. Similarly, when a SAML application 1012 connects to a SAML server in IDCS, its "channel" also requests SSO services. In IDCS, each microservice (eg, OpenID microservice 1004 and SAML microservice 1006 ) handles each application and these microservices request SSO functionality from SSO microservice 1008 . This architecture can be extended to support any number of other security protocols by adding a microservice for each protocol and then using the SSO microservice 1008 for SSO functionality. The SSO microservice 1008 issues sessions (ie SSO cookies 1014 are provided) and is the only system in this architecture that has the authority to issue sessions. An IDCS session is accomplished by browser 1002 using SSO cookie 1014 . Browser 1002 also manages its local session using local session cookie 1016 .

In one embodiment, for example, within a browser, a user logs in using a first application based on SAML and then uses a second application built with a different protocol such as OAuth to good too. The user is given SSO on a second application within the same browser. The browser is therefore the state or user agent and manages cookies.

In one embodiment, SSO microservice 1008 provides login ceremony 1018, ID/password recovery 1020, first login flow 1022, authentication manager 1024, HTTP cookie manager 1026, and event manager 1028. The Login Ceremony 1018 implements SSO functionality based on customer settings and/or application context, and may be configured according to local forms (eg Basic Auth), external SAML IDP, external OIDC IDP, and the like. ID/Password Recovery 1020 is used to recover a user's ID and/or password. The first login flow 1022 is implemented when the user logs in for the first time (ie, no SSO session exists yet). Authentication manager 1024 issues an authentication token upon successful authentication. HTTP cookie manager 1026 stores the authentication token in an SSO cookie. Event manager 1028 publishes events related to SSO functionality.

In one embodiment, the interaction between the OAuth microservice 1004 and the SSO microservice 1008 is based on a browser redirect, with the SSO microservice 1008 querying the user with an HTML form, validating credentials, and using a session cookie. to be issued.

In one embodiment, for example, OAuth microservice 1004 receives an authorization request from browser 1002 and authenticates the user of the application according to a three-way OAuth flow. Thus, the OAuth microservice 1004 acts as an OIDC provider 1030 and redirects the browser 1002 to the SSO microservice 1008 to go along with the application context. Depending on whether the user has a valid SSO session or not, the SSO microservice 1008 either validates the existing session or performs a login ceremony. Upon successful authentication or verification, SSO microservice 1008 returns an authentication context to OAuth microservice 1004 . OAuth microservice 1004 then redirects browser 1002 to a callback URL with an authorization (“AZ”) code. Browser 1002 sends the AZ code to OAuth microservice 1004 requesting the required token 1032 . Browser 1002 also includes its client credentials (obtained when IDCS was registered as an OAuth2 client) in the HTTP authorization header. In response, OAuth microservice 1004 provides browser 1002 with the requested token 1032 . In one embodiment, token 1032 provided to browser 1002 includes a JW identity and an access token signed by the IDCS OAuth2 server. Further details of this function are disclosed below with reference to FIG.

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

In one embodiment, for example, SAML microservice 1006 receives an SSO POST request from a browser to authenticate a user of web application 1012 acting as a SAML SP. SAML microservice 1006 then acts as SAML IDP 1038 and redirects browser 1002 to SSO microservice 1008 to proceed along the application context. Depending on whether the user has a valid SSO session or not, the SSO microservice 1008 either validates the existing session or performs a login ceremony. Upon successful authentication or verification, SSO microservice 1008 returns an authentication context to SAML microservice 1006 . The SAML microservice then redirects to the SP with the required token.

In one embodiment, for example, the SAML microservice 1006 may function as a SAML SP 1040 and may go to a remote SAML IDP 1042 (eg, active directory federation service (“ADFS”)). implements a standard SAML/AD flow, hi one embodiment, the interaction between the SAML microservice 1006 and the SSO microservice 1008 is based on browser redirects, and the SSO microservice 1008 uses HTML forms. user, validates credentials, and issues a session cookie.

In one embodiment, interactions between components internal to IDCS (eg, 1004, 1006, 1008) and components external to IDCS (eg, 1002, 1011, 1042) occur through firewall 1044.

Login/Logout Flow FIG. 11 is a message sequence flow 1100 for the SSO functionality provided by IDCS in one embodiment. When a user accesses a client 1106 (e.g., a browser-based application or a mobile/native application) using a browser 1102, Cloud Gate 1104 acts as an application enforcement point and enforces policies specified in local policy text files. do. If Cloud Gate 1104 detects that the user does not have a local application session, Cloud Gate 1104 requests authentication of the user. To do so, Cloud Gate 1104 initiates the OpenID Connect login flow to the OAuth2 microservice 1110 by redirecting the browser 1102 to the OAuth2 microservice 1110 (a three-way AZ Grant flow, scope = “openid profile ”).

The browser 1102 request traverses the IDCS routing layer web service 1108 and Cloud Gate 1104 to reach the OAuth2 microservice 1110 . The OAuth2 microservice 1110 configures the application context (i.e. metadata describing the application, e.g. the identity of the connecting application, client id, configuration, what the application can do, etc.) and directs the browser 1102 to the SSO microservice for login. Redirect to service 1112 .

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

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

Upon successful authentication or verification, SSO microservice 1112 sends browser 1102 a newly created/updated SSO host HTTP cookie (e.g., the cookie created in the context of the host indicated by "HOSTURL") containing the user's authentication token. ) to redirect the browser 1102 back to the OAuth2 microservice 1110 . OAuth2 microservice 1110 redirects the AZ code (eg, OAuth concept) back to browser 1102 to Cloud Gate 1104 . Browser 1102 sends the AZ Code to Cloud Gate 1104, and Cloud Gate 1104 sends a REST POST to OAuth2 microservice 1110 requesting an access token and an identity token. Both of these tokens are scoped to the OAuth microservice 1110 (indicated by the Audience Token claim). Cloud Gate 1104 receives these tokens from OAuth2 microservice 1110 .

Cloud Gate 1104 uses the identity token to map the authenticated user's identity to its internal account representation, and it may store this mapping in its own HTTP cookie. Cloud Gate 1104 then redirects browser 1102 to client 1106 . Browser 1102 then reaches client 1106 and receives a corresponding response from client 1106 . From this point forward, browser 1102 can seamlessly access the application (ie, client 1106) as long as the application's local cookie is valid. Once the local cookie is invalidated, the authentication process is repeated.

Cloud Gate 1104 also uses the access token included in the request to obtain the "userinfo" from the OAuth2 microservice 1110 or from the SCIM microservice. This access token is sufficient to access the 'userinfo' resource in the attributes given by the 'profile' scope. This is also sufficient to access the "/me" resource via SCIM microservices. In one embodiment, by default, the included access token is sufficient only for user profile attributes given under the "profile" scope. Access to other profile attributes is authorized based on additional (optional) scopes presented in the AZ Grant login request issued by Cloud Gate 1104.

The same process is repeated if the user accesses another OAuth2-integrated application.

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 and initiates a logout. Alternatively, the user may have initiated a logout on the IDCS side. Cloud Gate 1104 terminates the application-specific user session and initiates an OAuth2 OpenID provider (“OP”) logout request to OAuth2 microservice 1110 . OAuth2 microservice 1110 redirects to SSO microservice 1112 which deletes the user's host SSO cookie. The SSO microservice 1112 initiates a set of redirects (OAuth2 OP and SAML IDP) to known logout endpoints tracked in the user's SSO cookie.

In one embodiment, when Cloud Gate 1104 requires user authentication (eg, login) using the SAML protocol, a similar process is initiated between the SAML microservice and SSO microservice 1112 .

Cloud Cache One embodiment provides a service/feature called Cloud Cache, which is an LDAP front end. A cloud cache is provided to IDCS to support communication with LDAP-based applications (eg, email servers, calendar servers, some business applications, etc.). This is because IDCS does not communicate according to LDAP, whereas such applications are configured to communicate only based on LDAP. Typically, cloud directories are exposed via REST APIs and do not communicate according to the LDAP protocol. In general, managing LDAP connections through a corporate firewall requires special configurations that are difficult to set up and manage.

To support LDAP-based applications, the cloud cache translates LDAP communications into a protocol suitable for communicating with cloud systems. Generally, LDAP-based applications use databases through LDAP. Alternatively, the application may 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, whereas SQL represents data as tables and fields. Therefore, it would be more desirable for LDAP to be for search functions. SQL, on the other hand, would be more desirable for transactional functions.

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 of the application (i.e. security services). can. In one embodiment, the interface with IDCS is through a firewall and based on HTTP (eg, REST). Typically, corporate firewalls do not allow access to internal LDAP communications, even when such communications implement Secure Sockets Layer ("SSL"). Also, corporate firewalls do not allow TCP ports to be exposed through the firewall. However, Cloud Cache translates between LDAP and HTTP to allow LDAP-based applications to reach services provided by IDCS, and the firewall is open to HTTP.

Generally, LDAP directories may be used in lines of business, such as marketing and development, to define users, groups, jobs, and the like. In one example, a marketing and development business may target multiple customers, each of which may have its own applications, users, groups, activities, and so on. Another example of a line of business that may implement an LDAP cache directory is a wireless service provider. In this case, each call made by a user of the wireless service provider authenticates the user's device against the LDAP directory, and some of the corresponding information in the LDAP directory may be synchronized with the billing system. In these examples, LDAP provides the ability to physically separate content that is searched at runtime.

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

Distributed Data Grid In one embodiment, cache clusters in IDCS are implemented based on the distributed data grid disclosed, for example, in US Patent Publication No. 2016/0092540, the disclosure of which is incorporated herein by reference. . A distributed data grid is a system in which a collection of computer servers in one or more clusters in a distributed or clustered environment work together to manage information and related operations, such as computations. A distributed data grid can be used to manage application objects and data shared between servers. Distributed data grids offer fast response times, high throughput, predictable scalability, continuous availability, and reliability of information. As a concrete example, distributed data grids, such as Oracle's Oracle Coherence data grid, achieve even higher performance by storing information in-memory, keeping information synchronized across multiple servers. By using redundancy in maintaining a copy of , we ensure the resilience of the system and the continued availability of data in the event of a server failure.

In one embodiment, IDCS implements a distributed data grid, such as Coherence, allowing all microservices to request access to shared cached objects without blocking. Coherence is a proprietary, Java-based, in-memory data grid designed for greater reliability, scalability, and performance compared to traditional relational database management systems. Coherence provides a peer-to-peer (ie no central manager) in-memory distributed cache.

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

As shown in FIG. 12, a distributed data grid provides data storage and management functionality by distributing data across multiple servers (eg, 1220a, 1220b, 1220c, and 1220d) working together. Each server in the data grid cluster is a conventional computer, such as a "commodity x86" server hardware platform with 1 to 2 processor sockets and 2 to 4 CPU cores per processor socket. It may be a system. Each server (eg, 1220a, 1220b, 1220c, and 1220d) has one or more CPUs, a Network Interface Card (“NIC”), and, for example, a minimum of 4 GB of RAM and a maximum of 64 GB or more of RAM. It consists of memory and Server 1220a is shown as having a CPU 1222a, a memory 1224a, and a NIC 1226a (these elements are also present on other servers 1220b, 1220c, 1220d but not shown). Optionally, each server may be provided with flash memory (eg, SSD 1228a) to provide excess storage capacity. As provided, the SSD capacity is preferably ten times the size of the RAM. The servers (eg, 1220a, 1220b, 1220c, 1220d) of the data grid cluster 1200a are connected to a high-performance network switch 1220 (eg, Gigabit or higher Ethernet) using high-bandwidth NICs (eg, PCI-X or PCIe) It is connected to the.

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

In most Wide Area Network (“WAN”) configurations of a distributed data grid 1200, each data center within the WAN is a separate but interconnected data grid cluster (eg, 1200a, 1200b). , and 1200c). A WAN may include more clusters than shown in FIG. 12, for example. Additionally, by using interconnected but independent clusters (e.g., 1200a, 1200b, 1200c) coupled via links 1206 and/or interconnected but independent By placing the clusters in data centers that are far apart from each other, the distributed data grid is designed to prevent the simultaneous loss of all servers in one cluster caused by natural disasters, fires, floods, extended power outages, etc. Data and services to clients 1250 can be guaranteed.

One or more nodes (eg, 1230a, 1230b, 1230c, 1230d and 1230e) run on each server (eg, 1220a, 1220b, 1220c, 1220d) of cluster 1200a. In a distributed data grid, nodes may be, for example, software applications, virtual machines, etc., and servers may include operating systems, hypervisors, etc. (not shown) on which the nodes run. In the Oracle Coherence data grid, each node is a Java virtual machine (“JVM”). There may be multiple JVMs/nodes on each server, depending on CPU processing power and memory available on the server. JVMs/nodes may be added, started, stopped, and removed as required by the distributed data grid. JVMs running Oracle Coherence automatically join and cluster at startup. JVMs/nodes that join a cluster are called cluster members or cluster nodes. Each cluster can also be connected to a standard database 1210 containing accessible data 1212 .

Architecture Each client or server includes a bus or other communication mechanism for communicating information, and a processor coupled with the bus for processing information. The processor can be any type of general purpose or special purpose processor. Each client or server may also include memory for storing information and instructions for execution by the processor. The memory may consist of random access memory (“RAM”), read only memory (“ROM”), static storage such as magnetic or optical disks, or any other combination of computer readable media. Each client or server may further include a communication device such as a network interface card to provide access to the network. Thus, a user can interface with each client or server directly, remotely through a network, or by any other means.

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

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

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

Clients may access web services, such as cloud services. In one embodiment, the web service may be implemented on Oracle's WebLogic Server. Other implementations of web services may be used in other embodiments. Web services access databases that store cloud data.

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

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

In one embodiment, this request includes a URL. In one embodiment, microservices are identified in a URL prefix. In one embodiment, the resource portion of the URL identifies the API. In one embodiment, the host portion of the URL identifies the tenancy of the resource associated with the request. For example, in a URL like "host/microservice/resource" in the IDCS web environment, a microservice is characterized by having a specific URL prefix (e.g. "host/oauth/v1") and the actual microservice is is 'oauth/v1' and there are multiple APIs under 'oauth/v1', for example APIs for requesting tokens: 'host/oauth/v1/token', authorizing users API for (authorize): such as "host/oauth/v1/authorize". That is, the URL implements the microservice and the resource portion of the URL implements the API. Thus, multiple APIs are aggregated under the same microservice. In one embodiment, the host portion of the URL identifies the tenant (eg, https://tenant3.identity.oraclecloud.com:/oauth/v1/token").

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

The microservices are then accessed based on the API, for example as described herein with reference to the IDCS "API platform" of FIG. In one embodiment, communication with the microservice is configured through the microservice's anonymous universal port. In one embodiment, a microservice's anonymous universal port is a standard communication channel that a conventional microservice exposes (eg, as a conventional HTTP port) to which any other module/microservice within the same service It is a standard communication channel that allows people to talk to each other. In one embodiment, microservices provide one or more functions by exposing one or more APIs. In one embodiment, communication with microservices is accomplished only through one or more APIs. That is, touching/contacting a microservice is achieved only by calling such an API. In one embodiment, communication with microservices is structured according to a lightweight protocol. In one embodiment, lightweight protocols include HTTP and REST. In one embodiment, the request includes a call to a RESTful HTTP API. Accordingly, one embodiment provides dispatch functionality. Each HTTP request contains a URI and a verb. The present embodiment parses the URI endpoint (host/service/resource) and combines it with an HTTP verb (e.g. POST, PUT, PATCH, or Delete) to determine the appropriate method of the appropriate module. dispatch (or call). This pattern is common in REST and is supported by various packages (eg Jersey).

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

On -Premises Integration As disclosed above in connection with FIG. 2, on-premises applications 218, which may reside at client locations, can be managed by a cloud-based third-party identity management system, such as IDCS 202. . However, in general, clients may be reluctant to allow third-party cloud services to send commands to them through their firewalls. In contrast, in embodiments, the client first contacts IDCS 202 instead to request an action (referred to as a "target action"). This is the opposite of receiving unsolicited actions from IDCS 202 through the client's firewall. This feature is commonly called "delegated authentication".

Given the reality that a client may not "trust" the cloud service and thus may not open its firewall to the cloud service, embodiments are concerned with how to remove resources on a client's premises from the cloud. Solve the problem of managing Embodiments use asynchronous responses based on the Java API for RESTful Web Services (“JAX-RS”). Since asynchronous callbacks are used for delegated authentication, an asynchronous callback is executed. For example, when a user logs into IDCS 202, the user is not authenticated by a local identity stored in IDCS 202, but is passed through to an on-premise active directory such as Active Directory (“AD”) 204 in FIG. be. In this pass-through scenario, AD 204 will perform authentication on behalf of IDCS 202 .

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

One possible solution for latency reduction is to use HTTP request/response. Specifically, it posts a login request directly to the bridge/AD 204 and waits for a response. However, since this solution uses database persistence, it is not optimized to prevent latency.

In contrast, embodiments provide notification to both (ie, IDCS 202 and AD 204) by using cache listeners as in Coherence 1200 rather than persistence in the database to avoid latency. In embodiments, the cache listener is a feature of the Coherence Cache Service, which is one of the IDCS 202 microservices. Cache listeners can be implemented by other types of in-memory distributed data grids in addition to Coherence. The notification (ie, request/response) includes the time at which authentication needs to occur and the completion of authentication (ie, whether authentication succeeded or failed). Thus, a customer who already has all of that user's username/password stored in AD 204 may use IDCS 202 as a pass-through mechanism for authentication, storing a duplicate of the username/password in IDCS 202. do not have to.

In embodiments, the AD bridge 230 (shown as "ID" bridge 230 in FIG. 2) is already optimized for low latency. By using the disclosed framework of target actions, actions can be taken against on-premise targets, but the speed and latency reduction required for the delegated authentication disclosed herein. .

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

FIG. 13 illustrates the functionality between IDCS 202 and on-premises active directory 204 via bridge 230 from the perspective of IDCS 202 when performing delegated authentication, according to an embodiment. FIG. 14 illustrates the functionality between IDCS 202 and on-premises Active Directory 204 via bridge 230 from the perspective of Active Directory 204 when performing delegated authentication, according to an embodiment. The functions generally shown in FIGS. 13 and 14 are as follows.
The caller performs an action (such as POST /TargetActions or GET /AsyncTargetActions) The caller registers a listener with a particular cache The listener interrupts the caller when the desired event occurs If the desired event does not occur, the caller is advised of the work to be done for pending TargetActions, e.g., authentication, password change targeting an AD domain managed by AD Bridge polling To do so, perform a DB search via a GET /AsyncTargetAction request.

Regarding which entity is considered the "calling party", for POST/TargetActions the call is initiated/called when the user logs in and the login is set up for pass-through/delegated authentication to the AD domain. For GET/AsyncTargetActions, the call is initiated/called by the AD Bridge 230 to initiate polling for TargetActions such as authentication, password change, user update, etc. (collectively "authentication actions").

The elements shown in FIGS. 13 and 14 include SSO service 1350 and Admin service 1351 . SSO service 1350 and management service 1351 in embodiments are implemented in separate IDCS microservices. Management Service 1351 includes all the endpoints shown, which are Password Authenticator 1352, User 1353, Target Actions (“TA”) 1301, Target Action Results ) (“TAR”) 1302 and async target actions (“ATA”) 1354 . These elements further include a tenant database (“DB”) 1355 and a cache 1356, which in embodiments is a Coherence cache, implemented as a microservice in IDCS. Caches 1356 include three different caches that communicate with management service 1351: TA cache, TAR cache, and ATA cache. AD Bridge 230 and AD 204 on the other side of the "pipe" between IDCS and on-premises elements are on-premises.

A TA is the endpoint that an IDCS client uses to initiate a request to a target, containing whatever action is requested for this target. TAR is the result of a request. For delegated authentication, the TAR is posted by the bridge 230 back to the IDCS server. In general, TA is the request and TAR is the response. All TAs contain the appID (ie AD domain ID) of the targeted application. In an embodiment, all synchronous TA 1301 threads block until they get the TAR 1302 of the response. In contrast, the asynchronous TA 1354 thread polls (ie, does not block) until it gets the TAR 1302 of the response.

Referring to the functionality of FIG. 13, at 1310 the user logs into the SSO service 1350 (e.g., the user can log into IDCS 202 to modify its profile as an end-user, can perform IDCS administrator tasks, access other applications to which it has been granted access, etc.). At 1311 the resulting SSO service thread calls the admin service http client POST/UPA (i.e. User Password Authenticator) until admin service 1351 returns admin service acquisition thread 1 at 1312 , to block. At 1313, the UPA calls GET/Users to acquire a DB connection and calls DB Search (e.g., for pending TargetActions such as authentication, password change targeting an AD domain managed by AD bridge polling, etc.). , for work to do, via a GET /AsyncTargetAction request). At 1314 the user is returned to PA 1352 .

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

Referring to Figure 14, in response to 1316, the bridge 230 first calls GET/AsyncTargetAction for the given appID at 1410, so the bridge thread blocks until an asynResponse timeout or TargetActions are returned. The bridge thread polls until TargetActions are returned for processing or until the polling timeout is reached (eg 60 seconds). The http thread on the IDCS server is released, but the AD bridge thread is blocked while polling. In response, at 1411, the server (i.e., the IDCS management service servicing the AsyncTargetAction REST request) does a GET /AsyncTargetActionss, creating a management service thread until the asyncResponse timeout is reached at 1412 (60 seconds), or Blocks until called back by the coherence cache listener when an authentication TargetAction is created for an appId managed by the bridge. At 1413, it registers a cache listener to call when a TargetAction is created for an appId managed by the bridge. AsyncTargetAction is called back by coherence cache listeners when an authentication TargetAction is created for an appId managed by the bridge.

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

Referring again to 13, at 1319 the TargetAction is called back by the Coherence cache listener when the authentication TargetActionResult is created for the appId managed by the bridge. At 1320, get the TargetActionResult matching the authentication TargetAction id from the cache, add the TargetActionResult to the TargetAction response, and at 1321 return the TargetAction response to the UPA.

The UPA returns the response to the SSO service, releases management service thread 1, and the SSO service returns 1325 the response to the user. The SSO service thread is then released.

The following pseudocode example implements delegated authentication functionality according to an embodiment.

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

Embodiments ensure that synchronous TAs have higher priority than asynchronous TAs for transmission to the bridge, but at the same time that asynchronous TAs are not blocked by synchronous TAs for too long. It is acceptable that asynchronous TAs take longer to send to the bridge because of the priority of sending the synchronous TAs to the bridge first, as long as the asynchronous TAs are sent to the bridge in a reasonable amount of time.

Accordingly, embodiments treat synchronous target actions separately from asynchronous target actions at a high level.
• Synchronous target actions require a "fast path" because the requester is blocking.
Asynchronous target actions take the slower path, so
o It is possible to prioritize synchronous target actions over asynchronous ones,
o Target actions can be ordered as desired.

The following table summarizes the sync target action flow according to embodiments. In the table below, each bridge polls for a long time waiting for synchronous TargetActions. The IDCS client posts a synchronous TargetAction and then blocks waiting for the TargetActionResult.

The following table summarizes the asynchronous target action flow according to embodiments. In the table below, each bridge polls for a long time waiting for asynchronous TargetActions. The IDCS client posts asynchronous TargetActions, then waits and polls for TargetActions.

As disclosed, embodiments optimize request/response flows by promoting Coherence cache callbacks. Embodiments reduce latency when cloud-based authentication systems (eg, IDCS) interface with on-premise authentication systems (eg, AD) with cache callbacks.

Claims (20)

A method of operating a multi-tenant cloud system, the method comprising:
receiving a request for an authentication action for a user;
creating an authentication target action;
registering a cache listener to listen for target action responses in response to said authentication target action;
initiating an authentication action for said user via a bridge with an on-premise Active Directory (AD);
waiting for a cache callback;
receiving, in said cache callback, a target action response including a result of said authentication action. 2. The method of claim 1, wherein the request for authentication action is received at the multi-tenant cloud system. 3. The method of claim 2, wherein a result of said authentication action is received from said on-premises AD. while waiting for the cache callback, polling for threads created for the authentication action;
2. The method of claim 1, wherein said polling continues until said cache callback or timeout. 2. The method of claim 1, wherein the cache listener is implemented by an in-memory distributed data grid. 2. The method of claim 1, wherein the authentication action is an asynchronous action including changing a password. 7. The method of claim 6, wherein said asynchronous actions are assigned a lower priority than synchronous actions, said synchronous actions including logging in said user. 2. The method of claim 1, wherein the multi-tenant cloud system accesses the on-premises active directory through a firewall. A computer-readable medium storing instructions that, when executed by at least one processor of a plurality of processors, cause said processor to operate a multi-tenant cloud system, said operation comprising:
receiving a request for an authentication action for a user;
creating an authentication target action;
registering a cache listener to listen for target action responses in response to the authentication target action;
Initiating an authentication action for the user via a bridge with an on-premises Active Directory (AD);
waiting for a cache callback; and
receiving, in the cache callback, a target action response that includes a result of the authentication action. 10. The computer-readable medium of claim 9, wherein the request for authentication action is received at the multi-tenant cloud system. 11. The computer-readable medium of claim 10, wherein a result of said authentication action is received from said on-premises AD. The operation further includes polling for threads created for the authentication action while waiting for the cache callback;
10. The computer-readable medium of claim 9, wherein said polling lasts until said cache callback or timeout. 10. The computer-readable medium of Claim 9, wherein the cache listener is implemented with an in-memory distributed data grid. 10. The computer-readable medium of Claim 9, wherein the authentication action is an asynchronous action including changing a password. 15. The computer-readable medium of claim 14, wherein the asynchronous actions are assigned a lower priority than synchronous actions, and wherein the synchronous actions include logging in the user. 10. The computer-readable medium of claim 9, wherein the multi-tenant cloud system accesses the on-premises active directory through a firewall. A multi-tenant cloud system for multiple user accounts, said system comprising:
one or more processors in communication with a client system that receives an authentication action from a user, the processor comprising:
Create an authentication target action,
Registering a cache listener to listen for target action responses in response to said authenticate target action;
initiating an authentication action for said user via a bridge with an on-premise Active Directory (AD);
wait for the cache callback,
A multi-tenant cloud system wherein, in said cache callback, it receives a target action response including a result of said authentication action. 18. The system of claim 17, wherein the request for authentication action is received at the multi-tenant cloud system. 19. The system of claim 18, wherein results of said authentication action are received from said on-premises AD. while waiting for the cache callback, polling for threads created for the authentication action;
18. The system of claim 17, wherein said polling continues until said cache callback or timeout.

Images