Multi-tenant identity and data security management cloud service

Mutual reference to related applications This application applies to US Provisional Patent Application No. 62 / 334,645 filed May 11, 2016, US Provisional Patent Application No. 62 / 371,336 filed August 5, 2016, August 17, 2016. US Provisional Patent Application No. 62 / 376,069, US Provisional Patent Application No. 62 / 395,463 filed September 16, 2016, US Provisional Patent Application No. 62 / 395,479 filed September 16, 2016, 2016 US Provisional Patent Application No. 62 / 395,501 filed on September 16, 2016, US Provisional Patent Application No. 62 / 434,501 filed on December 15, 2016, US Patent Application No. 15 / 450,512 filed on March 6, 2017. , US Patent Application No. 15 / 450,550 filed March 6, 2017, US Patent Application No. 15 / 469,718 filed March 27, 2017, and US Patent Application No. 15 filed April 12, 2017. Claim priority under / 485,532. The disclosures of each of the above applications are incorporated herein by reference.

A field 1 embodiment generally relates to identity management, especially identity management in cloud systems.

Background Information Generally, cloud-based applications (such as corporate public cloud applications, third parties) accessed by a variety of devices (eg desktop and mobile devices) and a variety of users (eg employees, partners, customers, etc.) The use of cloud applications, etc.) is increasing exponentially. Due to the versatility and accessibility of cloud-based applications, identity management and access security have become a central concern. Typical security issues in a cloud environment include unauthorized access, account hijacking, and malicious insiders. Therefore, secure access is required regardless of the type of device or user accessing the application, whether it is a cloud-based application or an application that exists anywhere.

<p> Overview One embodiment is a system that provides cloud-based identity and access management. The system receives a request from the client for an identity management service, authenticates the request, and accesses the microservice based on the request. The system determines client tenancy, user tenancy, and resource tenancy based on the request. The system retrieves the data needed to process the request from the determined tenancy. This data is retrieved by microservices using a connection pool that provides a connection to the database. The system then performs identity management services with the appropriate microservices responsible for processing the requests received.</p>

<figref num="1">It is a block diagram of an example of an embodiment that provides cloud-based identity management.</figref><figref num="2">It is a block diagram of an example of an embodiment that provides cloud-based identity management.</figref><figref num="3">It is a block diagram of an example of an embodiment that provides cloud-based identity management.</figref><figref num="4">It is a block diagram of an example of an embodiment that provides cloud-based identity management.</figref><figref num="5">It is a block diagram of an example of an embodiment that provides cloud-based identity management.</figref><figref num="6">It is a block diagram which provides the system view of a certain embodiment.</figref><figref num="6A">It is a block diagram which provides the functional view of a certain embodiment.</figref><figref num="7">It is a block diagram of the embodiment which realizes a cloud gate.</figref><figref num="8">An example of a system that realizes a plurality of tenancy in one embodiment is shown.</figref><figref num="9">It is a block diagram of the network view of a certain embodiment.</figref><figref num="10">It is a block diagram of the system architecture view of the single sign-on (SSO) function in one embodiment.</figref><figref num="11">It is a figure which shows the message sequence flow of the SSO function in one Embodiment.</figref><figref num="12">An example of a distributed data grid in one embodiment is shown.</figref><figref num="13">It is a flow diagram of the identity and access management function according to a certain embodiment.</figref><figref num="14">It is a flow diagram of the identity and access management function according to a certain embodiment.</figref><figref num="15">It is a flow diagram of the identity and access management function according to a certain embodiment.</figref><figref num="16">It is a flow diagram of the identity and access management function according to a certain embodiment.</figref>

Detailed Description The identity cloud service provided by the embodiment provides a microservices-based architecture, as well as multi-tenant identity and data security management and secure access to cloud-based applications. The embodiment supports secure access for hybrid cloud deployments (ie, cloud deployments that include a combination of public and private clouds). The embodiment protects applications and data both in the cloud and on-premises. Embodiments include web, mobile devices, and application programming. Supports multi-channel access via interface: "API"). The embodiment manages access for various users, such as customers, partners, and employees. The embodiment manages, controls, and audits both access through the cloud and on-premises access. The embodiments are integrated with new and existing applications and identities. The embodiment is laterally scalable.

One embodiment is a system that provides cloud-based multi-tenant identity and access management services by implementing a large number of microservices in a stateless middle tier environment. In one embodiment, each requested identity management service is divided into a real-time task and a near real-time task. Real-time tasks are processed by middle-tier microservices, while near-real-time tasks are offloaded to the message queue. The embodiment enhances the security model for accessing microservices by implementing access tokens 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 an organization to quickly develop fast, reliable and secure services for its new business initiative. In one embodiment, the identity cloud service provides a number of core services. Each core service solves the unique challenges faced by many companies. In one embodiment, the Identity Cloud service provides a user, for example, when first onboarding / importing a user, when importing a group with a user member, when creating / updating / disabling / enabling / deleting a user. Supports administrators when assigning / unassigning users to a group, creating / updating / deleting groups, resetting passwords, managing policies, sending activations, and so on.

<u style="single">Unified access security</u> One 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 there can be an increased risk if there is a security contradiction between these two environments. For example, in the event of such a conflict, the salesperson will have access to their Customer Relationship Management (CRM) account, even after leaving and moving to a competitor. May continue. Therefore, the embodiment extends the security controls provided in the on-premises environment to the cloud environment. For example, if a person leaves the company, the embodiment ensures that the account is disabled both on-premises and in the cloud.

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

One embodiment also manages access for various users, such as customers, partners, and employees. In general, applications and / or data may be accessed not only by employees, but also by customers or third parties. Many known systems take security measures when employees are onboard, as these security measures are usually not at the same level as security measures when granting access to customers, third parties, partners, etc. As a result, security can be compromised by someone who is not properly managed. However, embodiments ensure that adequate security measures are provided for access by each type of user as well as employees.

<u style="single">Identity cloud service</u> The embodiment provides a multi-tenant, cloud-scale IAM platform, Identity Cloud Service (IDCS). IDCS provides authentication, authorization, auditing, and federation. IDCS manages access to custom applications and services running on public clouds and on-premises systems. In an alternative or alternative embodiment, 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.

The embodiment is based on a multi-tenant microservice architecture for designing, building, and delivering cloud-scale software services. Multi-tenancy means that there is a physical realization of a certain service, and this service is a service that safely supports multiple customers who have purchased the service. A service requests a service (for example, retrieving specified information or performing a set of actions) to a software feature or set of software features that can be reused by different clients for different purposes. It is a combination of policies governing its use (based on the client's identity). In one embodiment, a service is a mechanism that allows access to one or more features, which access is provided using a given interface and is performed in accordance with the constraints and policies specified in the service description. NS.

In one embodiment, the microservice is an independently deployable service. In one embodiment, the term microservice is intended for a software architecture design pattern in which complex applications consist of small independent processes that communicate with each other using language-independent APIs. In one embodiment, microservices are small, finely separated services, and each service can focus on performing small tasks. In one embodiment, the microservices architecture style is a technique for developing a single application as a small set of services, where each service runs in its own process and communicates with a lightweight mechanism (eg, an HTTP resource API). In one embodiment, microservices are easier to replace when compared to monolithic services that perform all of the same functions or many of the same functions. In addition, each microservice can be updated without adversely affecting other microservices. In contrast, updating part of a monolithic service can have unwanted or unintended adverse effects on other parts of the monolithic service. In one embodiment, microservices can be beneficially organized around their function. In one embodiment, the startup time of each microservice in the collection of microservices is much shorter than the startup time of a single application running all the services of these microservices together. In some embodiments, the startup time for each such microservice is about 1 second or less, whereas the startup time for such a single application is about 1 minute, minutes, or longer. In some cases.

In one embodiment, a microservice architecture is a service oriented architecture for building a flexible, independently deployable software system. It is a method of specialization (that is, separation of tasks in the system) and realization of architecture (SOA)). Services in a microservice architecture are the processes of communicating with each other over a network to achieve their goals. In one embodiment, these services use technology-independent protocols. In one embodiment, the service uses a protocol that is small and lightweight. In one embodiment, the services can be deployed independently. By distributing the functionality of the system into different smaller services, the cohesiveness of the system is improved and the coupling of the system is reduced. This facilitates system changes and adds functionality and quality to the system at any given time. It also allows the architecture of individual services to emerge through constant refactoring, thus reducing the need for large-scale pre-design and allowing early and continuous release of software. become.

In one embodiment, in a microservices architecture, applications are developed as a collection of services, where each service runs its own process and communicates using a lightweight protocol (eg, a unique API for each microservice). In a microservices architecture, breaking down a piece of software into individual services / functions can be done at different levels of granularity depending on the services provided. Services are runtime components / processes. Each microservice is a built-in 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 traditionally microservices expose (such as a traditional Hypertext Transfer Protocol (HTTP) port) and is another within the same service. A standard communication channel that allows modules / microservices to talk to it. Microservices or other built-in functional modules can be collectively referred to as "services".

The embodiment provides a multi-tenant identity management service. The embodiment is based on an open standard that guarantees easy integration with various applications and provides IAM functionality through standards-based services.

The embodiment manages the life cycle of a user identity that involves determining and enforcing what the identity can access, who can grant such access, who can manage such access, and so on. The embodiment runs an identity management workload in the cloud and supports security features of applications that do not necessarily exist in this cloud. The identity management services provided by these embodiments may be purchased from the cloud. For example, a company may purchase such services from the cloud to control its employees' access to the company's applications.

The embodiments provide system security, massive scalability, end-user usability, and application interoperability. The embodiment deals with the growth of the cloud and the use of identity services by customers. The microservice-based foundation deals with lateral scalability conditions, while the fine-tuning of services deals with functional conditions. To achieve both of these goals, the business logic is decomposed (as much as possible) to ultimately achieve consistent statelessness, while most of the behavioral logic that is not subject to real-time processing is delivered. By being offloaded to a highly scalable asynchronous event management system with guaranteed processing, it shifts to near real time. The embodiment is completely multi-tenant from the web layer to the data for cost efficiency and ease of system management.

Embodiments include industry standards (eg, OpenID Connect, OAuth2, Security Assertion Markup Language 2 (SAML2), cross-domain identity management to facilitate integration with a variety of applications. System for Cross-domain Identity Management (SCIM), Representational State Transfer: "REST") etc.). One embodiment provides a cloud-scale API platform that enables laterally scalable microservices for elastic scalability. This embodiment strengthens the cloud principle and provides a multi-tenant architecture in which data is separated for each tenant. The present embodiment further provides per-tenant customization via tenant self-service. This embodiment can be used via API for on-demand integration with other identity services to provide a series of feature releases.

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

Therefore, one embodiment is a system that provides cloud-based multi-tenant identity and access management services by implementing a large number of microservices in the stateless middle tier. In one embodiment, each requested identity management service is divided into a real-time task and a near real-time task. Real-time tasks are processed by middle-tier microservices, while near-real-time tasks are offloaded to the message queue. The embodiment implements a token that is consumed by the routing layer and implements a security model for accessing microservices. Therefore, the embodiment provides a cloud-scale IAM platform based on a multi-tenant microservice architecture.

In general, well-known systems provide sileded access to applications provided by various environments, such as corporate 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, heterogeneous 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 that provides a unified identity platform 126 for onboarding users and applications. This embodiment provides a seamless user experience across a variety of applications such as corporate cloud application 102, partner cloud application 104, third party cloud application 110, and customer application 112. Applications 102, 104, 110, 112 may be accessed through different channels, for example, mobile phone user 108 may access via mobile phone 106 and desktop computer user 116 may access via browser 114. .. A web browser (commonly referred to as a browser) is a software application for retrieving, presenting, and traversing information resources on the worldwide web. Examples of web browsers include Mozilla® Firefox®, Google Chrome®, Microsoft® Internet Explorer®, and Apple® Safari®. Be done.

IDCS118 provides a unified view 124 of the user's application, unified secure credentials across devices and applications (via the identity platform 126), and a unified management method (via the management console 122). The IDCS service may be obtained by calling IDCS API 142. Such services include, for example, Login / SSO Service 128 (eg OpenID Connect), Coordination Service 130 (eg SAML), Token Service 132 (eg OAuth), Directory Service 134 (eg SCIM), Provisioning Service 136 (eg SCIM or). Any Transport over Multiprotocol (AToM), Event Service 138 (eg REST), and role-based access control: "RBAC") Service 140 (eg SCIM) can be included. IDCS118 may also provide reports and dashboards 120 regarding the services provided.

<u style="single">Integrated tool</u> It is common for large companies to have IAM systems in place for secure access to their on-premises applications. Business methods are usually matured and standardized around in-house IAM systems such as Oracle's "Oracle IAM Suite". Even small to medium sized organizations are typically designed around managing their business processes through simple directory solutions 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 IDCS202 in a cloud environment 208 that provides integration of on-premises 206 with AD204. The present embodiment includes various applications / services in cloud 208 such as cloud service 210, cloud application 212, partner application 214, and customer application 216, as well as on-premises and third-party applications such as on-premises application 218. Provides a seamless user experience across applications. Cloud application 212 includes, for example, Human Capital Management (HCM), CRM, talent acquisition (eg Oracle's Oracle Taleo cloud service), configuration, pricing, and quote (Configure Price and Quote. CPQ ") etc. can be included. The cloud service 210 is, for example, a platform as a. Service: "PaaS"), Java®, databases, business intelligence ("BI"), documents, etc. may be included.

Applications 210, 212, 214, 216, 218 may be accessed through different channels, for example, mobile phone user 220 via mobile phone 222 and desktop computer user 224 via browser 226. May be good. In this embodiment, the identity is automatically synchronized from the on-premises AD data to the cloud data via the SCIM identity bus 234 between the cloud 208 and the enterprise 206. The present embodiment further provides a SAML bus 228 for linking authentication (using, for example, password 232) from the cloud 208 to the on-premises AD204.

In general, an identity bus is a service bus for identity-related services. The service bus provides a platform for transmitting messages from one system to another. This is a controlled mechanism for exchanging information between trusted systems, for example in a service oriented architecture (SOA). The identity bus is a logical bus built according to standard HTTP-based mechanisms such as web services and web server proxies. Communication on the identity bus may be performed according to each protocol (eg SCIM, SAML, OpenID Connect, etc.). For example, the SAML bus is an HTTP-based connection between two systems that conveys 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-premises 206 with the customer's AD204. The identity bridge 230 listens for users and groups (eg, groups of users) of the organizational unit (OU) selected by the customer and synchronizes these users with the cloud 208. In one embodiment, the user password 232 is not synced to cloud 208. Customers can manage user application access by mapping a group of IDCS users to cloud applications managed by IDCS208. Whenever a user's group membership changes on-premises 206, the corresponding cloud application access changes automatically.

For example, an employee who has moved from the engineering 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 AD204, changes in access to cloud applications will be realized in near real time. Similarly, access to cloud applications managed by IDCS208 by users leaving the company will be revoked. For full automation, customers set up an SSO between the on-premises AD204 and IDCS208, for example through an AD integration service (AD / FS or some other mechanism to achieve SAML integration), and the end user A single corporate password 332 may be used to access cloud applications 210, 212, 214, 216 and on-premises application 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, the IDCS202 provides integration with an on-premises IDM304 such as the Oracle IDM. Oracle IDM304 is Oracle's software suite for providing IAM functionality. The present embodiment provides a seamless user experience across all applications, including on-premises and third-party applications. The present embodiment provisions a user identity from on-premises IDM 304 to IDCS 208 via the SCIM identity bus 234 between Cloud 202 and Enterprise 206. The present embodiment further provides a SAML bus 228 (or OpenID Connect bus) for linking authentication 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 (Oracle Access) Manager: "OAM") Cooperation module 306 is realized as an extension module of Oracle IDM 304. A connector is a module that has a physical awareness of how to talk to the system. OIM is an application configured to manage user identities (for example, managing user accounts on different systems based on what the user should and should not have access to). OAM is a security application that provides access control features such as web SSO, identity context, authentication and authorization, policy management, testing, logging, and auditing. OAM has built-in support for SAML. If the user has an IDCS202 account, OIM Connector 302 and OAM Linkage 306 can be used with Oracle IDM304 to create / delete this account and control 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. 2 and 3. .. However, in the embodiment of FIG. 4, IDCS202 provides the ability to extend cloud identity to on-premises application 218. The present embodiment provides a seamless view of identity across all applications, including on-premises and third-party applications. In the embodiment of FIG. 4, the SCIM identity bus 234 is used to synchronize the data in IDCS202 with on-premises LDAP data called "cloud cache" 402. Cloud cache 402 is disclosed in more detail below.

In general, applications configured to communicate based on LDAP require an LDAP connection. Such applications may not build LDAP connections using URLs (unlike "www.google.com" which connects to Google®, for example). Because LDAP must be on the local network. In the embodiment of FIG. 4, the LDAP-based application 218 connects to the cloud cache 402, the cloud cache 402 connects to the IDCS 202, and then pulls the requested data from the IDCS 202. Communication between IDCS202 and cloud cache 402 may be implemented according to the SCIM protocol. For example, the cloud cache 402 may use the SCIM bus 234 to send a SCIM request to the IDCS 202 and receive the corresponding data.

In general, the full realization of an application is to build a consumer portal, run marketing campaigns against external user groups, support web and mobile channels, and authenticate users, sessions, users. Includes handling profiles, user groups, application roles, password policies, self-service / registration, social integration, identity integration, and more. In general, application developers are not identity / security experts. For this reason, 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. 2-4. However, in the embodiment of FIG. 5, IDCS202 provides on-demand and secure identity management. This embodiment provides on-demand integration with IDCS202's identity services (based on standards such as OpenID Connect, OAuth2, SAML2, or SCIM). Application 505 (which may be on-premises, in a public cloud, or in a private cloud) may call IDCS202's identity service API504. Services provided by IDCS202 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, the SCIM identity bus 234 is used to synchronize the data in IDCS202 with the data in the on-premises LDAP cloud cache 402. In addition, application 505 may use "CloudGate" 502 running on a web server / proxy (eg NGINX, Apache, etc.) to obtain user web SSO and REST API security from IDCS202. Cloudgate 502 secures access to multi-tenant IDCS microservices by providing a valid access token for the client application and / or ensuring that the user successfully authenticates to build an SSO session. It is a component to do. Cloudgate 502 is further disclosed below. Cloudgate 502 (a practice 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, the 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 their on-premises identities to work together. Therefore, the embodiment enables investment savings and expansion by leveraging open standards to achieve integration with existing SSOs (eg, until the final full transition to an identity cloud service approach). ).

One embodiment may provide the following functions. · Keep track of already authorized user accounts, ownership, access, and permissions by maintaining an identity store. · Integration with workflow simplifies the various approvals required to access an application (eg administration, IT, human resources, law, and compliance). · Provision SaaS user accounts for selective devices (eg mobile and personal computers (PC)). Access to the user portal involves a number of private and public cloud resources. Facilitate regular management proof for compliance with rules and current responsibilities.

In addition to these features, the embodiments also include: -Provisioning cloud accounts for managing account lifecycles in cloud applications, -Integrating more robust multifactor authentication ("MFA"), -Extended mobile May provide security features and dynamic authentication options.

One embodiment provides adaptive certification and MFA. In general, password and verification questions have been considered inadequate and vulnerable to common attacks such as phishing. Most modern enterprises are looking at some form of MFA to reduce risk. However, in order for the solution to be successfully deployed, the solution needs to be easily provisioned, maintained, and understood by the end user. This is because end users usually resist whatever interferes with their digital experience. Enterprises securely embrace Bring Your Own Device (BYOD), social identity, remote users, customers, and subscribers while making MFA a nearly transparent component of a seamless user access experience. I'm looking for a way. OAuth and OpenID in MFA deployment Industrial standards such as Connect are essential to ensure the integration of existing multi-factor solutions and the introduction of newer adaptive certification technologies. Therefore, the embodiment proves the identity after the start of a user session by defining dynamic (or adaptive) authentication as an assessment of available information (ie, IP address, location, time, and biometrics). With the integration of appropriate standards (eg, open authentication (OATH) and fast identity online (FIDO)) and an extensible identity management framework, the embodiments are end-to-end. Provides an MFA solution that can be easily adopted, upgraded, and integrated within an IT organization as part of a two-end secure IAM deployment. When considering MFA and adaptation policies, the organization should have a hybrid IDCS and on-premises IAM environment. Must implement consistent policies across on-premises and cloud resources that require integration between systems.

One embodiment provides user provisioning and certification. In general, the basic function of an IAM solution is to enable and support the entire user provisioning life cycle. This gives the user appropriate application access for their identity and role within the organization (for example, the user's role or the tasks or applications used within that role over time. Includes (because it changes) and the quick user deprovisioning needed when a user leaves the organization. This is important not only to meet various compliance requirements, but also because improper insider access is a major source of security breaches and attacks. Automated user provisioning capabilities in identity cloud solutions can be important not only in their own rights, but also as part of hybrid IAM solutions, so IDCS provisioning is shrinking and expanding for enterprises. It can offer greater flexibility than on-premises solutions during migration when merging or attempting to integrate existing systems with an IaaS / PaaS / SaaS environment. The IDCS approach can save time and effort in a one-time upgrade and ensure proper integration of the required departments, divisions and systems. Enterprises often have a secret need to scale this technology, and the rapid provision of scalable IDCS capabilities throughout the enterprise can benefit in terms of flexibility, cost, and control.

In general, employees are given additional power over the years as their occupation changes (ie, "creeping power"). Loosely regulated companies generally lack a "verification" process. This process periodically audits the privileges of employees in a company (for example, access to networks, servers, applications, and data) to creep permissions that cause over-privileged accounts. Need an administrator to stop or slow down. Therefore, one embodiment may provide a proof process that is carried out on a regular basis (at least once a year). In addition, the need for these tools and services will increase exponentially with mergers and acquisitions. The user resides in the SaaS system, resides on-premises, spans different departments, and / or is deprovisioned or reassigned. Moving to the cloud can further confuse this situation, and things can escalate rapidly beyond existing proof methods that are often manually managed. Therefore, one embodiment automates these functions and applies advanced analysis to user profiles, access history, provisioning / deprovisioning, and subdivided rights.

One embodiment provides identity analysis. In general, the ability to integrate identity analysis with the IAM engine for comprehensive proof and proof can be essential to secure an organization's risk profile. Properly deployed identity analysis may require enforcement of the entire internal policy. Identity analysis, which provides a unified, single management view across the cloud and on-premises, is highly needed and reduces risk in a governance, risk, and compliance (GRC) enterprise environment. It can help provide a closed-loop process for meeting compliance rules. Therefore, one embodiment provides identity analysis. Identity analysis meets specific industrial conditions and government regulations with easy client customization for the reporting and analysis required by managers, executives, and auditors.

One embodiment improves the end-user experience and efficiency by providing self-service and access request capabilities, while reducing the cost of help desk calls. In general, many companies deploy on-premises self-service access requests for their employees, but many do not properly extend these systems outside the formal corporate walls. A positive digital customer experience, outside the scope of employee use, increases business credibility and ultimately contributes to increased revenue, allowing companies to not only reduce customer help desk calls, but also reduce customer satisfaction. Increase. Accordingly, one embodiment provides an identity cloud service environment that is based on open standards and, if desired, seamlessly integrates with existing access control software and MFA mechanisms. The SaaS delivery model eliminates the 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, are insiders with access credentials of superusers such as system administrators, executives, HR executives, contractors and system integrators. Vulnerable to unauthorized use of privileged accounts by. In addition, external threats generally first compromise low-level user accounts and eventually reach and take advantage of privileged user access controls within the corporate system. Therefore, one embodiment provides PAM to prevent such unauthorized insiders from using the account. The main component of the PAM solution is password vault It is a vault), which can be supplied in various ways. For example, it can be delivered in different ways as software installed on a corporate server, also as a virtual appliance on a corporate server, as a packaged hardware / software appliance, or as part of a cloud service. PAM functionality is similar to the physical safe place used to store passwords that are held within the envelope and regularly changed in the manifest for sign-in and sign-out. One embodiment allows for password checkout, as well as setting time limits, forcing time limits, automatic checkout tracking, and reporting on all activities. One embodiment provides a method of directly connecting to the requested resource without the user knowing the password. This feature also paves the way for session management and other functional methods.

In general, most cloud services utilize APIs and management interfaces. These give intruders the opportunity to bypass security. Therefore, one embodiment fills in these deficiencies in the implementation of PAM. This is because the move to the cloud poses new challenges for PAM. Many small to medium sized businesses now have their own SaaS systems (eg Office) 365), but larger companies are increasingly having individual business units that increase the turnover of their SaaS and IaaS services. These customers have little experience dealing with this responsibility, although PAM functionality is either included in the identity cloud service solution or obtained from its IaaS / PaaS provider. In addition, in some cases, many different geographically dispersed business units seek to separate management responsibilities for the same SaaS application. Therefore, in one embodiment, a customer in this situation links an existing PAM into the overall identity framework of an identity cloud service, demanding business needs for greater security and compliance. It makes it possible to make sure that it is adjusted according to the cloud load conditions.

<u style="single">API platform</u> The API platform provided by the embodiment exposes a collection of features as a service. APIs are aggregated into microservices, and each microservice provides one or more functions by exposing one or more APIs. That is, each microservice can expose different types of APIs. In one embodiment, each microservice communicates only through its API. In one embodiment, each API may be a microservice. In one embodiment, multiple APIs are aggregated into one service based on the target functionality provided by this service (eg OAuth, SAML, Admin, etc.). As a result, similar APIs are not exposed as separate runtime processes. The API is made available to service customers to use the services provided by IDCS.

Generally, in the IDCS web environment, a URL contains three parts: a host, a microservice, and a 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, API for requesting tokens: "host / oauth / v1 / token", API for authorizing users: " host / oauth / v1 / authorize "and so on. That is, the URL realizes a micro service, and the resource part of the URL realizes an API. Therefore, multiple APIs are aggregated under the same microservice, and each request executes a call to the API that identifies the identity management service (for example, requesting a token, authenticating a user, etc.) and the identity management service. Includes microservices configured to do so (eg OAuth).

In one embodiment, the host portion of the URL identifies the tenant (eg https://tenant3.identity.oraclecloud.com:/oauth/v1/token). In one embodiment, the host portion of the URL identifies the tenancy of the resource associated with the request.

Configuring an application that integrates with an external service that has the required endpoints and keeping the configuration up to date is generally a challenge. To overcome this challenge, the embodiment exposes the public discovery API to a well-known location, from which the application can discover the information about the IDCS needed to consume the ADCS API. can. In one embodiment, two discovery documents are supported, including IDCS, SAML, SCIM, OAuth, and OpenID Connect configurations with IDCS configurations (eg, &lt;IDCS-URL&gt; /. Well-known/idcs-configuration). ) And the industrial standard OpenID Connect configuration (for example, &lt;IDCS-URL&gt; /. Well-known/openid-configuration). The application can retrieve the discovery literature by consisting of a single IDCS URL.

FIG. 6 is a block unit that provides a system view 600 of IDCS in one embodiment. In FIG. 6, any of the various applications / services 602 can use the IDCS service by making an HTTP call to the IDCS API. Examples of such applications / services 602 are built to run on specific operating systems such as web applications, native applications (eg Windows® applications, iOS® applications, Android® applications, etc. Applications), web services, customer applications, partner applications, or software as a service (SaaS), PaaS, and infrastructure as a service (IaaS), etc. , A service provided by the public cloud.

In one embodiment, the HTTP request for application / service 602 requesting the IDCS service is an Oracle public cloud BIG-IP appliance 604 and IDCS BIG-IP appliance 606 (or similar technology such as a load balancer, or appropriate security rules. It goes through a cloud load balancer (a component called Cloud Load Balancer as a Service (LBaaS)) as a service that realizes and protects traffic. However, this request may be received in any way. On the IDCS BIG-IP Appliance 606 (or similar technology, such as a load balancer or 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 onboard in the cloud, or new service instances purchased by the customer.

This HTTP request is then received by IDCS Web Routing Layer 610. This routing layer implements a security gate (ie, a cloud gate) and provides service routing and microservice registration and discovery 612. Depending on the service requested, HTTP requests are forwarded to the IDCS microservice at IDCS Intermediate Layer 614. The IDCS microservice handles external and internal HTTP requests. IDCS microservices enable platform and infrastructure services. IDCS Platform Services is a separately deployed Java-based runtime service that enables IDCS businesses. IDCS Infrastructure Services is a separately deployed runtime service that provides infrastructure support for IDCS. IDCS also includes an infrastructure library, which is common code packaged as a shared library used by the IDCS service, and a shared library. Infrastructure services and libraries provide the support features that platform services require to achieve their capabilities.

<u style="single">Platform service</u> In one embodiment, IDCS supports standard authentication protocols, so IDCS microservices include OpenID Connect, OAuth, SAML2, System for Cross-domain Identity Management ++ (SCIM ++), etc. Includes platform services.

The OpenID Connect platform service provides a standard OpenID Connect login / logout flow. Interactive web-based and native applications require user authentication by driving a standard browser-based OpenID Connect flow and convey the user's authenticated identity in JavaScript Object Notation (JavaScript Object Notation). Receives a standard identity token that is a "JSON") Web Token (Web Token "JWT"). Internally, the runtime authentication model is stateless and hosts the user's authentication / session state with an HTTP cookie (including a JWT identity token). Maintain in the form of. OpenID Authentication interactions initiated via the Connect protocol are delegated to a trusted SSO service that implements user login / logout ceremonies for local and collaborative logins. Further details of this function are disclosed below with reference to FIGS. 10 and 11. In one embodiment, the OpenID Connect function is implemented, for example, according to the OpenID Foundation standard.

The OAuth2 platform service provides a token authorization service. It provides a rich API infrastructure for creating and validating access tokens that convey user rights and making API calls. This supports a range of useful token grant types and allows customers to securely connect clients to their services. It implements the 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, IDCS as OIDC RP is social OIDC By integrating with OPs (eg Facebook®, Google®, etc.), customers will be able to have policy-based access to their applications with social identities. In one embodiment, the OAuth function is implemented according to, for example, the Internet Engineering Task Force (IETF), Request for Comments (RFC) 6749.

The SAML2 platform service provides an identity integration service. This allows customers to set up partnership agreements with their partners based on a SAML identity provider (IDP) and SAML service provider (SP) relationship model. In one embodiment, the SAML2 platform service implements a standard SAML2 browser post-login and log-out profile. In one embodiment, the SAML function is implemented according to, for example, IETF, RFC7522.

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, RFC 7642, 7643, 7644. be. The SCIM ++ platform service provides an identity management service that allows customers to access IDCS's IDP features. The management service exposes a set of stateless REST interfaces (ie APIs) that cover 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 manages IDCS resources (eg users, roles, password policies, applications, SAML / OIDC identity providers, SAML service providers, keys, certifications, notification templates, etc.) to enable. Management services enhance and extend the SCIM standard to create, read, update, delete, and query (CRUDQ) behavior for all IDCS resources. Implement a schema-based REST API for. In addition, all IDCS internal resources used to manage and configure IDCS itself are exposed as SCIM-based REST APIs. Access to Identity Store 618 is separated into the SCIM ++ API.

In one embodiment, for example, the SCIM standard is implemented to manage user and group resources specified by the SCIM standard, whereas SCIM ++ uses the language specified by the SCIM standard for yet another IDCS. Configured to support internal resources (eg password policies, roles, settings, etc.).

The management service supports SCIM2.0 standard endpoints with standard SCIM2.0 core schema and, if necessary, schema extensions. In addition, the management service manages other IDC resources, such as users, groups, applications, settings, etc., by supporting some SCIM 2.0 compliant endpoint extensions. The management service also does not perform CRUDQ operations, but instead provides functional services, such as "UserPasswordGenerator", "UserPasswordValidator", etc., for remote procedure call-style (RPC style) REST interfaces. Supports sets.

The IDCS management API uses the OAuth2 protocol for authentication and authorization. IDCS supports common OAuth2 scenarios such as scenarios for web servers, mobile, and JavaScript applications. Access to the IDCS API is protected by an access token. In order to access the IDCS management API, the application must be registered as an OAuth2 client or as an IDCS application (in this case the OAuth2 client is created automatically) through the IDCS management console and also in the desired IDCS management role. Need to be given. When making an IDCS management API call, the application first requests an access token from the IDCS OAuth2 service. After obtaining this token, the application sends the access token, including the HTTP authorization header. The application can use the IDCS management REST API directly or the IDCS Java client API library.

<u style="single">Infrastructure services</u> IDCS Infrastructure Services supports the functionality of IDCS Platform Services. These runtime services include event processing services (for processing user notifications, application submissions, and audits of databases asynchronously) and lengths (for scheduling and executing jobs, for example, without user intervention). Generate job scheduler services (for immediate execution or set time execution), cache management services, storage management services (for integration with public cloud storage services), and reports and dashboards. Report services (for managing internal user authentication and SSO), SSO services (for managing internal user authentication and SSO), and different types of user interfaces (user) interface: Includes a user interface (UI) service (for hosting clients) and a service manager service. The service manager is the internal interface between the Oracle Public Cloud and IDCS. The service manager manages the 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 they are ready to buy something, the cloud sends a request to IDCS to ask them to create a tenant. In this case, the service manager implements the cloud-specific behavior that the cloud expects IDCS to support.

The IDCS microservice may call another IDCS microservice through the network interface (ie HTTP request).

In one embodiment, IDCS may also provide a schema service (or persistence service) that allows the database schema to be used. The schema service allows IDCS to delegate responsibility for managing the database schema. Therefore, IDCS users do not need to manage the database. This is because there is an IDCS service that provides this functionality. For example, a user may use a database to parse a schema for each tenant, and another database so that the schema service does not have to manage the database itself when space is exhausted in the database. And manage the function of expanding the above space.

IDCS also includes a data store, which is the data repository required / generated by IDCS. It has an identity store 618 (which stores users, groups, etc.), a global database (which stores the configuration data that IDCS uses to configure itself), a global database 620 (separates the schema for each tenant and customer data for each customer). Includes operational schema 622 (which stores audit data), audit schema 624 (which stores audit data), caching cluster 626 (which speeds up execution by storing cached objects), and so on. All internal and external IDCS consumers are integrated with Identity Services according to standards-based protocols. This allows you to use the Domain name system (DNS) to decide where to route requests, separating application consumption from understanding the internal realization of identity services. ..

<u style="single">Real-time and near-real-time tasks</u> IDCS separates the tasks of the requested service into synchronous real-time tasks and asynchronous near-real-time tasks. Real-time tasks include only the operations that the user needs to proceed. In one embodiment, a real-time task is a task that is executed with minimal delay, and a near real-time task is a task that is executed in the background without the user waiting. In one embodiment, a real-time task is a task that is performed with virtually no delay or with very little delay, and is a task that appears to the user to be performed almost instantaneously.

Real-time tasks perform key business functions of a particular identity service. For example, when requesting a login service, the application sends a message to authenticate the user's credentials and retrieve a session cookie for it. What the user experiences is logging into the system. However, for user login, some other tasks will be performed, such as verifying who the user is, auditing, sending notifications, and so on. Therefore, credential validation is a task that is performed in real time, as if a user were given an HTTP cookie to start a session, but notifications (eg sending an email to notify them of account creation), auditing. Tasks related to (eg tracking / recording) 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 arithmetic logic / events that do not necessarily undergo real-time processing are placed in message queue 628. Offloaded. Message Queue 628 supports the highly scalable asynchronous event management system 630 with guaranteed delivery and processing. Thus, certain behaviors allow IDCS to provide high-level services to customers by reducing response time latency by being pushed from the front end to the back end. For example, the login process can include verifying credentials, submitting log reports, updating the last login time, etc., but these tasks should be offloaded to the message queue and performed in near real time instead of real time. Can be done.

In one example, the system may need to register or create a new user. The system calls the IDCS SCIM API to create a user. As a final result, when a user is created in Identity Store 618, he gets a notification email containing a link to reset his password. When IDCS receives a request to register or create a new user, the corresponding microservice looks at the configuration data in the operational database (located within global database 620 in Figure 6) and "user-created". Is marked in the "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 was created successfully, but the actual sending of the notification email is postponed and pushed to the backend. To do so, the microservice uses messaging API 616 to put this message in the store queue 628.

To get out of queue 628, the messaging microservice, which is an infrastructure microservice, runs continuously in the background, looking for events in queue 628 and scanning queue 628. Events in queue 628 are processed by event subscribers 630 for audits, user notifications, application submissions, data analysis, and more. Depending on the task indicated by the event, the event subscriber 630 may communicate with, for example, the audit scheme 624, the user notification service 634, the identity event subscriber 632, and so on. For example, if a messaging microservice finds a "user-created" event in queue 628, it executes the corresponding notification logic and sends the corresponding email to the user.

In one embodiment, queue 628 queues operational events published by microservice 614 and resource events published by API 616, which manages 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 enables elastic cache cluster 626, which grows as the number of customers supported by IDCS increases. The cache cluster 626 may be implemented with a distributed data grid, which is disclosed in more detail below. In one embodiment, the write-only resource bypasses 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's Oracle public cloud.

In one embodiment, the user may be created using IDCS. For example, client application 602 may issue a REST API call to create a user. The management service (614 platform services) delegates this call to the user manager (614 infrastructure libraries / services). Then, the user manager creates this user in the ID store stripe for a specific tenant in the ID store 618. For User Create Success, the user manager inspects the table in inspection schema 624 by inspecting 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, the IDCS may be used to give the user a role, and as a result the user may provision the action. For example, client application 602 may issue a REST API call to grant a role to a user. The management service (614 platform services) may delegate this call to the role manager (614 infrastructure libraries / services). This role manager grants a role in the ID store stripe for a specific tenant in the ID store 618. "Role Grant In the case of "Success)", the role manager audits the operation on the audit table in the audit schema 624 and publishes "identity.user.role.grant.success" to the message queue 628. Identity subscriber 632 picks up this event and evaluates the provisioning grant policy. If there is an active application grant for the granted role, the provisioning subscriber will perform some validation, initiate account creation, call out the target system, create an account on the target system, and successfully create the account. Mark it as done. As a result of each of these features, support such as "prov.account.create.initiate", "prov.target.create.initiate", "prov.target.create.success" or "prov.account.create.success" Events can be published. These events may have their own business metrics that sum the number of accounts created on 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 user login using one of the supported authentication flows. IDCS authenticates the user and, if successful, audits operations on the audit table in audit schema 624. If unsuccessful, IDCS audits failures in audit schema 624 and publishes the "login.user.login.failure" event in message queue 628. The logged-in subscriber picks up this event, updates its metrics for the user, and determines if additional analysis of the user's access history needs to be performed.

Therefore, by implementing the "reversal of control" function (for example, by changing the flow of execution, the execution of an operation at a later point in time is scheduled so that the operation is under the control of another system). , Embodiments dynamically add other event queues and subscribers to test new features for smaller user samples before deploying to a wider user base, or for specific internal or external customers. Can handle specific events for.

<u style="single">Stateless function</u> IDCS microservices are stateless. This means that the microservice itself does not hold state. "State" refers to the data that an application uses to perform its function. IDCS provides multi-tenant functionality by persisting all states into a specific tenant repository within the IDCS data tier. The middle layer (ie, the code that processes the request) does not have the data stored in the same location as the application code. Therefore, IDCS is highly scalable in both the horizontal and vertical directions.

Vertical scaling (or scaling up / down) means adding (or removing) resources to one node in the system, adding CPU or memory to one computer. Is generally accompanied by. Vertical scalability allows applications to scale up to the limits of their hardware. Lateral 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. .. Lateral scalability allows applications to scale almost indefinitely and is constrained only by the amount of bandwidth provided by the network.

The stateless middle tier of IDCS makes it laterally scalable with the addition of more CPUs, and the IDCS component that performs the work of the application has the specified physical infrastructure on which the particular application is running. You don't have to have it. The stateless middle tier of IDCS makes IDCS highly available, even when providing identity services to a large number of customers / tenants. Each path through an IDCS application / service concentrates exclusively on CPU usage to execute application transactions, but does not use hardware to store data. Scaling is achieved by adding more slices while the application is running, while the data for the transaction is stored in the persistence layer where more copies can be added as needed.

The IDCS web layer, middle layer, and data layer can be scaled independently and separately. By scaling the web layer, you can handle more HTTP requests. By scaling the middle layer, more service functions can be supported. By scaling the data layer, more tenants can be supported.

<u style="single">IDCS feature view</u> FIG. 6A is an example 600b of a block diagram of the IDCS functional view in one embodiment. Block In Figure 600b, the IDCS feature stack includes services, shared libraries, and datastores. Services include IDCS Platform Service 640b, IDCS Premium Service 650b, and IDCS Infrastructure Service 662b. In one embodiment, the IDCS Platform Service 640b and the IDCS Premium Service 650b are separately deployed Java-based runtime services that enable IDCS's business. IDCS Infrastructure Service 662b is a separately deployed runtime service that provides infrastructure support for IDCS. The shared library includes the IDCS infrastructure library 680b, which is a common code packaged as a shared library used by the IDCS service, and the shared library. The data store is the data repository required / generated by IDCS, identity store 698b, global configuration 700b, message store 702b, global tenant 704b, personalization settings 706b, resource 708b, user temporary data 710b, system temporary data 712b. , Includes per-tenant schema (managed ExaData) 714b, operational store (not shown), caching store (not shown), etc.

In one embodiment, the IDCS platform service 640b includes, for example, the OpenID Connect service 642b, the OAuth2 service 644b, the SAML2 service 646b, and the SCIM ++ service 648b. In one embodiment, IDCS premium services include, for example, cloud SSO and governance 652b, corporate governance 654b, AuthN broker 656b, federated broker 658b, and private account management 660b.

The IDCS Infrastructure Service 662b and IDCS Infrastructure Library 680b provide support for the features that the IDCS Platform Service 640b needs to perform its job. In one embodiment, the IDCS Infrastructure Services 662b includes Job Scheduler 664b, UI666b, SSO668b, Report 670b, Cache 672b, Storage 674b, Service Manager 676b (Public Cloud Control), and Event Processor 678b (User Notifications, Application Submissions, Audits). , Data analysis). In one embodiment, the IDCS infrastructure library 680b includes a data manager API682b, an event API684b, a storage API686b, an authentication API688b, an authorization API690b, a cookie API692b, a key API694b, and a credential API696b. In one embodiment, the cloud computing service 602b (internal Nimbula) supports the functionality of the IDCS Infrastructure Service 662b and the IDCS Infrastructure Library 680b.

In one embodiment, IDCS provides a variety of UI602b for consumers of IDCS services, such as customer end user UI604b, customer management UI606b, DevOps management UI608b, and login UI610b. In one embodiment, IDCS enables integration 612b and firmware integration 620b of applications (eg customer application 614b, partner application 616b, and cloud application 618b). In one embodiment, various environments may be integrated with IDCS to support their access control needs. Such integration is provided, for example, by 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 Connect630b, OAuth2 632b, SAML2 634b, SCIM636b, and REST / HTTP 638b. This allows you to determine where to route requests using the domain name system ("DNS"), separating application consumption from understanding the internal realization of identity services.

The IDCS feature view in Figure 6A also shows that IDCS provides metrics / warnings for user notifications (cloud notification service 718b), file storage (cloud storage service 716b), and DevOPs (cloud monitor service (EM) 722b and cloud metrics services). Includes public cloud infrastructure services that provide common functionality that depends on (Graphic) 720b).

<u style="single">Cloud gate</u> In one embodiment, IDCS implements a "cloud gate" at the web layer. CloudGate is a web server plug-in that allows web applications to externalize user SSO to identity management systems (eg IDCS), similar to WebGate or WebAgent technologies that work with the corporate IDM stack. .. Cloudgate acts as a security gatekeeper to secure access to the IDCS API. In one embodiment, CloudGate is implemented by a web / proxy server plug-in that provides a Policy Enforcement Point (PEP) to protect HTTP resources based on OAuth.

FIG. 7 is a block diagram 700 of an embodiment that realizes the cloud gate 702. Cloudgate 702 runs within web server 712 and acts as a policy enforcement point (PEP). Policy enforcement points are integrated with IDCS policy decision points (PDP) that use open standards (eg, OAth2, OpenID Connect, etc.), while ensuring access to REST API resources 714 for web browsers and applications. It is configured to. In some embodiments, PDP is implemented with OAuth and / or OpenID Connect microservice 704. For example, when user browser 706 sends a request to IDCS to log in for user 710, the corresponding IDCS After verifying the credential, the PDP determines if this credential is sufficient (for example, if it requires another credential, such as a second password). In the embodiment of FIG. 7, the cloudgate 702 has a local policy and can thus serve as both a PEP and a PDP.

As part of the one-time deployment, CloudGate 702 registers IDCS as an OAuth2 client, which allows IDCS to request OIDC and OAuth2 operations. It then retains configuration information about protected and unprotected resources of the application that are subject to request matching rules (how to match URLs to, for example, wildcards, regular expressions, etc.). do. By deploying CloudGate 702, different applications with different security policies can be protected, and the protected applications may be multi-tenant.

During web browser-based user access, Cloudgate 702 acts as an OIDC RP718 that initiates a user authentication flow. If user 710 does not have a valid local user session, Cloudgate 702 redirects the user to the SSO microservice and participates in the OIDC "Authentication Code" flow with the SSO microservice. This flow ends with the delivery of JWT as an identity token. Cloudgate 708 validates the JWT (eg, focus on signing, 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 deleting that local session cookie.

Cloudgate 702 also acts as an HTTP Basic Auth certifier and validates HTTP Basic Auth credential 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 program access by REST API client 708, Cloudgate 702 may act as an OAuth2 resource server / filler 720 for the application's protected REST API 714. This checks if a request exists for the authentication header and access token. When client 708 (eg mobile, web application, JavaScript, etc.) indicates an access token (issued by IDCS) for use with a protected REST API 714, Cloudgate 702 grants access to the API. Validate access tokens before (eg signing, expiring, audience, etc.). The original access token is sent unmodified.

In general, OAuth is used to generate a client identity propagation token (for example, indicating who the client is) or a user identity propagation token (for example, indicating who the user is). In this embodiment, the implementation of OAuth in CloudGate is based on JWT, which defines the format of web tokens, for example provided by IETF, RFC7519.

When the user logs in, a JWT is issued. JWT is signed by IDCS and supports multi-tenant functionality in IDCS. Cloudgate enables multi-tenant function in IDCS by verifying JWT issued by IDCS. Therefore, IDCS provides multi-tenancy both in the physical structure and in the logical business processes that support the security model.

<u style="single">Types of tenancy</u> IDCS identifies three types of tenancy: customer tenancy, client tenancy, and user tenancy. The 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 doing the work). User tenancy identifies which users are using the application to access the data (ie, by whom the work is being performed). For example, when a professional service company provides system integration capabilities for a large discount shop and uses IDCS to provide identity management for the system of this large discount shop, user tenancy is equivalent to this professional service company. However, client tenancy corresponds to the application used to provide system integration capabilities, and customer tenancy is a large discount shop.

Separating and integrating these three tenancy enables multi-tenant capabilities in cloud-based services. In general, for on-premises software installed on an on-premises physical machine, it is not necessary to identify these three tenancy. This is because the user must be physically on the machine to log in. However, in the case of cloud-based service structures, embodiments have tokens to determine who uses which application to access which resource. The three tenancy are codified by tokens, enforced by CloudGate, and used by middle-tier business services. In one embodiment, the OAuth server generates a token. In various embodiments, this token may be used with security protocols other than OAuth.

Separating users, clients, and resource tenancy gives users of the services provided by IDCS a substantial business advantage. For example, by doing so, a service provider who understands the needs of a business (eg, a health business) and its identity management issues will purchase the services provided by IDCS and develop their own back-end applications that consume the services of IDCS. However, this back-end application can be provided to the target business. Therefore, service providers can extend IDCS services to provide their desired functionality and deliver them to specific target businesses. Service providers do not have to build and run software to provide identity services, but instead they can extend and customize IDCS services to meet the needs of their target business.

Some well-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, customer partners, customer clients, clients themselves, or clients whose access is delegated by the customer. By defining and enforcing a plurality of tenancy in the present embodiment, it becomes easy to specify the management function for these various users.

In one embodiment, one IDCS entity does not belong to multiple tenants at the same time, but to only one tenant, and "tenancy" is where the artifact resides. In general, there are multiple components that perform a particular function, and these components can belong to multiple tenants or can belong to the infrastructure. The infrastructure interacts with entity services on behalf of the tenant when it needs to function on behalf of the tenant. In this case, the infrastructure itself has its own tenancy, and the customer has its own tenancy. When a request is made, there are multiple tenancy involved in this request.

For example, a client belonging to "Tenant 1" may execute 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". Therefore, the user needs to go to the resource namespace of "Tenant 2" and request a token for it. Therefore, delegation of authority is realized by identifying "who", "what", and "who" can be done. As another example, the first user working for the first organization (Tenant 1) and the second user working for the second organization (Tenant 2) is the third organization (Tenant 2). You may allow access to documents hosted by "Tenant 3").

In one example, the "tenant 1" client may request an access token for the "tenant 2" user to access the "tenant 3" application. The client may request the token by going to "http: // tenant3 / oauth / token" and calling an OAuth request for this token. The client reveals that it is a client that exists 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 the "client 1" of the "tenant 1", the client has the right to call a request for a token for the "tenant 3" and wants a token for the user of the "tenant 2". Therefore, a "user assertion" is also sent as part of the same HTTP request to reveal that "tenant 2" is the tenancy of this user, and the header of this request is that "tenant 3" is the tenancy of the resource / application. Make it clear. As a result, the request identifies client tenancy, user tenancy, and resource tenancy. The generated access token is issued in the context of target tenancy, which is application tenancy (tenant 3), and includes user tenancy (tenant 2). Therefore, the access token identifies the resource / application tenancy as well as the user tenancy.

In one embodiment, each tenant in the data layer is realized as an independent stripe. From a data management perspective, the artifacts are in the tenant. From a service perspective, the service knows how to work with heterogeneous tenants, and multiple tenancy is a different dimension in the business function of the service. FIG. 8 shows an example 800 of a system that realizes a plurality of tenancy in an embodiment. System 800 includes client 802, which requests services provided by microservice 804, which understands how to work with data in database 806. Database 806 contains multiple tenants 808, each tenant containing a corresponding tenancy artifact. In one embodiment, the microservice 804 is attempted by a "tenant 1" client to obtain a token for a "tenant 2" user to access a "tenant 3" application at https://tenant3/oauth/. An OAuth microservice that requests through a token. Database 806 stores data for client tenancy (tenant 1), user tenancy (tenant 2), and resource / application tenancy (tenant 3). The functionality of the OAuth microservice is performed on the microservice 804 with data from database 806 to verify that the client 802's request is legitimate, and if so, a different tenancy 808. The data from is used to form the token. Therefore, the system 800 is multi-tenant in that it can work in a cross-tenant environment by not only supporting the services given to each tenancy but also supporting services that can function on behalf of various tenants.

System 800 is convenient. The reason is as follows. The microservice 804 is physically separated from the data in the database 806, and by replicating the data through a location closer to the client, the microservice 804 can be provided as a local service to the client, and the system 800 You can manage the availability of services and provide them globally.

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

Generally, a connection is built 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 (eg "Server = sql_box; Database = Common; User"). ID = uid; Pwd = password; "). Once a connection is built, it can be opened and closed and properties (eg, command timeout length, or transaction, if any) can be set. The connection string contains a set of key / value pairs dictated by the data provider's data access interface. A connection pool is a cache of database connections that is kept so that connections can be reused when future requests for the database are needed. In connection pooling, the connection is placed in the pool after it is created and reused so that no new connection needs to be established. For example, if 10 connections are required between Microservice 804 and Database 808, then the connection pool 810 is all in the context of a database user (for example, in relation to a particular database user, for example, who owns this connection). There will be 10 open connections (in relation to who, who's credential is being validated, whether it's a database user, whether it's a system credential, etc.).

Connections in connection pool 810 are created for system users who have access to anything. Therefore, in order to properly handle auditing and privileges by microservices 804, which handles requests on behalf of tenants, database operations are performed in the context of "proxy user" 812, which is associated with the schema owner assigned to a particular tenant. NS. This schema owner can only access the tenancy that was the purpose of creating this schema, and the value of this tenancy is the value of this schema owner. When a request is made for data in database 806, microservice 804 provides this data using the connections in connection pool 810. Therefore, multi-tenancy is a specific tenant data store binding built for each request at the top of a data connection created (for example, in connection with it) in the context of a data store proxy user associated with resource tenancy. Obtained by having a stateless and elastic middle-tier service that handles incoming requests (eg, in connection with it) in the context of, the database can scale independently of the service.

The following provides an example of the function to realize the proxy user 812.

<maths num="1"><img file="JP6917331B2_D0001.tif" /></maths>

In this feature, Microservice 804 uses the database connections in Connection Pool 810, while setting the "Proxy User" setting for connections drawn from Connection Pool 810 to "Tenant". And perform data operations in the context of a tenant.

When configuring different columns for different tenants in the same database by striping all the tables, one table can contain data for all mixed tenants. On the other hand, one embodiment provides a tenant-driven data layer. The present embodiment does not strip the same database for different tenants, but provides different physical databases for each tenant. For example, multi-tenancy may be achieved using a pluggable database (eg Oracle Database 12c from Oracle), where each tenant is assigned a separate partition. At the data tier, the resource manager processes the request and then seeks the data source for the request (separate from the metadata). This embodiment executes a runtime switch to each data source / store for each request. By separating the data of each tenant from the other tenants, this embodiment provides improved data security.

In one embodiment, tokens that differ from each other coordinate different tenancy. The URL token can identify the tenancy of the application requesting the service. The identity token can coordinate the identity of the user to be authenticated. Access tokens can identify multiple tenancy. For example, an access token can coordinate the tenancy that is the target of such access (eg, application tenancy) with the user tenancy of the user to whom access is granted. The client assertion token can identify the client ID and client tenancy. User assertion tokens can identify users and user tenancy.

In one embodiment, the identity token comprises at least a "claim" [used by those skilled in the art of security] indicating the user tenant name (ie, where the user resides). A "claim" associated with an authorization token is a statement that one entity describes itself or another. The statement may relate, for example, to a name, identity, key, group, privilege, or function. Claims are issued by a provider, given one or more values, and then packaged in a security token issued by an issuer commonly known as the security token service (STS). ..

In one embodiment, the access token is at least a claim / statement indicating the resource tenant name (for example, a customer) at the time when the request for the access token is made, a claim / statement indicating the user tenant name, and the requesting OAuth. Includes a claim that indicates the name of the client and a claim / statement that indicates the name of the client tenant. In one embodiment, the access token may be implemented according to the following JSON function.

<maths num="2"><img file="JP6917331B2_D0002.tif" /></maths>

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

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

FIG. 9 is a block diagram of the IDCS network view 900 in one embodiment. FIG. 9 shows a network dialogue between application "zones" 904 in one embodiment. Applications are divided into zones based on the level of protection required and the realization of connectivity to various other systems (eg SSL zone, no SSL zone, etc.). Of the application zones, some are application zones that provide services that require access from inside IDCS, some are application zones that provide services that require access from outside IDCS, and some are open access. .. Therefore, each protection level is strengthened for each zone.

In the embodiment of FIG. 9, communication between services is performed using an HTTP request. In one embodiment, the IDCS uses the access tokens described herein to not only provide services, but also secure access to the IDCS and access within the IDCS itself. In one embodiment, the IDCS microservice is exposed through the RESTful interface and secured by the tokens described herein.

In the embodiment of FIG. 9, any one of the various applications / services 902 may use the IDCS service by making an HTTP call to the IDCS API. In one embodiment, the HTTP request for application / service 902 is Oracle Public Cloud Load Balancing External Virtual IP Address (VIP) 906 (or other similar technology), Public Cloud Web Routing Layer 908, and IDCS Load Balancing Internal VIP. It may be received by the IDCS web routing layer 912 through the 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. IDCS Platform Service Layer 914 is OpenID Includes IDCS microservices called from outside IDCS such as Connect, OAuth, SAML, SCIM. IDCS Infrastructure Services Layer 916 includes support microservices called from within IDCS to support the functionality of other IDCS microservices. Examples of IDCS infrastructure microservices include UI, SSO, reports, caches, job schedulers, service managers, and key-making capabilities. IDCS cache tier 926 supports caching capabilities for IDCS platform service tier 914 and IDCS infrastructure service tier 916.

By strengthening 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 embodiment of FIG. 9, by using the OAuth protocol 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. , Use the same tokens used to secure communication between IDCS components (eg, microservices) within IDCS and secure access from outside IDCS for security within IDCS. That is, the web routing layer 912 uses the same tokens and protocols to process the received request, whether the request is received from outside the IDCS or from inside the IDCS. Therefore, IDCS 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 applicable network protocols such as HTTP, Transmission Control Protocol (TCP), and User Datagram Protocol (UDP). For example, application "X" is based on application "Y" and HTTP, and application "Y" is an HTTP uniform resource locator (Uniform Resource). You can communicate by exposing as Locator: "URL"). In one embodiment, "Y" is an IDCS microservice that exposes a large number of resources, each corresponding to a function. When an "X" (for example, another IDCS microservice) needs to be called, it constitutes a URL that contains the "Y" and the resource / feature that needs to be called (for example, https: / host /). Y / resource), make the corresponding REST call led to "Y" through the web routing layer 912.

In one embodiment, the caller outside the IDCS may not need to know where the "Y" is, but the web routing layer 912 needs to know where the application "Y" is running. In one embodiment, the IDCS implements a discovery function (achieved by the OAuth service) to determine where each application is running and eliminate the need for static routing information availability.

In one embodiment, enterprise manager (EM) 922 provides a single glass that extends on-premises and cloud-based management to IDCS. Kazumi in facilities form a Chef Software Inc. configuration management tools "Chef (Chef)" server 924 provides a configuration management function for various IDCS layer. In one embodiment, the service deployment infrastructure and / or persistent storage module 928 sends OAuth2 HTTP messages to 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.

<u style="single">Cloud access control-SSO</u> 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 heavy cloud standard that requires more management, configuration, and tools to build clients. This embodiment is an OpenID for the application Require user authentication from IDCS by using Connect semantics. This 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 a JWT-based identity token when mapping the authenticated identity back to its own local session for the application to be used. This embodiment supports integration with a coordinated identity management system and exposes SAML IDP support for corporate deployments to require user authentication from IDCS.

FIG. 10 is a block diagram 1000 of the system architecture view of the SSO function in IDCS in one embodiment. This embodiment allows a client application to drive a standards-based web protocol to initiate a user authentication flow. Applications that require cloud system and SSO integration may be in a corporate data center, in a remote partner data center, or operated by an on-premises customer. In one embodiment, different IDCS platform services are connected to OpenID Connect to handle login / logout requests from the native application to which they are connected (ie, an application that utilizes an OpenID connection to integrate with IDCS). SAML IDP service for handling browser-based login / logout requests from your application, SAML for coordinating user authentication to external SAML IDPs Enable SSO business, including SP services and an internal IDCS SSO service for coordinating end-user login ceremonies to manage IDCS hosted session cookies, including local or coordinated login flows. In general, HTTP works with or without forms. When working with a form, this form is visible in the browser. When working without forms, this acts as a client-to-server communication. Both OpenID Connect and SAML require the ability to render forms, which is achieved by the presence of a browser or virtually performed by an application that acts as if the browser were present. In one embodiment, an application client that implements user authentication / SSO through IDCS must be registered as an OAuth2 client in IDCS to obtain a client identifier and credentials (eg ID / password, ID / certificate, etc.). There is a need.

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

In general, the identity metasystem is an interoperable architecture for digital identities that allows the use of a collection of underlying technologies, implementations, and providers. LDAP, SAML, and OAuth are examples of different security standards that provide identity capabilities and can be the basis for building applications, and the identity metasystem is unified for such applications. It may be configured to provide a security system. The LDAP security model specifies a specific mechanism 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 the OpenID application 1010 connects to the OpenID server in IDCS, its "channel" requests the SSO service. Similarly, when SAML application 1012 connects to a SAML server in IDCS, its "channel" also requests SSO service. In IDCS, each microservice (eg OpenID microservice 1004 and SAML microservice 1006) processes each application, and these microservices require SSO functionality from SSO microservice 1008. This architecture can be extended to support any number of other security protocols by adding microservices for each protocol and then using SSO Microservices 1008 for SSO functionality. The SSO Microservice 1008 is the only system authorized to publish sessions (ie, SSO cookie 1014 is provided) and publish sessions in this architecture. The IDCS session is implemented by browser 1002 using SSO cookie 1014. Browser 1002 also uses the local session cookie 1016 to manage its local sessions.

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

In one embodiment, the SSO Microservice 1008 provides a login ceremony 1018, an ID / password recovery 1020, a first login flow 1022, an authentication manager 1024, an HTTP cookie manager 1026, and an event manager 1028. The login ceremony 1018 implements SSO functionality based on customer settings and / or application context and may be configured according to local forms (eg basic Auth), external SAML IDP, external OIDC IDP, and so on. ID / Password Recovery 1020 is used to recover a user's ID and / or password. The first login flow 1022 is realized the first time the user logs in (ie the SSO session does not yet exist). Authentication manager 1024 issues an authentication token when authentication is successful. HTTP Cookie Manager 1026 stores authentication tokens in SSO cookies. Event Manager 1028 publishes events related to SSO functionality.

In one embodiment, the interaction between the OAuth microservices 1004 and the SSO microservices 1008 is based on browser redirects, where the SSO microservices 1008 uses HTML forms to challenge the user, validate the credentials, and session. Issue a cookie.

In one embodiment, for example, the OAuth microservice 1004 receives an authentication request from the browser 1002 and authenticates the user of the application according to a three-way OAuth flow. Thus, the OAuth microservice 1004 acts as the OIDC provider 1030, redirecting the browser 1002 to the SSO microservice 1008 and proceeding along the application context. Depending on whether the user has a valid SSO session, the SSO Microservice 1008 validates the existing session or performs a login ceremony. Upon successful authentication or verification, SSO Microservice 1008 returns the authentication context to OAuth Microservice 1004. The OAuth microservice 1004 then authenticates the browser 1002 (redirects to a callback URL that has an "AZ" code. The browser 1002 sends the AZ code to the OAuth microservice 1004 and requests the required token 1032. The browser 1002 includes its client credentials (obtained when IDCS is registered as an OAuth2 client) in the HTTP authentication header, whereas the OAuth microservice 1004 gives the requested token 1032 to the browser 1002. One embodiment. In, the token 1032 given to the browser 1002 includes a JW identity and an access token signed by the IDCS OAuth2 server. Further details of this feature will be disclosed below with reference to FIG.

In one embodiment, for example, the 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 (for example, 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, the SAML microservice 1006 receives an SSO POST request from a browser and authenticates a user of web application 1012 acting as a SAML SP. The SAML microservice 1006 then acts as the SAML IDP1038, redirecting the browser 1002 to the SSO microservice 1008 and proceeding along the application context. Depending on whether the user has a valid SSO session, the SSO Microservice 1008 validates the existing session or performs a login ceremony. Upon successful authentication or validation, SSO Microservice 1008 returns the 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 the SAML SP1040 or proceed to a remote SAML IDP1042 (eg, Active directory federation service (ADFS). In 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. Challenge the user, validate the credential, and issue a session cookie.

In one embodiment, the dialogue between components inside IDCS (eg 1004, 1006, 1008) and components outside IDCS (eg 1002, 1011, 1042) takes place through firewall 1044.

<u style="single">Login / logout flow</u> FIG. 11 is a message sequence flow 1100 of the SSO function provided by IDCS in one embodiment. When a user uses the browser 1102 to access client 1106 (eg a browser-based application or mobile / native application), Cloudgate 1104 acts as an application enforcement point and enforces the policies specified in the local policy text file. do. Cloudgate 1104 requests user authentication if it detects that the user does not have a local application session. To do so, Cloudgate 1104 initiates an OpenID Connect login flow for OAuth2 Microservice 1110 by redirecting browser 1102 to OAuth2 Microservice 1110 (a three-way AZ Grant flow, range = "openid profile". ").

Requests from browser 1102 reach OAuth2 microservice 1110 across IDCS routing layer web service 1108 and cloudgate 1104. The OAuth2 microservice 1110 configures the application context (ie, the metadata that describes the application, such as the identity of the connecting application, the client ID, the configuration, what the application can do, etc.) and the browser 1102 SSO Micro 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, the session cookie does not exist), SSO MicroService 1112 initiates a user login ceremony according to the customer's login preferences (eg, displays a branded login page). To do so, the SSO Microservice 1112 redirects the browser 1102 to the JavaScript-enabled login application service 1114. Login application service 1114 provides a login page for browser 1102. Browser 1102 sends a REST POST containing login credentials to SSO Microservice 1112. SSO Microservice 1112 generates an access token and REST Send to POST Cloudgate 1104. Cloudgate 1104 validates the user's password by sending credentials to the management SCIM microservice 1116. The management SCIM microservice 1116 determines that the authentication was successful and sends the corresponding message to the 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 posted on the login page that informs the user about the specific profile attributes that are exposed to the application. During the login ceremony, SSO Microservice 1112 will respect the customer's IDP preferences and, as soon as it is configured, redirects to the IDP to authenticate against the configured IDP.

Upon successful authentication or validation, the SSO Microservice 1112 launches the browser 1102 with a newly created / updated SSO host HTTP cookie containing the user's authentication token (eg, a cookie created in the context of the host indicated by "HOSTURL"). ) To redirect the browser 1102 back to the OAuth2 microservice 1110. The OAuth2 microservice 1110 returns the AZ code (eg OAuth concept) back to the browser 1102 and redirects it to Cloudgate 1104. Browser 1102 sends the AZ code to Cloudgate 1104, which sends a REST POST to OAuth2 Microservice 1110 to request access and identity tokens. Both of these tokens are scoping to OAuth Microservice 1110 (as indicated by the Audience Token Claim). Cloudgate 1104 receives these tokens from the OAuth2 microservice 1110.

Cloudgate 1104 uses an identity token to map the authenticated user's identity to its internal account representation, which may store this mapping in its HTTP cookie. Cloudgate 1104 then redirects browser 1102 to client 1106. The browser 1102 then reaches client 1106 and receives the corresponding response from client 1106. From this point on, browser 1102 can seamlessly access the application (ie client 1106) as long as the application's local cookies are valid. If the local cookie is disabled, the authentication process will be repeated.

Cloudgate 1104 also uses the access token included in the request to obtain "userinfo" from the OAuth2 microservice 1110 or from the SCIM microservice. This access token is sufficient to access the "userinfo" resource for the attributes given by the "profile" scope. This is also sufficient to access the "/ me" resource via the SCIM microservice. In one embodiment, by default, the included access tokens are sufficient only for user profile attributes given under the "profile" scope. Access to other profile attributes is granted based on the additional (arbitrary) scope presented in the AZ Grant Login Request issued by Cloudgate 1104.

When a user accesses another application with OAuth2 integration, the same process is repeated.

In one embodiment, the SSO integrated architecture uses a similar OpenID Connect user authentication flow for browser-based user logouts. In one embodiment, a user with an existing application session accesses CloudGate 1104 and initiates a logout. Instead, the user may have started logging out on the IDCS side. Cloudgate 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 hosted SSO cookie. SSO Microservice 1112 initiates a set of redirects (OAuth2 OP and SAML IDP) to known logout endpoints tracked in the user's SSO cookie.

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

<u style="single">Cloud cache</u> One embodiment provides a service / function called a cloud cache. The cloud cache is given to IDCS to support communication with LDAP-based applications such as email servers, calendar servers, and any business applications. This is because IDCS does not communicate according to LDAP, but such applications are configured to communicate only based on LDAP. Typically, cloud directories are exposed via the REST API and do not communicate according to the LDAP protocol. In general, managing LDAP connections through corporate firewalls requires special configurations that are difficult to set up and manage.

To support LDAP-based applications, the cloud cache translates LDAP communication into a protocol suitable for communicating with cloud systems. In general, LDAP-based applications use databases over 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 tree-structured resources, while SQL represents data as tables and fields. Therefore, it would be more desirable for LDAP to be for search functions. On the other hand, it would be more desirable for SQL to be for transactional functions.

In one embodiment, the services provided by IDCS may be used in an LDAP-based application to, for example, authenticate users of the application (ie identity service) or enforce security policies of the application (ie security service). can. In one embodiment, the interface with the IDCS goes through a firewall and is based on HTTP (eg REST). Corporate firewalls typically do not allow access to internal LDAP communications, even if the communications provide Secure Sockets Layer (SSL). Also, the corporate firewall does not allow TCP ports to be exposed through the firewall. However, the cloud cache translates between LDAP and HTTP, allowing LDAP-based applications to reach the services provided by IDCS, and the firewall is open to HTTP.

In general, LDAP directories may be used in the line of business, such as marketing and development, and define users, groups, businesses, and so on. In one example, the marketing and development business may be targeted at a diverse range of customers, each with its own application, user, group, business, and so on. Another example of a business line that can run an LDAP cache directory is a wireless service provider. In this case, each call made by the user of the wireless service provider may authenticate the user's device to the LDAP directory and synchronize some of the corresponding information in the LDAP directory with the billing system. In these examples, LDAP provides the ability to physically separate the content retrieved at run time.

In one example, a wireless service provider may use services provided by IDCS to support short-term marketing campaigns, while treating its 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, the number of cloud caches realized in IDCS may be any number.

<u style="single">Distributed data grid</u> In one embodiment, the cache cluster in IDCS is implemented, for example, based on the distributed data grid disclosed 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 environment or a cluster environment manages information and related operations such as calculations by working together. By using a distributed data grid, it is possible to manage application objects and data shared between servers. The distributed data grid provides short response times, high throughput, predictable scalability, continuous availability, and information reliability. As a concrete example, for example, Oracle's Oracle Distributed data grids, such as Coherence's data grid, achieve even higher performance by storing information in-memory and use redundancy to keep copies of synchronized information across multiple servers. Ensures system resiliency and continuous data availability in the event of a server failure.

In one embodiment, IDCS implements a distributed data grid, such as Coherence, that allows all microservices to request access to shared cache objects without being blocked. Coherence is a claimable 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 shows an example of a distributed data grid 1200 that stores data and grants data access rights to the client 1250 to realize an embodiment of the present invention. A "data grid cluster" or "distributed data grid" stores information by working together in one or more clusters (eg 1200a, 1200b, 1200c) within a distributed or clustered environment, such as related calculations. A system that includes multiple computer servers that manage operation (eg 1220a, 1220b, 1220c, and 1220d). The distributed data grid 1200 is shown as including four servers 1220a, 1220b, 1220c, 1220d with five data nodes 1230a, 1230b, 1230c, 1230d, and 1230e in cluster 1200a, but the distributed data grid 1200. Can include any number of clusters and any number of servers and / or nodes in each cluster. In certain embodiments, the distributed data grid 1200 implements the present invention.

As shown in Figure 12, the distributed data grid provides data storage and management capabilities by distributing the data across a large number of servers (eg 1220a, 1220b, 1220c, and 1220d) with which it works. Each server in a data grid cluster is a traditional computer, such as a "commodity x86" server hardware platform with one to two processor sockets and two to four CPU cores per processor socket. It may be a system. Each server (eg 1220a, 1220b, 1220c, and 1220d) has one or more CPUs and a Network Interface card. Card: "NIC") and, for example, a minimum of 4GB of RAM and a maximum of 64GB of RAM. Server 1220a is shown to have CPU 1222a, memory 1224a, and NIC 1226a (these elements are also on other servers 1220b, 1220c, 1220d but not shown). Optionally, each server may be provided with a flash memory (eg SSD 1228a) to provide excess storage capacity. At the time of delivery, the SSD capacity is preferably 10 times the size of the RAM. Servers in the data grid cluster 1200a (eg 1220a, 1220b, 1220c, 1220d) use high bandwidth NICs (eg PCI-X or PCIe) to perform high performance network switches 1220 (eg Gigabit and above Ethernet®). It is connected to the.

The cluster 1200a preferably contains a minimum of four physical servers to avoid the possibility of data loss during a failure, but typical equipment has 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. Ideally, each data grid cluster should be limited to a single switch 1202 that provides single-hop communication between servers in order to minimize communication time between servers. Thus, the cluster is limited by the number of ports on switch 1202. Therefore, a typical cluster contains 4 to 96 physical servers.

In most Wide Area Network (WAN) configurations of the distributed data grid 1200, each data center in the WAN is an independent but interconnected data grid cluster (eg 1200a, 1200b, And 1200c). The WAN can contain more clusters than, for example, the cluster shown in Figure 12. In addition, by using interconnected but independent clusters (eg 1200a, 1200b, 1200c) and / or interconnected but independent clusters within a data center that is separated from each other. By placing in, the distributed data grid guarantees data and services to client 1250 to prevent simultaneous loss of all servers in a cluster due to natural disasters, fires, floods, long-term power outages, etc. Can be done.

One or more nodes (eg 1230a, 1230b, 1230c, 1230d and 1230e) run on each server in cluster 1200a (eg 1220a, 1220b, 1220c, 1220d). In a distributed data grid, the node may be, for example, a software application, a virtual machine, etc., and the server may include an operating system, a hypervisor, etc. (not shown) on which the node runs. In the Oracle Coherence data grid, each node is a Java virtual machine (JVM). A large number of JVMs / nodes may be provided on each server, depending on the processing power of the CPU and the memory available on the server. JVMs / nodes may be added, started, stopped, and removed at the request of the distributed data grid. JVMs running Oracle Coherence automatically join and cluster at boot time. JVMs / nodes that join a cluster are called cluster members or cluster nodes.

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

The computer-readable medium may be any available medium accessible from the processor, including volatile and non-volatile media, removable and non-removable media, and communication media. The communication medium may include computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier or other transport mechanism, any information transmission medium. include.

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

In one embodiment, the memory stores a software module that provides functionality when executed by the processor. The module contains an operating system that provides operating system functionality to each client or server. The module may further include a cloud identity management module for providing cloud identity management functions and all other functions disclosed herein.

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

The disclosed embodiments provide cloud-based multi-tenant IAM services by implementing a microservices-based architecture. In one embodiment, each requested identity management service is divided into real-time tasks processed by middle-tier microservices and near-real-time tasks offloaded to the message queue. Therefore, the embodiment provides a cloud-scale IAM platform.

FIG. 13 is a flow diagram 1300 of an IAM function according to an embodiment. In one embodiment, the function of the flow diagram of FIG. 13 is realized by software stored in memory or other computer-readable or tangible medium and performed by a processor. In other embodiments, this feature is provided by hardware (eg, application specific integrated circuit (ASIC), programmable gate array (PGA), field programmable gate array (PGA), and field programmable gate array (PGA). It may be executed (by using programmable gate array: "FPGA"), etc., or it may be executed by some combination of hardware and software.

At 1302, a request for identity management service is received from the client, at 1304, the request is authenticated, and at 1306, the microservice is accessed based on the request. For example, in one embodiment, the IDCS microservice 614 can be used by various applications / services 602 making HTTP calls to the IDCS API, as shown in FIG. In one embodiment, a microservice is a self-contained module capable of communicating with other modules / microservices, and each microservice has an anonymous universal port that can be contacted by others. In one embodiment, the request is authenticated by a security gate, such as the cloud gate described herein. In one embodiment, the request is authenticated with reference to, for example, the web routing layer 610 in FIG. 6 and / or the cloud gate 702 in FIG.

Based on the request, determine the client tenancy, the user tenancy associated with the request, and the resource tenancy associated with the request, for example as described herein for "types of tenancy" in 1308. In one embodiment, the request comprises a client assertion token that identifies the client's tenancy. In one embodiment, the request comprises a user assertion token that identifies the user's tenancy. In one embodiment, the request header indicates the tenancy of the resource. In one embodiment, the resource is an application or data that resides in resource tenancy and is owned by the corresponding resource tenant. In one embodiment, the client is the browser used by the user. In one embodiment, at least two of the client tenancy, the user tenancy, and the resource tenancy are the same tenancy.

In one example, the "tenant 1" client may request an access token for the "tenant 2" user to access the "tenant 3" application. The client may request the token by going to "http: // tenant3 / oauth / token" and calling an OAuth request for this token. The client reveals that it is a client that exists 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 the "client 1" of the "tenant 1", the client has the right to call a request for a token for the "tenant 3" and wants a token for the user of the "tenant 2". Therefore, a "user assertion" is also sent as part of the same HTTP request. The generated access token will be issued in the context of the target tenancy, which is the application tenancy ("tenant 3"), and will include the user tenancy ("tenant 2").

Data is retrieved from at least one of client tenancy, user tenancy, or resource tenancy, as described herein in connection with data retrieved from database 806, eg, FIG. Will be done. In one embodiment, the microservices 804 retrieves data using connection pool 810, which provides a connection to database 806, as described herein in relation to the data retrieved from database 806 of FIG. .. In one embodiment, the client tenancy, the user tenancy, and the resource tenancy may be the same tenancy or different tenancy. For example, the client may be in the first tenant and the user may be in a second tenant that is different from the first tenant. As another example, the client may reside in the first tenant and the resources may reside in a second tenant that is different from the first tenant. As another example, the user may reside in the first tenant and the resources may reside in a second tenant that is different from the first tenant. As another example, the client may be in the first tenant, the user may be in a second tenant different from the first tenant, and the resources may be in a third tenant different from the first and second tenants. It may exist in the tenant of.

Identity management tasks are performed by services using data, as described herein in connection with the IDCS API Platform of FIG. 6 and access to microservices at IDCS Intermediate 614. In one embodiment, the identity management task involves obtaining an access token for a user to access a resource. In one embodiment, the access token identifies the tenancy of the resource and the tenancy of the user. In one embodiment, the identity management task involves authenticating the user. In one embodiment, authentication may be based on an OAuth standard that uses a three-way or two-way flow.

In one embodiment, the service is stateless. In one embodiment, the microservice 804 uses proxy user 812 to connect to each connection in connection pool 810. In one embodiment, proxy user 812 represents tenant 808 in database 806. In one embodiment, the database 806 and the microservices 804 are configured to scale independently of each other. In one embodiment, database 806 includes a distributed data grid.

FIG. 14 is a flow diagram 1400 of an IAM function according to an embodiment. In one embodiment, the functions of the flow diagram of FIG. 14 are realized by software stored in memory or other computer-readable or tangible medium and performed by a processor. In other embodiments, this feature can be achieved by using hardware (eg, application-specific integrated circuits (ASIC), programmable gate arrays (PGA), field programmable gate arrays (FPGA), and so on. ) It may be executed, or it may be executed by some combination of hardware and software.

At 1402, the client receives a request to obtain an access token for the user to access the resource. In one embodiment, this request is an HTTP request. For example, in one embodiment, various applications / services 602 are IDCS, as shown in FIG. IDCS microservices 614 can be used by making HTTP calls to the API. In one embodiment, this request indicates an authorization standard for authenticating a user and obtaining an access token. In one embodiment, the authorization standard is OAuth. In one embodiment, the client is an OAuth client. In one embodiment, the token is a JWT. In one embodiment, a resource is an application or data that resides in the tenancy of the resource and is owned by the corresponding tenant. In one embodiment, the client is the browser used by the user. In one embodiment, the request is authenticated by a security gate, such as a cloud gate, as described herein in connection with, for example, the web routing layer 610 of FIG. 6 and / or the cloud gate 702 of FIG.

At 1404, determine client tenancy, user tenancy, and resource tenancy based on the request. In one embodiment, the request comprises a client assertion token that identifies the client's tenancy. In one embodiment, the request comprises a user assertion token that identifies the user's tenancy. In one embodiment, the request header indicates the tenancy of the resource. In one example, for example, a "tenant 1" client may request an access token for a "tenant 2" user to access a "tenant 3" application. The client may request the token by going to "http: // tenant3 / oauth / token" and calling an OAuth request for this token. The client reveals that it is a client that exists 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 the "client 1" of the "tenant 1", the client has the right to call a request for a token for the "tenant 3" and wants a token for the user of the "tenant 2". Therefore, a "user assertion" is also sent as part of the same HTTP request. The generated access token will be issued in the context of the target tenancy, which is the application tenancy ("tenant 3"), and will include the user tenancy ("tenant 2").

In one embodiment, the client tenancy, the user tenancy, and the resource tenancy may be the same tenancy or different tenancy. In one embodiment, at least two of the client tenancy, the user tenancy, and the resource tenancy are the same tenancy. In one embodiment, at least two of the client tenancy, the user tenancy, and the resource tenancy are different tenancy. For example, the client may be in the first tenant and the user may be in a second tenant that is different from the first tenant. As another example, the client may reside in the first tenant and the resources may reside in a second tenant that is different from the first tenant. As another example, the user may reside in the first tenant and the resource may reside in a second tenant that is different from the first tenant. As another example, the client may be in the first tenant, the user may be in a second tenant different from the first tenant, and the resources may be different from the first and second tenants. It may exist in a third tenant.

At 1406, access microservices on demand. In one embodiment, a microservice is a self-contained module that can talk to other modules / microservices, each microservice having an anonymous universal port that can be contacted by others. In one embodiment, microservices are accessed, for example as described herein in connection with accessing the IDCS API Platform and IDCS Intermediate Layer 614 microservices of FIG.

At 1408, a microservice runs an identity management service based on a request. In one embodiment, the identity management service comprises generating an access token that identifies the tenant and user tenancy of the resource. For example, in one embodiment, the access token is at least a claim indicating the resource tenant name (for example, a customer) at the time when the request for the access token is made, a claim indicating the user tenant name, and the requesting OAuth client. Includes a claim indicating the name and a claim indicating the client tenant name. In one embodiment, the access token may be implemented according to the following JSON function.

<maths num="3"><img file="JP6917331B2_D0003.tif" /></maths>

In one embodiment, the identity management service comprises authenticating the user. In one embodiment, authentication may be based on an OAuth standard that uses a three-way or two-way flow, as described herein with reference to, for example, FIG. In one embodiment, the request is authenticated by a security gate, such as the cloud gate described herein.

In one embodiment, client tenancy, user tenancy, and resource tenancy data are stored in a database. In one embodiment, the database and microservices are configured to scale independently of each other. In one embodiment, the database includes a distributed data grid.

FIG. 15 is a flow diagram 1500 of an IAM function according to an embodiment. In one embodiment, the function of the flow diagram of FIG. 15 is realized by software stored in memory or other computer-readable or tangible medium and performed by a processor. In other embodiments, this feature can be achieved by using hardware (eg, application-specific integrated circuits (ASIC), programmable gate arrays (PGA), field programmable gate arrays (FPGA), and so on. ) It may be executed, or it may be executed by some combination of hardware and software.

At 1502, it receives a request to run an identity management service. In one embodiment, the request includes a call to an API that identifies an identity management service and a microservice that is configured to perform that identity management service. In one embodiment, a microservice is a self-contained module capable of communicating with other modules / microservices, and each microservice has an anonymous universal port that can be contacted by others. For example, in one embodiment, the IDCS microservices 614 may be used by various applications / services 602 making HTTP calls to the IDCS API, as shown in FIG. In one embodiment, a microservice is a run-time component / process.

In one embodiment, the request includes a URL. In one embodiment, the microservice is specified in the 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 such as "host / microservice / resource" in the IDCS web environment, the microservice is characterized by having a specific URL prefix such as "host / oauth / v1", but the actual microservice. Is "oauth / v1". There are multiple APIs under "oauth / v1", and multiple APIs are, for example, the API "host / oauth / v1 / token" for requesting tokens, to authorize the user. API "host / oauth / v1 / authorize" etc. That is, the URL realizes a micro service, and the resource part of the URL realizes an 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).

At 1504, authenticate the request. In one embodiment, a security gate, such as a cloud gate, authenticates the request, as described herein with reference to, for example, the web routing layer 610 in FIG. 6 and / or the cloud gate 702 in FIG.

Accessing microservices in 1506, for example, as described herein in connection with accessing the IDCS API Platform and IDCS middle tier 614 microservices of FIG. In one embodiment, communication with a microservice is configured through an anonymous universal port of the microservice. In one embodiment, the anonymous universal port of a microservice is the standard communication channel that the microservice traditionally exposes (eg, as a traditional HTTP port) and other modules / microservices within the same service talk to it. It is a standard communication channel that makes it possible. In one embodiment, a microservice provides one or more functions by exposing one or more APIs. In one embodiment, communication with microservices is only achieved through one or more APIs. That is, microservices can only be reached / contacted by calling such APIs. In one embodiment, communication with microservices is configured according to a lightweight protocol. In one embodiment, the lightweight protocol includes HTTP and REST. In one embodiment, the request comprises a call to the RESTful HTTP API. Therefore, one embodiment provides a dispatch function. Each HTTP request contains a URI and a verb. This embodiment parses an endpoint (host / service / resource) from a URI and combines it with an HTTP verb (eg POST, PUT, PATCH or DELETE) to dispatch the right method for the right module. To (or call). This pattern is common to REST and is supported by various packages (eg Jersey).

In 1508, microservices perform identity management services, as described herein in connection with accessing the IDCS "API Platform" and IDCS middle tier 614 microservices, for example. In one embodiment, microservices are stateless, laterally scalable, and independently deployable. In one embodiment, each physical implementation of a microservice is configured to securely support multiple tenants. In one embodiment, the identity management service includes a login service, an SSO service, a federation service, a token service, a directory service, a provisioning service, or an RBAC service.

In one embodiment, the microservice performs an identity management service based on tenant data stored in a database. In one embodiment, the database and microservices are configured to scale independently of each other. In one embodiment, the database includes a distributed data grid.

FIG. 16 is a flow diagram 1600 of an IAM function according to an embodiment. In one embodiment, the function of the flow diagram of FIG. 16 is realized by software stored in memory or other computer-readable or tangible medium and performed by a processor. In other embodiments, this feature can be achieved by using hardware (eg, application-specific integrated circuits (ASIC), programmable gate arrays (PGA), field programmable gate arrays (FPGA), and so on. ) It may be executed, or it may be executed by some combination of hardware and software.

At 1602, he receives a request to run an identity management service, and at 1604 he accesses a microservice based on the identity management service. In one embodiment, a microservice is a self-contained module capable of communicating with other modules / microservices, and each microservice has an anonymous universal port that can be contacted by others. For example, in one embodiment, the IDCS microservices 614 may be used by various applications / services 602 making HTTP calls to the IDCS API, as shown in FIG. In one embodiment, the service is a login service, SSO service, federation service, token service, directory service, provisioning service, or RBAC service.

One or more real-time tasks and one or more nears that must be performed to complete the identity management service, as described in 1606, for example, in connection with "real-time and near-real-time tasks" herein. -Judge as a real-time task. In one embodiment, the identity management service comprises authenticating the user, and one or more real-time tasks include validating the user's credentials and initiating a corresponding session. In one embodiment, one or more near real-time tasks include at least one of audits or notifications. In one embodiment, the request is authenticated by a security gate, such as a cloud gate, as described herein in connection with, for example, the web routing layer 610 of FIG. 6 and / or the cloud gate 702 of FIG.

In 1608, a microservice (microservice 614 in Figure 6) executes one or more real-time tasks synchronously, and in 1610, queues one or more near-real-time tasks that run asynchronously (message in Figure 6). Send to queue 628). In one embodiment, executing a task synchronously means waiting for the end of execution of a task until the start of execution of another task. In one embodiment, executing a task asynchronously means that the execution of another task may be started before the execution of the previous task ends (eg, during the execution of the previous task in a thread). To start another task or process in another thread). In one embodiment, the queue is a message queue (eg, Message Queuing 628 in FIG. 6) that provides a highly scalable asynchronous event management system with guaranteed delivery and processing. In one embodiment, the identity management task is required to allow the user access to the resource. In one embodiment, the user can access the resource at the time when the first set of subtasks is completed and before the second set of subtasks is completed.

In one embodiment, the determination of which task to execute synchronously and which task to execute asynchronously as part of the request is made at design time rather than at run time. This embodiment executes code with a specific value at run time (eg, sends an event that creates a specific user or records the creation of a specific user), but at run time, is the specific task synchronous? It does not determine if it is asynchronous. In one embodiment, for example, when IDCS receives a request to register or create a new user, the corresponding microservices focus on the configuration data of the operational database (located in global database 620 in Figure 6). , It is determined that the "user creation" operation is marked with "user creation" which is specified as an asynchronous operation in the configuration data. The microservice returns to the client to indicate that the user was successfully created, but the actual notification email delivery is postponed and pushed to the backend. To do so, the microservice uses messaging API 616 to put a message in the store queue 628.

In one embodiment, the microservice is stateless. In one embodiment, the microservice performs an identity management service based on tenant data stored in a database. In one embodiment, the database and microservices are configured to scale independently of each other. In one embodiment, the database includes a distributed data grid.

Some embodiments are specifically exemplified and / or described herein. However, it is understood that the modifications and modifications of the disclosed embodiments are covered by the above teachings and are included in the scope of the following claims without departing from the spirit and intended scope of the present invention. Let's go.