JP2015531511A - Multi-domain identity management system - Google Patents

Abstract

A multi-tenant identity management (IDM) system performs IDM functions for a variety of different customer domains within a shared cloud computing environment without duplicating a separate IDM system for each separate domain Make it possible to do. The IDM system can provide IDM functionality to service instances located in a variety of different customer domains while performing isolation between those domains. The cloud-wide identity store may include identity information for multiple customer domains, and the cloud-wide policy store may include security policy information for multiple customer domains. The multi-tenant IDM system can provide a delegation model in which domain administrators can be specified for each domain and each domain administrator can delegate a role to other user identities belonging to that domain. . A service instance specific administrator may be designated by a domain administrator to manage a particular service instance in the domain.

Description

CROSS REFERENCE TO RELATED APPLICATIONS This application claims priority to US patent application Ser. No. 13 / 838,813 filed Mar. 13, 2013 entitled Multi-tenancy Identity Management System, the entire contents of which are hereby incorporated by reference. Claims priority to US Provisional Patent Application No. 61 / 698,463, filed September 7, 2012, which is incorporated herein by reference for all purposes; and is entitled Shared Identity Management Architecture; The entire contents of which are incorporated herein by reference for all purposes; priority of US Provisional Patent Application No. 61 / 698,413, filed September 7, 2012, entitled Tenant Automation System. Claimed and incorporated herein by reference in its entirety for all purposes; entitled Service Deployment Infrastructure Claims priority of US Provisional Patent Application No. 61 / 698,459, filed September 7, 2012; US Provisional Patent Application, filed March 14, 2013, entitled Cloud Infrastructure Claims 61 / 785,299, the entire contents of which are incorporated herein by reference for all purposes.

BACKGROUND The following disclosure relates generally to computer security, and more specifically to identity management within a cloud computing environment that is divided into various distinct identity domains.

  Cloud computing requires the use of computing resources (eg, hardware and software) delivered as a service on a network (typically the Internet). Cloud computing outsources user data, software and operations to remote services. Cloud computing can be used, for example, to provide Software as a Service (SaaS) or Platform as a Service (PaaS). In a business model using SaaS, users are allowed access to application software and databases. The cloud provider can manage the infrastructure and platform on which the application is running. SaaS providers generally use a subscription fee to set an application price. SaaS may offer the potential to reduce information technology operational costs by outsourcing hardware and software maintenance and support to cloud providers in business. This outsourcing may allow the business to redistribute information technology operating costs from hardware / software costs and labor costs to achieving other information technology goals. Furthermore, if the application is centrally hosted, updates can be published without the user installing new software. However, some organizations may be concerned about the fact that the user's data is stored on the cloud provider's server and that the data can be accessed without authentication.

  End users can access cloud-based applications through a web browser or lightweight desktop or mobile application. On the other hand, business software and user data can be stored on a server at a location remote from the business and those users. Cloud computing, at least in theory, enables enterprises to deploy their applications more quickly by improving manageability and reducing maintenance. Cloud computing, at least theoretically, allows information technology managers to adjust resources more quickly to meet often unpredictable business demands.

  Identity management (IDM) is a task that controls information about users of a computer system. Such information may include information that authenticates the identity of such a user. Such information may include information that describes what data the users are authorized to access. Such information describes what actions those users are authorized to perform on various system resources (eg files, directories, applications, communication ports, memory segments, etc.). Information can be included. The IDM can also include descriptive information about each user and management of the descriptive information about who can access and modify the descriptive information and how.

  In some cases, a cloud computing environment could include a separate IDM system or a separate instance of an IDM system for each separate organization using the cloud computing environment. However, such a scheme may be considered as a waste of computing resources with a waste of effort.

Overview Some embodiments of the present invention include an identity management (IDM) system implemented in a cloud computing environment and divided into multiple distinct identity domains.

  In an embodiment of the invention, a set of constructs are all aligned to create an abstract or “tenant sliced” view of a single IDM system. This single IDM system may include multiple separate components or subsystems. The IDM system can be shared among multiple independent and separate “tenants” or IDM system customers to be more closely utilized. Thus, there is no need to instantiate a separate IDM system for each separate customer. The single IDM system can be configured for each tenant of the IDM system so that a virtual diagram of the IDM system specific to that tenant can be presented to the user of that tenant.

  Embodiments of the present invention may use the concept of virtualization. Separate views of an IDM system can be virtualized within a single IDM system in a manner that is conceptually similar to the manner in which multiple distinct virtual machines can be virtualized on a single host computing device. This virtualization can be achieved by configuring the IDM system in a specific manner. An IDM system may include a plurality of separate layers including an upper layer and a lower layer that are conceptually stacked vertically in sequence. The upper layer can be divided at least. In an IDM system, various different services (eg, authentication and / or authorization services) can be associated with various different tenants of the IDM system. The IDM system can separate each tenant so that each tenant can only interact with an IDM system “slice” or partition dedicated to that tenant. In this way, the IDM system can perform separation between tenants.

  Exemplary embodiments of the present invention provide a computer-implemented method that creates a plurality of identity domains in a cloud computing environment and between identity domains within the plurality of identity domains. Performing separation, adding a service instance to a specific identity domain of multiple identity domains, a service instance, and a specific partition of an identity store that stores identities for each identity domain of the multiple identity domains; Storing data for associating a service instance with multiple identity domains associated with different identity domains And storing data associating a particular partition policy store that stores policies for service instance.

  In one example, the computer-implemented method further assigns a first role from a hierarchy of roles to a first user having a first user identity stored in an identity store and associated with a particular identity domain. The first role is a role that allows a user having the first role to manage all service instances associated with a particular identity domain, the method further comprising: Assigning, from a hierarchy of roles, a second role to a second user having a stored second user identity, the second role comprising: a user having the second role having a specific identity domain Single service associated with the Is a role that allows you to manage the instance.

  In one example, assigning the second role to the second user assigning the second role to the second user in response to the first user delegating the second role to the second user. Includes steps.

  In one example, the step of adding a service instance to a particular identity domain of a plurality of identity domains is stored in an identity store with a third role defined by a plurality of roles associated with a particular service instance type, Assigning to a third user having a third identity associated with a particular identity domain.

  In one example, the computer-implemented method further includes causing the second role to inherit all permissions associated with the third role, and causing the first role to inherit all inherited by the second role. Inheriting the permission of

  In one example, creating multiple identity domains within a cloud computing environment includes creating a specific identity domain within the cloud computing environment, and creating a specific identity domain within the cloud computing environment. Includes sending an email message to a specified email address, which provides a mechanism by which recipients of the email message can establish an administrative identity within a particular identity domain.

  Exemplary embodiments of the present invention provide a computer-implemented method, the method comprising establishing a single identity management (IDM) system in a cloud computing environment, the single IDM system having a cloud computing Providing an IDM function to a first service instance associated with a first identity domain defined in a computing environment and separated from a second identity domain defined in a cloud computing environment; Causing the IDM system to provide IDM functionality to a second service instance associated with the second identity domain.

  In one example, a computer-implemented method is further associated with a single IDM system associated with a first identity domain rather than a second identity domain in a single identity store maintained in a cloud computing environment. Storing a user identity; causing a single IDM system to store a user identity associated with a second identity domain instead of the first identity domain in a single identity store; and Generating a first credential, wherein the first credential is a user identity in which the first service instance is not associated with the first identity domain. Allowing a single IDM system to interact with a portion of a single identity store that includes a user identity associated with a first identity domain rather than a portion of a single identity store that includes Generating a second credential, wherein the second credential is not part of a single identity store where the second service instance contains a user identity that is not associated with a second identity domain; Allows to interact with parts of a single identity store containing user identities associated with identity domains.

  In one example, a computer-implemented method is further associated with a single IDM system with a first service instance, rather than a second service instance in a single policy store maintained within a cloud computing environment. Storing a security access policy; causing a single IDM system to store a security access policy associated with a second service instance instead of the first service instance in a single policy store; and a single IDM system. Generating a first credential, wherein the first credential includes a single security access policy in which the first service instance is not associated with the first service instance. Allowing the interaction with a single policy store part that includes the security access policy associated with the first service instance, rather than the policy store part, and the method further provides the single IDM system with a second credential. Generating a second credential associated with the second service instance rather than being part of a single policy store that includes a security access policy that is not associated with the second service instance. Allows to interact with parts of a single policy store containing specified security access policies.

1 is a block diagram conceptually illustrating an example of a shared IDM system from a tenant perspective, according to an embodiment of the invention. FIG. 6 is a flowchart illustrating an example technique for creating multiple identity domains for multiple customers via a shared IDM system, according to an embodiment of the invention. 1 is a block diagram illustrating an example of an overview of a hierarchical cloud-based IDM system, according to an embodiment of the invention. FIG. It is a block diagram which shows the example of the subsystem of a cloud security foundation layer based on the Example of invention. It is a block diagram which shows the example of the subsystem of a cloud shared IDM layer based on the Example of invention. FIG. 3 is a block diagram illustrating an example of an Oracle IDM / security layer subsystem, according to an embodiment of the invention. 1 is a block diagram illustrating an example of a cloud-based IDM system that can use a role hierarchy to manage identity domains, according to an embodiment of the invention. FIG. FIG. 2 is a block diagram illustrating a multi-tenant IDM system that allows an application instance runtime component to access identities defined in an identity domain, according to an embodiment of the invention. FIG. 2 is a simplified block diagram illustrating components of a system environment that may be used in accordance with an embodiment of the present invention. FIG. 2 is a simplified block diagram of a computer system that can be used in accordance with an embodiment of the present invention. It is a block diagram which shows the role delegation in the multi-tenant IDM system based on the Example of invention. It is a block diagram which shows the permission inheritance in the multi-tenant IDM system based on the Example of invention. FIG. 2 is a block diagram illustrating an example system for provisioning service instances in an identity domain, according to an embodiment of the invention. FIG. 2 is a block diagram illustrating an example of a multi-tenant cloud-based system in which cloud hardware and software resources can be shared between identity domains, according to an embodiment of the invention. FIG. 3 is a block diagram illustrating an example JAVA cloud service architecture that can be used in a cloud-based system to share virtual “slices” of cloud hardware between isolated customers, according to an embodiment of the invention. is there. FIG. 3 is a hierarchical diagram illustrating an example of the structure of a multi-tenant LDAP directory for a cloud-based IDM system, according to an embodiment of the invention. FIG. 6 is a hierarchy diagram illustrating an example structure of an LDAP directory subtree related to role templates for different service types, according to an embodiment of the invention. FIG. 3 is a block diagram illustrating an example of a database cloud service multi-tenancy architecture that can be used in a cloud-based system where multiple schemas can be used within the same database instance, according to an embodiment of the invention. It is a block diagram which shows the example of a Nuviaq cloud system based on the Example of invention. 1 is a logical diagram of a cloud infrastructure system according to an embodiment of the present invention. 1 is a simplified block diagram of a hardware / software stack that can be used to implement a cloud infrastructure system according to an embodiment of the present invention. FIG. FIG. 20B is a simplified block diagram of a system environment for realizing the cloud infrastructure system shown in FIG. 20A. FIG. 6 illustrates a simplified flowchart illustrating processing that may be performed by a TAS module in a cloud infrastructure system according to an embodiment of the present invention. FIG. 4 shows a simplified high-level diagram of one or more submodules in a TAS module in a cloud infrastructure system according to an embodiment of the present invention. Fig. 3 illustrates an exemplary distributed deployment of TAS components according to an embodiment of the present invention. FIG. 4 is a simplified block diagram illustrating SDI module interaction with one or more modules in a cloud infrastructure system according to an embodiment of the present invention. FIG. 4 shows a simplified high level diagram of sub-modules of an SDI module according to an embodiment of the present invention. FIG. 6 illustrates a simplified flowchart illustrating processing that may be performed by an SDI component in a cloud infrastructure system according to an embodiment of the present invention. FIG. 2 shows a simplified block diagram illustrating a high level architecture of Nuviaq system and its relationship with other cloud infrastructure components according to an embodiment of the present invention. FIG. 4 shows an exemplary sequence diagram illustrating steps of a provisioning process using a Nuviaq system according to an embodiment of the present invention. FIG. 3 shows an exemplary sequence diagram illustrating the steps of a deployment process using a Nuviaq system according to an embodiment of the present invention. Fig. 4 illustrates an example of a database instance provisioned for a database service according to an embodiment of the present invention. It is a functional block diagram of the computing apparatus which concerns on one Example of this invention. FIG. 6 is a functional block diagram of a computing device according to another embodiment of the present invention. It is a functional block diagram of the computing apparatus which concerns on another Example of this invention.

DETAILED DESCRIPTION In the following description, for the purposes of explanation, specific details are set forth in order to provide a thorough understanding of embodiments of the invention. However, it will be apparent that the invention may be practiced without these specific details.

  Certain embodiments of the present invention provide techniques for automating the provisioning, management and tracking of services provided by a cloud infrastructure system.

  In a particular embodiment, a cloud infrastructure system is a self-service, subscription-based, elastically scalable, reliable, highly available, secure set of applications, middleware and Database service offerings may be included. An example of such a cloud infrastructure system is the Oracle public cloud provided by the assignee.

  The cloud infrastructure system provides the ability to provision, manage and track customer subscriptions for services and resources in the cloud infrastructure system, the ability to provide predictable work costs to customers using services in the cloud infrastructure system, The ability to provide robust identity domain separation and protection of customer data in cloud infrastructure systems, the ability to provide customers with a transparent architecture and control of cloud infrastructure system design, data protection assurance and data privacy standards To build and deploy services in cloud infrastructure systems, functions that provide customers with regulatory compliance Many features, including but not limited to the ability to provide customers with an integrated development experience and the ability to provide customers with seamless integration between business software, middleware, databases, and infrastructure services in a cloud infrastructure system Can be provided.

  In certain embodiments, services provided by cloud infrastructure systems include online data storage and backup solutions, web-based email services, hosted office suites and document collaboration services, database processing, managed technical support services, etc. It may include a plurality of services that are available on demand by users of cloud infrastructure systems. The services provided by the cloud infrastructure system can be dynamically scaled to meet the needs of its users. A specific instantiation of a service provided by a cloud infrastructure system is referred to herein as a service instance. In general, any service that a user can use from a cloud service provider system via a communication network such as the Internet is called a cloud service. In general, in a public cloud environment, the servers and systems that make up the cloud service provider's system are different from the customer's own on-premises servers and systems. For example, a cloud service provider's system can host an application and a user can order and use the application on demand via a communication network such as the Internet.

  Services in a computer network cloud infrastructure are provided to users by cloud vendors or otherwise protected to storage, hosted databases, hosted web servers, software applications or other services known in the art. Computer network access included. For example, a service may include password protected access to remote storage on the cloud over the Internet. As another example, a service may include a web service-based hosted relational database and scripting language middleware engine for private use by networked developers. As another example, the service may include access to an email software application hosted on a cloud vendor's website.

  FIG. 20A is a logical diagram of a cloud infrastructure system according to one embodiment of the present invention. The cloud infrastructure system 2000 may provide various services via a cloud or networked environment. These services include Software as a Service (SaaS) category, Platform as a Service (PaaS) category, Infrastructure as a Service (Infrastructure as a Service). a Service: IaaS) category, or may include one or more services provided under other categories of services including hybrid services. A customer may order one or more services provided by the cloud infrastructure system 2000 via a subscription order. The cloud infrastructure system 2000 then performs processing to provide services in the customer's subscription order.

  The cloud infrastructure system 2000 can provide cloud services through various deployment models. For example, the service is owned by an organization that sells cloud services (e.g., owned by Oracle), where the cloud infrastructure system 2000 is in a public cloud model where the service is available to general public enterprises or various industrial enterprises. May be provided below. As another example, the services are provided under a private cloud model where the cloud infrastructure system 2000 is operated solely for a single organization and can provide services to one or more entities within the organization. May be. The cloud service may also be provided under a community cloud model where the services provided by the cloud infrastructure system 2000 and system 200 are shared by several organizations in the associated community. The cloud service may also be provided under a hybrid cloud model that is a combination of two or more different models.

  As shown in FIG. 20A, the cloud infrastructure system 2000 may include multiple components that operate in concert that allow provisioning of services provided by the cloud infrastructure system 2000. 20A, the cloud infrastructure system 2000 includes a SaaS platform 2002, a PaaS platform 2004, an IaaS platform 2010, infrastructure resources 2006, and a cloud management function 2008. These components may be implemented in hardware or software or a combination thereof.

  The SaaS platform 2002 is configured to provide cloud services that fall into the SaaS category. For example, the SaaS platform 2002 may provide functionality for building and delivering a set of on-demand applications on an integrated development and deployment platform. The SaaS platform 2002 may manage and control the basic software and infrastructure for providing SaaS services. By utilizing the services provided by the SaaS platform 2002, customers can utilize applications running on the cloud infrastructure system 2000. Customers can obtain application services without the customer having to purchase separate licenses and support.

  A variety of different SaaS services can be provided. Examples include, but are not limited to, services that provide solutions for sales performance management, enterprise integration and business flexibility for large organizations. In one embodiment, the SaaS service includes a customer relationship management (CRM) service 2010 (eg, a fusion CRM service provided by Oracle Cloud), a human capital management (HCM) / talent management service 2012, etc. May be included. CRM services 2010 may include services directed to reporting and managing sales activity cycles to customers. HCM / talent services 2012 may include services directed to providing global workforce lifecycle management and talent management services to customers.

  A variety of different PaaS services can be provided by the PaaS platform 2004 in a standardized, shared, elastically scalable application development and deployment platform. Examples of PaaS services include services that allow organizations (such as Oracle) to aggregate existing applications on a shared common architecture, and new services that leverage shared services provided by the platform A function for building an application may be mentioned, but is not limited thereto. The PaaS platform 2004 may manage and control the basic software and infrastructure for providing PaaS services. The customer can obtain the PaaS service provided by the cloud infrastructure system 2000 without the customer having to purchase separate licenses and support. Examples of the PaaS service include, but are not limited to, an Oracle Java (registered trademark) cloud service (Java Cloud Service: JCS), an Oracle database cloud service (Oracle Database Cloud Service: DBCS), and the like.

  By utilizing the services provided by the PaaS platform 2004, customers can take advantage of programming languages and tools supported by the cloud infrastructure system 2000 and can also control deployed services. In some embodiments, the PaaS service provided by the cloud infrastructure system 2000 may include a database cloud service 2014, a middleware cloud service (eg, Oracle Fusion middleware service) 2016, and a Java cloud service 2017. . In one embodiment, the database cloud service 2014 may support a shared service deployment model that allows organizations to pool database resources and provide database as a service to customers in the form of a database cloud. The middleware cloud service 2016 provides a platform for customers to develop and deploy various business applications, and the Java cloud service 2017 provides a platform for customers to deploy Java applications in the cloud infrastructure system 2000. To do. The components in SaaS platform 2002 and PaaS platform 2004 shown in FIG. 20A are shown for illustrative purposes only and are not intended to limit the scope of embodiments of the present invention. In an alternative embodiment, SaaS platform 2002 and PaaS platform 2004 may include additional components for providing additional services to customers of cloud infrastructure system 2000.

  Various different IaaS services may be provided by the IaaS platform 2010. The IaaS service facilitates the management and control of basic computing resources such as storage, network and other basic computing resources for customers utilizing services provided by the SaaS platform and the PaaS platform. .

  In particular embodiments, cloud infrastructure system 2000 includes infrastructure resources 2006 for providing resources used to provide various services to customers of cloud infrastructure system 2000. In one embodiment, infrastructure resources 2006 include a pre-integrated, optimized combination of hardware such as servers, storage and networking resources to perform services provided by the PaaS platform and the SaaS platform. .

  In certain embodiments, the cloud management function 2008 provides comprehensive management of cloud services (eg, SaaS, PaaS, IaaS services) in the cloud infrastructure system 2000. In one embodiment, cloud management functionality 2008 includes functionality for provisioning, managing and tracking customer subscriptions received by cloud infrastructure system 2000, and so forth.

  FIG. 20B is a simplified block diagram of a hardware / software stack that may be used to implement a cloud infrastructure system 2000 according to an embodiment of the present invention. It should be understood that the implementation shown in FIG. 20B may have other components than those shown in FIG. 20B. Further, the embodiment shown in FIG. 20B is only one example of a cloud infrastructure system that can incorporate embodiments of the present invention. In some other examples, cloud infrastructure system 2000 may have more or fewer components than those shown in FIG. 20B, may combine two or more components, or components May have different configurations or arrangements. In particular embodiments, hardware and software components are stacked to provide vertical integration that provides optimal performance.

  Various types of users can interact with the cloud infrastructure system 2000. These users may include end users 2050 that may interact with the cloud infrastructure system 2000 using various client devices such as desktops, mobile devices, tablets, and the like. In addition, the user may use a command line interface (CLI), an application programming interface (CLI), through various integrated development environments (IDE), and through other applications. A developer / programmer 2052 that may interact with the cloud infrastructure system 2000 using an API). The user may also include an operation staff 2054. These may include staff of cloud service providers or staff of other users.

  Application service layer 2056 identifies various cloud services that may be provided by cloud infrastructure system 2000. These services are mapped to respective software components 2060 (eg, an Oracle web logic server for providing Java services, an Oracle database for providing database services, etc.) via a service integration and connectivity layer 2058, or Or it can be associated.

  In particular embodiments, several internal services 2062 that are shared by various components or modules of cloud infrastructure system 2000 and services provided by cloud infrastructure system 2000 may be provided. These internal shared services include security and identity services, integration services, enterprise repository services, enterprise manager services, virus scanning and whitelist services, high availability, backup and recovery services, services to enable cloud support in IDEs, This may include, but is not limited to, email services, notification services, file transfer services, and the like.

  The runtime infrastructure layer 2064 represents the hardware layer on which various other layers and components are built. In certain embodiments, the runtime infrastructure layer 2064 may comprise a single Oracle Exadata machine for providing storage, processing and networking resources. The Exadata machine can be composed of various database servers, storage servers, networking resources, and other components for hosting cloud service related software layers. In particular embodiments, Exadata machines can be designed to work with Oracle Exalogic, an engineered system that provides a collection of storage, computing, network and software resources. The combination of Exadata and Exalogic provides a complete hardware and software engineered solution that provides a high performance, highly available, scalable, secure, managed platform for delivering cloud services.

  FIG. 21 is a simplified block diagram of a system environment for realizing the cloud infrastructure system shown in FIG. 20A according to an embodiment of the present invention. In the illustrated example, system environment 2130 includes one or more client computing devices 2124, 2126, and 2128 that can be used by a user to interact with cloud infrastructure system 2000. The client device may be used by a user of the client device to interact with the cloud infrastructure system 2000 to utilize the services provided by the cloud infrastructure system 2000, a web browser, a proprietary client application (eg, Oracle Forms) or It may be configured to run client applications such as other applications.

  It should be understood that the cloud infrastructure system 2000 shown in FIG. 21 may have other components than those shown in FIG. Further, the embodiment shown in FIG. 21 is only one example of a cloud infrastructure system that can incorporate embodiments of the present invention. In some other embodiments, cloud infrastructure system 2000 may have more or fewer components than those shown in FIG. 21, may combine two or more components, or components May have different configurations or arrangements.

  Client computing devices 2124, 2126 and 2128 may be general purpose personal computers (including, by way of example, personal computers and / or laptop computers running various versions of Microsoft Windows® and / or Apple Macintosh operating systems), A mobile phone or PDA (running software such as Microsoft Windows Mobile, which is the Internet, email, SMS, Blackberry or any other communication protocol that can be used), such as various commercially available UNIX® or UNIX Operating system (including but not limited to various GNU / Linux operating systems) Workstation computers running one of the not be) or may be other computing devices. For example, client computing devices 2124, 2126, and 2128 are other electronic devices such as thin client computers that can communicate over a network, gaming devices capable of connecting to the Internet, and / or personal messaging devices. May be. Although an exemplary system environment 2130 is shown with three client computing devices, any number of client computing devices may be supported. Other devices, such as devices having sensors, may interact with the cloud infrastructure system 2000.

  Network 2132 may facilitate communication and exchange of data between clients 2124, 2126 and 2128 and cloud infrastructure system 2000. The network 2132 is familiar to those skilled in the art that may support data communications using any of a variety of commercially available protocols including but not limited to TCP / IP, SNA, IPX, AppleTalk, etc. It can be any type of network. By way of example only, network 2132 includes an Ethernet network, a local area network (LAN) such as a token ring network, a wide area network, or a virtual private network (VPN). But not limited to virtual networks, the Internet, intranets, extranets, public switched telephone networks (PSTN), infrared networks, wireless networks (eg IEEE 802.1X series of protocols, known in the art) Network that operates under any of the Bluetooth® protocols and / or other wireless protocols), and / or these and / or other It may be any combination of network.

  The cloud infrastructure system 2000 includes general-purpose computers, specialized server computers (including PC servers, UNIX servers, midrange servers, mainframe computers, rack mount servers, etc.), server farms, server clusters, or others. One or more computers and / or servers may be provided, which may be any suitable arrangement and / or combination. The computing devices that make up the cloud infrastructure system 2000 may include any of the operating system or various additional server applications and / or middle tier applications, including HTTP servers, FTP servers, CGI servers, Java servers, database servers, etc. Can be executed. Exemplary database servers include, but are not limited to, those commercially available from Oracle, Microsoft, Sybase, IBM, and the like.

  In various embodiments, the cloud infrastructure system 2000 may be adapted to automatically provision, manage and track customer subscriptions to services provided by the cloud infrastructure system 2000. In one embodiment, as shown in FIG. 21, the components in the cloud infrastructure system 2000 are an identity management (IDM) module 2100, a service module 2102, and a tenant automation system (TAS) module. 2104, Service Deployment Infrastructure (SDI) module 2106, Enterprise Manager (EM) module 2108, store user interface (UI) 2110, cloud user interface (UI) 2112 and support One or more front-end web interfaces, such as a user interface (UI) 2116, and an order tube Includes a module 2114, and sales staff 2118, the operator staff 2120, and an order database 2142. These modules may include one or more computers and / or servers, which may be general purpose computers, specialized server computers, server farms, server clusters, or other suitable arrangements and / or combinations. May be provided using. In one embodiment, one or more of these modules may be provided by the cloud management function 2008 or the IaaS platform 2010 in the cloud infrastructure system 2000. The various modules of the cloud infrastructure system 2000 shown in FIG. 21 are shown for illustrative purposes only and are not intended to limit the scope of embodiments of the present invention. Alternative embodiments may include more or fewer modules than those shown in FIG.

  In an exemplary operation, in (1), a customer using a client device, such as client device 2124 or 2126, browses various services provided by cloud infrastructure system 2000 and is provided by cloud infrastructure system 2000. One can interact with the cloud infrastructure system 2000 by placing an order for a subscription for one or more services. In certain embodiments, a customer may access store UI 2110 or cloud UI 2112 and place a subscription order through these user interfaces.

  The order information received by the cloud infrastructure system 2000 in response to the customer placing an order includes the customer and one or more services provided by the cloud infrastructure system 2000 that the customer intends to subscribe to. The information to identify may be included. A single order may include orders for multiple services. For example, a customer may log in to the cloud UI 2112 and request a subscription for CRM service and Java cloud service in the same order.

  In addition, the order may also include one or more service levels for the ordered service. As used herein and described in more detail below, the service level for a service depends on the service requested in the context of the subscription, such as the amount of storage, the amount of computing resources, data transfer facilities, etc. Determine the amount of resources allocated to provide For example, a basic service level may provide a minimum level of storage, data transmission, or number of users, and a higher service level may include additional resources.

  Also, in some examples, the order information received by the cloud infrastructure system 2000 may include information indicating the customer level and the time period for which service is desired. The customer level defines the priority of customers making subscription requests. In one example, the priority is a service that the cloud infrastructure system 2000 guarantees or promises to the customer as defined by a Service Level Agreement (SLA) agreed between the customer and the cloud service provider. Can be determined based on quality. In one example, the various customer levels include a basic level, a silver level, and a gold level. The service period may specify the start date and time of the service and the period for which the service is required (for example, the service end date and time may be specified).

  In one example, the customer may request a new subscription via the store UI 2110 or request a trial subscription via the cloud UI 2112. In certain embodiments, the store UI 2110 may correspond to a service provider's e-commerce storefront (eg, www.oracle.com/store for an Oracle cloud service). Cloud UI 2112 may represent a business interface for a service provider. Customers can research available services and sign up for services of interest via the cloud UI 2112. Cloud UI 2112 captures the user input required to order a trial subscription provided by cloud infrastructure system 2000. The cloud UI 2112 can also be used to view account functions and configure a runtime environment located within the cloud infrastructure system 2000. In addition to placing orders for new subscriptions, the store UI 2110 can also change subscription service levels, extend the duration of subscriptions, improve subscription service levels, terminate existing subscriptions, etc. It may also allow customers to perform subscription related tasks.

  After the order is placed for (1), in (2), order information received via either the store UI 2110 or the cloud UI 2112 is stored in the order database 2142, and the order database 2142 is stored in the cloud infrastructure system 2000. It can be one of several databases that are manipulated by and used in conjunction with other system elements. Although the order database 2142 is logically shown in FIG. 21 as a single database, in an actual implementation this may comprise one or more databases.

  In (3), the order is sent to the order management module 2114. Order management module 2114 is configured to perform billing and accounting functions associated with orders, such as order validation and order reservation at validation. In particular embodiments, order management module 2114 may include a contract management module and an install base module. The contract management module may store contract information associated with a customer subscription order, such as a customer service level agreement (SLA) with the cloud infrastructure system 2000. The installed base module may include a detailed description of the service in the customer's subscription order. In addition to order information, the install base module may track installation details associated with the service, product status and support service history associated with the service. When a customer orders a new service or upgrades an existing one, the installed base module can automatically add new order information.

  In (4), information regarding the order is communicated to the TAS module 2104. In one embodiment, the TAS module 2104 utilizes order information to orchestrate service and resource provisioning for orders placed by customers. In (5), the TAS component 2104 orchestrates the provisioning of resources to support services subscribed using the services of the SDI module 2106. In (6), the TAS module 2104 provides the service module 2102 with information related to the provisioned order received from the SDI module 2106. In some embodiments, at (7), the SDI module 2106 may also use the services provided by the service module 2102 to allocate and configure the resources necessary to realize the customer's subscription order. .

  At (8), the service module 2102 sends a notification regarding the status of the order to the customer on the client devices 2124, 2126 and 2128.

  In particular embodiments, the TAS module 2104 functions as an orchestration component that manages business processes associated with each other and applies business logic to determine whether an order should proceed to provisioning. In one embodiment, upon receiving an order for a new subscription, the TAS module 2104 requests the SDI module 2106 to allocate resources and configure those resources necessary to fulfill the subscription order. Send. The SDI module 2106 enables allocation of resources for services ordered by customers. The SDI module 2106 provides a level of abstraction between the cloud service provided by the cloud infrastructure system 2000 and the physical implementation layer used to provision the resources to provide the requested service. To do. Thus, the TAS module 2104 can be decoupled from implementation details such as whether services and resources are actually provisioned on-the-fly, or whether they are pre-provisioned and simply allocated / assigned on demand.

  In certain embodiments, the user may use the store UI 2110 to interact directly with the order management module 2114 to perform billing and accounting related functions such as order validation and order reservation during validation. In some embodiments, instead of the customer placing an order, in (9) the order may instead be placed by a sales staff 2118 representing the customer, such as a customer service representative or sales representative. . Sales staff 2118 may interact directly with order management module 2114 via a user interface (not shown in FIG. 21) provided by order management module 2114 to place an order or provide a quote to a customer. . For example, this can be done for large customers where orders can be placed by customer sales representatives via order management module 2114. The sales representative may prepare a subscription on behalf of the customer.

  The EM module 2108 is configured to monitor activities related to managing and tracking customer subscriptions in the cloud infrastructure system 2000. The EM module 2108 collects usage statistics for services in the subscription order, such as the amount of storage used, the amount of data transferred, the number of users, the amount of system up time and system down time. In (10), the host operator staff 2120, who may be an employee of the provider of the cloud infrastructure system 2000, is responsible for managing the systems and resources for which services are provisioned within the cloud infrastructure system 2000. The EM module 2108 may be interacted via an interface (not shown in FIG. 21).

  Identity management (IDM) module 2100 is configured to provide identity services, such as access management and authorization services, in cloud infrastructure system 2000. In one embodiment, the IDM module 2100 controls information about customers who want to use services provided by the cloud infrastructure system 2000. Such information includes information that authenticates the identity of such customers, and what actions they perform on various system resources (eg, files, directories, applications, communication ports, memory segments, etc.) Information may be included that indicates whether the authorization is permitted. The IDM module 2100 may also include managing descriptive information about each customer and descriptive information about how the descriptive information can be accessed and modified by whom.

  In one embodiment, information managed by the identity management module 2100 can be partitioned to create a separate identity domain. Information belonging to a particular identity domain can be separated from all other identity domains. An identity domain can also be shared by multiple separate tenants. Each such tenant may be a customer that subscribes to services in the cloud infrastructure system 2000. In some examples, a customer can have one or many identity domains, each identity domain can be associated with one or more subscriptions, and each subscription can have one or more subscriptions. Have service. For example, a single customer may correspond to a large business entity, and an identity domain may be created for a department / department within this large business entity. Further, EM module 2108 and IDM module 2100 may interact with order management module 2114 at (11) and (12), respectively, to manage and track customer subscriptions in cloud infrastructure system 2000.

  In one embodiment, support services may also be provided to the customer via the support UI 2116 at (13). In one embodiment, the support UI 2116 allows support staff to interact with the order management module 2114 via a support back-end system to perform support services at (14). Support staff and customers in the cloud infrastructure system 2000 can submit bug reports and check the status of these reports via the support UI 2116.

  Other interfaces not shown in FIG. 21 may also be provided by the cloud infrastructure system 2000. For example, an identity domain administrator may use a user interface to IDM module 2100 to configure domain and user identities. The customer can also log into a separate interface for each service that they want to use. In particular embodiments, customers who wish to subscribe to one or more services provided by cloud infrastructure system 2000 may also be assigned various roles and missions. In one embodiment, the various roles and missions that can be assigned to a customer are for buyers, account administrators, service administrators, identity domain administrators, or users utilizing services and resources provided by cloud infrastructure system 2000. May include roles and missions. The various roles and missions are more fully shown in FIG. 23 below.

  FIG. 22A shows a simplified flowchart 2200 illustrating processing that may be performed by a TAS module in a cloud infrastructure system according to an embodiment of the present invention. The processing illustrated in FIG. 22A may be implemented by software (eg, code, instructions, program) executed by one or more processors, hardware, or a combination thereof. The software may be stored in memory (eg, on a memory device, non-transitory computer readable storage medium). The particular series of processing steps shown in FIG. 22A is not intended to be limiting. Other sequences of steps may also be performed according to alternative embodiments. For example, alternative embodiments of the invention may perform the above steps in a different order. Further, the individual steps shown in FIG. 22A may include multiple sub-steps that may be performed in various sequences as appropriate to the individual steps. Furthermore, additional steps may be added or deleted depending on the particular application. Those skilled in the art will recognize many variations, modifications and alternatives. In one example, the process shown in FIG. 22A may be performed by one or more components in TAS component 2104, as shown in detail in FIG. 22B.

  At 2202, a customer subscription order is processed. In one example, the process may include order authentication. Order verification ensures that the customer has paid for the subscription and ensures that the customer does not yet have a subscription with the same name, or Including ensuring that the customer does not attempt to create multiple subscriptions of the same type in the same identity domain for unauthorized subscription types. Processing may also include order status tracking for each order being processed by the cloud infrastructure system 2000.

  At 2204, a business process associated with the order is identified. In some examples, multiple business processes may be identified for an order. Each business process identifies a series of steps for processing various aspects of the order. As an example, a first business process may identify one or more steps associated with provisioning physical resources for an order, and a second business process creates an identity domain along with a customer identity for the order One or more steps related to doing can be identified, and the third business process is related to performing back office functions such as creating customer records for users, performing accounting functions related to orders, etc. One or more steps may be identified. In particular embodiments, various business processes may also be identified to handle various services in the order. For example, various business processes may be identified to handle CRM services and database services.

  At 2206, the business process identified for the order at 2204 is executed. Execution of the business process associated with the order may include an orchestration of a series of steps associated with the business process identified in step 2204. For example, the execution of a business process related to provisioning physical resources for an order sends a request to the SDI module 2106 to allocate resources and configure those resources necessary to fulfill a subscription order. It may include.

  At 2208, a notification is sent to the customer regarding the status of the provisioned order. Further explanation relating to the execution of steps 2202, 2204, 2206 and 2208 is described in detail in FIG. 22B.

  FIG. 22B shows a simplified high-level diagram of one or more submodules in a TAS module in a cloud infrastructure system according to an embodiment of the present invention. In one embodiment, the module shown in FIG. 22B performs the process described in steps 2202-308 shown in FIG. 22A. In the illustrated embodiment, the TAS module 2104 includes an order processing module 2210, a business process identifier 2212, a business process executor 2216, an excess framework 2222, a workflow identification module 2224, and a bundled subscription generation module 2226. With. These modules may be implemented in hardware or software or a combination thereof. The various modules of the TAS module shown in FIG. 22B are shown for illustrative purposes only and are not intended to limit the scope of embodiments of the present invention. Alternative embodiments may include more or fewer modules than those shown in FIG. 22B.

  In one embodiment, order processing module 2210 receives orders from customers from one or more input sources 2221. For example, the order processing module 2210 may receive orders directly via the cloud UI 2112 or the store UI 2110 in one embodiment. Alternatively, order processing module 2210 may receive orders from order management module 2114 or order database 2142. The order processing module 2210 then processes the order. In a particular embodiment, the processing of an order is a customer record that contains information about the order, such as service type, service level, customer level, resource type, amount of resources allocated to a service instance, and the period for which service is required. Includes generation. As part of the process, order processing module 2210 also determines whether the order is a valid order. This ensures that the customer does not yet have a subscription with the same name, or multiple of the same type in the same identity domain for unauthorized subscription types (such as in the case of a fusion CRM service) Including ensuring that the customer has not attempted to create a subscription.

  The order processing module 2210 may also perform further processing on the order. Processing may include order status tracking for each order being processed by the cloud infrastructure system 2000. In one example, order processing module 2210 may process each order to identify a number of conditions related to the order. In one example, the various states of the order can be an initialization state, a provisioning state, an active state, a state that requires management, an error state, and so on. The initialization state refers to the state of the new order, and the provisioning state refers to the state of the order when the services and resources for the order are provisioned. Once the order is processed by the TAS module 2104 and a notice to that effect is given to the customer, the order becomes active. An order is in a state that needs to be managed if an administrator intervention is required to solve the problem. If the order cannot be processed, the order is in error. In addition to maintaining the order progress state, the order processing module 2210 maintains detailed information about any failures encountered during the execution of the process. In other embodiments, as described in detail below, further processing performed by the order processing module 2210 may include changing the service level of a service in a subscription, changing a service included in a subscription, It may also include extending the period and specifying different service levels over different periods in the cancellation or subscription of the subscription.

  After the order is processed by the order processing module 2210, business logic is applied to determine whether the order should proceed to provisioning. In one embodiment, as part of an order orchestration, the business process identifier 2212 receives processed orders from the order processing module 2210 and applies business logic to identify specifics to be used in the order being processed. Identify business processes. In one example, business process identifier 2212 may utilize information stored in service catalog 2214 to determine a particular business process to be used in the order. In one example, as shown in FIG. 22A, multiple business processes may be identified for an order, each business process identifying a series of steps for processing various aspects of the order. In another example, as described above, different business processes may be defined for different types of services or combinations of services, such as CRM services or database services. In one example, the service catalog 2214 may store information that maps orders to specific types of business processes. Business process identifier 2212 may use this information to identify a particular business process for the order being processed.

  Once the business process is identified, the business process identifier 2212 communicates the specific business process to be executed to the business process executor 2216. The business process executor 2216 then performs the identified business process steps by operating in conjunction with one or more modules in the cloud infrastructure system 2000. In some embodiments, the business process executor 2216 serves as an orchestrator to perform the steps associated with the business process. For example, the business process executor identifies the workflow associated with the order and determines an excess of service in the order, or executes the steps in the business process that identify the service component associated with the order. Can interact with 2210.

  In one example, the business process executor 2216 interacts with the SDI module 2106 to perform the steps in the business process for allocating and provisioning resources for the requested service in the subscription order. In this example, for each step in the business process, business process executor 2216 may send a request to SDI component 2106 to allocate resources and configure the resources necessary to implement a particular step. . The SDI component 2106 is responsible for the actual allocation of resources. Once all the steps of the order business process have been executed, the business process executor 2216 may send a notification of the processed order to the customer by utilizing the service of the service component 2102. The notification may include sending an email notification with the details of the processed order to the customer. The email notification may also include deployment information associated with the order to allow the customer to access the subscribed service.

  In certain embodiments, the TAS module 2104 may include one or more TAS application programming that allows the TAS module 2104 to interact with other modules in the cloud infrastructure system 2000 and allow other modules to interact with the TAS module 2104. An interface (Application Programming Interface: API) 2218 may be provided. For example, the TAS API interacts with the SDI module 2106 via an asynchronous Simple Object Access Protocol (SOAP) based web service call to provision resources for customer subscription orders. A system provisioning API to be included. In one embodiment, the TAS module 2104 may also utilize the system provisioning API to accomplish the creation and deletion of systems and service instances, switch service instances to enhanced service levels, and associate service instances. An example of this is the association of a Java service instance to a fusion application service instance to enable secure web service communication. The TAS API may also include a notification API that interacts with the service module 2102 to notify the customer of the processed order. In certain embodiments, the TAS module 2104 also periodically communicates subscription information, outages and notifications (eg, planned downtime) to the service component 2102.

  In particular embodiments, the TAS module 2104 uses the amount of storage used, the amount of data transferred, the number of users, and the usage for each provisioned service, such as the amount of system up and system down time. Statistics are received periodically from the EM module 2108. The excess framework 2222 determines whether overuse of the service has occurred and, if so, uses the usage statistics to determine how much is charged for the excess and orders this information. To the management module 2114.

  In certain embodiments, the TAS module 2104 includes an order workflow identification module 2224 that is configured to identify one or more workflows associated with processing a customer's subscription order. In particular embodiments, the TAS module 2104 may generate a subscription order for a customer when the customer places a subscription order for one or more services provided by the cloud infrastructure system 2000. A generation framework 2226 may be included. In one embodiment, the subscription order includes one or more service components responsible for providing the services requested by the customer in the subscription order.

  Further, the TAS module 2104 may provide a tenant information system to allow provisioning of resources for one or more services subscribed to by a customer, taking into account historical information available to the customer, if any. One or more additional databases, such as a (Tenant Information System: TIS) database 2220 may also be interacted with. The TIS database 2220 may include historical order information and historical usage information related to orders subscribed by the customer.

  The TAS module 2104 can be deployed using various deployment models. In certain embodiments, a deployment includes a central component that interacts with one or more distributed components. Distributed components may be deployed, for example, as various data centers and therefore may also be referred to as data center components. The central component includes functions for processing orders and organizing services in the cloud infrastructure system 2000, and the data center component is functions for provisioning and operating a runtime system that provides resources to subscribed services. I will provide a.

  FIG. 23 illustrates an exemplary distributed deployment of TAS modules according to an embodiment of the present invention. In the example shown in FIG. 23, the distributed deployment of the TAS module 2104 includes a TAS center component 2300 and one or more TAS data center (DC) components 2302, 2304, and 2306. These components may be implemented in hardware or software or a combination thereof.

  In one embodiment, the task of the TAS-centric component 2300 is to receive a customer order and create a new subscription, change the service level of the service in the subscription, change the service included in the subscription, and the duration of the subscription Including, but not limited to, providing a centralized component for performing order-related business operations such as extension of subscriptions or cancellation of subscriptions. Also, the task of the TAS-centric component 2300 is to maintain and supply the subscription data required by the cloud infrastructure system 2000, and to handle all back office interactions, an order management module 2114, a support UI 2116, Interacting with the cloud UI 2112 and the store UI 2110 may also be included.

  In one embodiment, the duties of TAS DCs 2302, 2304, and 2306 include performing runtime operations to orchestrate the provisioning of resources for one or more services subscribed to by a customer. It is not limited. TAS DC 2302, 2304, and 2306 also perform operations such as subscription order locking, unlocking, enabling or disabling, order related metrics collection, order status determination, and order related notification event transmission. The function for executing is also included.

  In the exemplary operation of the distributed TAS system shown in FIG. 23, the TAS-centric component 2300 is initially sent via the cloud UI 2112, the store UI 2110, the order management system 2114, or the order database 2142. Receive orders from customers. In one embodiment, a customer represents a buyer who has the authority to order and / or change financial information and subscriptions. In one embodiment, the order information includes information identifying the customer, the type of service that the customer wants to subscribe to, and the account administrator responsible for handling the request. In certain embodiments, an account administrator may be appointed by a customer when the customer places an order for a subscription to one or more services provided by the cloud infrastructure system 2000. Based on the order information, the TAS-centric component 2300 can determine whether the order originates in the world, such as the United States, EMEA, or Asia Pacific, and the specific TAS DC (eg, 2302, 2304, or 2306) deployed to provision the order. ). In one embodiment, the particular TAS DC (eg, from within DC 2302, 2304, or 2306) deployed to provision an order is determined based on the geographic data region where the request originated.

  The TAS central component 2300 then sends the order request to a specific TAS DC to provision a service for the order request. In one embodiment, the TAS DC 2302, 2304 or 2306 identifies the service administrator and identity domain administrator responsible for processing order requests at a particular TAS DC. Service administrators and identity managers can be appointed by account administrators identified in the subscription order. The TAS DC 2302, 2304 or 2306 communicates with the SDI module 2104 to orchestrate provisioning of physical resources for the order. The SDI component 2104 in each TAS DC 2302, 2304 or 2306 allocates resources and configures those resources necessary to fulfill the subscription order.

  In certain embodiments, TAS DC 2302, 2304 or 2306 identifies the identity domain associated with the subscription. The SDI component 2106 may provide identity domain information to the IDM component 200 (shown in FIG. 21) for identification of an existing identity domain or creation of a new identity domain. Once the order is provisioned by the SDI module in the respective TAS DC 2302, 2304 or 2306, the TAS-centric component 2300 may place information about provisioned resources in the support system via the support UI 2116. The information may include, for example, a display of resource metrics and service usage statistics associated with the service.

  During operation, at each data center, the EM module 2108 performs the amount of storage used, the amount of data transferred, the number of users, and system up time for each provisioned service provisioned at that data center. And regularly collect usage statistics such as the amount of system downtime. These statistics are provided to the TAS DC that is local to the EM module 2108 (ie, in the same data center). In an embodiment, the TAS DC determines whether overuse of the service has occurred and, if so, uses usage statistics to determine how much is charged for overuse, The order management system 2114 may be provided.

  FIG. 24 is a simplified block diagram illustrating SDI module interaction with one or more modules in a cloud infrastructure system according to an embodiment of the present invention. In one embodiment, the SDI module 2106 interacts with the TAS module 2104 to provision resources for service in the subscription order received by the TAS module 2104. In particular embodiments, one or more of the modules shown in FIG. 24 may be a module in cloud infrastructure system 2000. In other embodiments, one or more of the modules that interact with the SDI module 2106 may be external to the cloud infrastructure system 2000. Alternate embodiments may also have more or fewer modules than those shown in FIG. These modules may be implemented in hardware or software or a combination thereof.

  In one embodiment, the modules in SDI module 2106 may include one or more modules in SaaS platform 2002 and PaaS platform 2004 in cloud infrastructure system 2000. To provision resources for various services, the SDI module 2106 may interact with various other modules, each customized to help provision resources for a particular type of service. For example, as shown in FIG. 24, the SDI module 2106 may interact with a Java service provisioning control module 2400 to provision a Java cloud service. In one embodiment, the Java service provisioning control component 2400 deploys a Java Cloud Service (JCS) assembly defined by an SDI module 2106 that includes a set of tasks that are performed to provision a Java cloud service. Can do. The infrastructure resource 2006 then determines the resources required to provision the Java cloud service.

  As another example, the SDI module 2106 includes a virtual assembly builder (VAB) module 2402, an application express (APEX) deployer module 2404, a virtual machine (VM) module 2406, an IDM. One or more modules such as module 2100 and database machine module 2018 may interact. VAB module 2402 includes functionality for configuring and provisioning a complete multi-tier application environment. In one embodiment, the VAB module 2402 is a MW service defined by the SDI module 2106 to provision a middleware (MW) service in the cloud infrastructure system 2000 using the service provided by the VM module 2406. Deploy the assembly. The APEX deployer module 2404 includes functionality for configuring and provisioning database services. In one embodiment, the APEX deployer module 2404 deploys a database service assembly defined by the SDI module 2106 to provision a database service in the cloud infrastructure system 2000 using resources provided by the infrastructure resource 2006. To do. The SDI module 2106 interacts with the IDM module 2100 to provide identity services such as access management across multiple applications in the cloud infrastructure system 2000.

  FIG. 25 shows a simplified high-level diagram of submodules of an SDI module according to an embodiment of the present invention. In the embodiment shown in FIG. 25, SDI module 2106 includes SDI-Web Service (WS) module 2500, SDI request controller module 2502, SDI task manager module 2504, SDI monitoring module 2506, and SDI data. An access module 2508, an SDI common library module 2510, and an SDI connector module 2512 are included. These modules may be implemented in hardware or software or a combination thereof. The SDI module 2106 and its various modules shown in FIG. 25 are shown for illustrative purposes only and are not intended to limit the scope of embodiments of the present invention. Alternative embodiments may have more or fewer modules than those shown in FIG. These modules and their functions are described in detail below.

  The SDI-WS module 2500 includes functionality for receiving steps in the business associated with the order from the business process executor 2216 of the TAS component 2104. In one embodiment, the SDI-WS module 2500 parses each step of the business process and converts the step into an internal representation used by the SDI module 2106. In one embodiment, each step of the business process associated with the order is performed in the form of a SOAP request to the SDI-WS module 2500 via the web service processing layer (eg, via the system provisioning API shown in FIG. 22B). )arrive.

  The SDI request controller module 2502 is an internal request processing engine in the SDI module 2106, and functions for executing asynchronous request processing, simultaneous request processing, simultaneous task processing, fault tolerant recovery related to order requests, and plug-in support. including. In one embodiment, the SDI request controller module 2502 accepts each step of the business process associated with the order from the SDI-WS module 2500 and submits the step to the SDI task manager module 2504.

  The SDI task manager module 2504 converts each step defined in the business process into a series of tasks for provisioning a particular step. Once a set of tasks for a particular step has been provisioned, the SDI task manager module 2504 provides the TAS module 2104 with an operation result that includes an order payload with the details of the resources provisioned to implement the particular step. In response to the business process executor 2216 at. The SDI task manager module 2504 repeats this process until all steps of the specific business process associated with the order are completed.

  In a particular embodiment, the SDI task manager module 2504 transforms each step defined in the business process into a series of tasks by utilizing the services of the SDI connector module 2512. The SDI connector module 2512 includes one or more connectors for addressing the deployment of tasks defined by the SDI task manager module 2504 to provision one or more services associated with order requests. In particular embodiments, one or more of the connectors can handle tasks specific to a particular service type, and other connectors can handle common tasks across various service types. In one embodiment, the SDI connector module 2512 interacts with one or more of the external modules (shown in FIG. 24) in the cloud infrastructure system 2000 to provision services and resources related to order requests. Includes connector (wrapper API). For example, Application Express (APEX) connector 2514 interacts with APEX deployer module 2404 to provision database services. A web center connector 2516 (Web Center Connector: WCC) interacts with a web center module in the cloud infrastructure system 2000 to provision web services. The web center module is a user engagement platform and includes functions for providing connectivity between people and information in the cloud infrastructure system 2000.

  In certain embodiments, a Middleware Application (MA) connector 2518 interacts with the VAB module 2402 in the cloud infrastructure system 2000 to provision middleware application services. The NUVIAQ connector 2520 interacts with the VAB module 2402 to provision Java services. The IDM connector 2522 interacts with the IDM module 2100 to provide identity and access management to users who subscribe to services and resources in the cloud infrastructure system 2000. Virtual assembly builder (VAB) connector 2524 interacts with VAB module 2402 in cloud infrastructure system 2000 to configure and provision a complete multi-tier application environment. Plug-in connector 2526 interacts with EM module 2108 to manage and monitor components in cloud infrastructure system 2000. The HTTP server connector 2528 interacts with one or more web servers in the PaaS platform to provide connection services to users in the cloud infrastructure system 2000.

  The SDI monitoring module 2506 in the SDI module 2106 provides an inbound interface for receiving Java Management Extensions (JMX) requests. The SDI monitoring module 2506 also provides tools for managing and monitoring applications, system objects and devices in the cloud infrastructure system 2000. The SDI data access module 2508 provides an inbound interface for receiving Java Database Connectivity (JDBC) requests. The SDI data access module 2508 supports data access in the cloud infrastructure system 2000 and provides object relationship mapping, Java transaction API service, data access object, and connection pooling. The SDI common library module 2510 provides configuration support for modules in the SDI module 2106.

  The above embodiment of FIG. 25 describes the modules in the SDI module according to the embodiment of the present invention. FIG. 26A shows a simplified flowchart 2600 illustrating processing that may be performed by modules of an SDI module in a cloud infrastructure system according to an embodiment of the present invention. The processing illustrated in FIG. 26A may be implemented by software (eg, code, instructions, program) executed by one or more processors, hardware, or a combination thereof. The software may be stored in memory (eg, on a memory device, non-transitory computer readable storage medium). The particular series of processing steps shown in FIG. 26A is not intended to be limiting. Other sequences of steps may also be performed according to alternative embodiments. For example, alternative embodiments of the invention may perform the above steps in a different order. Furthermore, the individual steps shown in FIG. 26A may include multiple sub-steps that may be performed in various sequences as appropriate to the individual steps. Furthermore, additional steps may be added or deleted depending on the particular application. Those skilled in the art will recognize many variations, modifications and alternatives. In one embodiment, the process shown in FIG. 26A may be performed by one or more modules in SDI module 2106 shown in detail in FIG.

  At 2602, a business process associated with a subscription order is received. In one embodiment, the SDI-WS module 2500 in the SDI module 2106 receives one or more steps in the business process associated with the subscription order from the business process executor 2216. At 2604, each step in the business process is converted into a series of tasks for provisioning resources for the subscription order. In one embodiment, the SDI task manager module 2504 in the SDI module 2106 converts each step defined in the business process into a series of tasks by utilizing the services of the SDI connector module 2512. At 2606, the subscription order is provisioned based on a series of tasks. In one embodiment, as shown in FIG. 25, the SDI connector module 2512 handles the deployment of tasks defined by the SDI task manager module 2504 to provision resources for services in the subscription order. One or more connectors.

  As described above with respect to FIG. 25, the SDI task manager module 2504 uses the services of the SDI connector module 2512 to convert each step defined in the business process into a series of tasks, and the SDI connector module 2512 One or more connectors for addressing the deployment of tasks defined by the SDI task manager module 2504 may be included to provision one or more services associated with the request. One or more of the connectors can handle tasks that are specific to a particular service type, and other connectors can handle tasks that are common across various service types. In one embodiment, the SDI connector module 2512 interacts with one or more of the external modules (shown in FIG. 24) in the cloud infrastructure system 2000 to provision services and resources related to order requests. Includes connector (wrapper API). For example, NUVIAQ connector 2520 interacts with VAB module 2402 to provision Java services.

  FIG. 26B shows a simplified block diagram illustrating a high level architecture of Nuviaq system 2610 and its relationship with other cloud infrastructure systems according to an embodiment of the present invention. It should be understood that the Nuviaq system 2610 shown in FIG. 26B may have other components than those shown in FIG. 26B. Further, the embodiment shown in FIG. 26B is only one example of a cloud infrastructure system that can incorporate embodiments of the present invention. In some other embodiments, Nuviaq system 2610 may have more or fewer components than those shown in FIG. 26B, may combine two or more components, or have different components It may have a configuration or an arrangement.

  In certain embodiments, Nuviaq system 2610 may be configured to provide a runtime engine for orchestrating PaaS operations. Nuviaq system 2610 may provide a web service API to facilitate integration with other products and services. Nuviaq system 2610 also provides support for complex workflows in system provisioning, application deployment and associated lifecycle operations, and integrates with management and monitoring solutions.

  In the example shown in FIG. 26B, the Nuviaq system 2610 includes a Nuviaq proxy 2612, a Nuviaq manager 2614, and a Nuviaq database 2616. In certain embodiments, Nuviaq manager 2614 provides an entry point to Nuviaq system 2610 and provides secure access to PaaS operations via a web service API. Internally, Nuviaq manager 2614 keeps track of system state in the database and controls the execution of jobs on the workflow engine. In the public cloud, Nuviaq manager 2614 can be accessed by the tenant provisioning system (SDI 2106) and the tenant console to drive provisioning and deployment operations, respectively.

  In one embodiment, Nuviaq manager 2614 executes jobs asynchronously via an internal workflow engine. A job may be a sequence of actions specific to a given PaaS workflow. Actions may be executed in order, and failure at any step results in failure of the entire job. Many workflow actions delegate authority to external systems associated with the workflow, such as the EM command line interface (cli). In one implementation, the Nuviaq manager 2614 application may be hosted in a 21-node web logic cluster with an associated HTTP server (eg, Oracle HTTP server or OHS) instance running within the firewall.

  In a particular embodiment, Nuviaq proxy 2612 is a public access point to Nuviaq API. In one embodiment, only public APIs can be published here. Requests received by proxy 2612 may be sent to Nuviaq manager 2614. In one embodiment, Nuviaq proxy 2612 runs outside the firewall, while manager 2614 runs inside the firewall. In one implementation, the Nuviaq proxy 2612 application runs on a web logic cluster that runs outside the firewall.

  In particular embodiments, Nuviaq database 2616 tracks various domain entities such as, but not limited to, platform instances, deployment plans, applications, web logic domains, jobs, alerts, and the like. If necessary, the primary key may be aligned with the service database.

  In one embodiment, platform instance 2618 may include all resources necessary for web logic services for a given tenant.

  Nuviaq system 2610 may rely on additional systems of cloud infrastructure system 2000 to execute workflows used by web logic cloud services. These dependencies may include dependencies on SDI 2106, IDM 2100, virus scanning system, service database, CRM instance, and the like. For example, Nuviaq system 2610 may rely on functions performed by an assembly deployer in SDI 2106. In one embodiment, the assembly deployer is a system for managing interactions with OVAB (Oracle Virtual Assembly Builder) and OVM (Oracle Virtual Machine). Assembly deployer functions used by Nuviaq system 2610 may include functions for deploying assemblies, functions for undeploying assemblies, functions for describing assembly deployment, functions for scaling appliances, etc. However, it is not limited to these. In one implementation, the Nuviaq system 2610 accesses the assembly deployer via a web service API.

  In certain embodiments, the security policy may require that certain artifacts be scanned for viruses before being deployed to the application. The cloud infrastructure system 2000 may provide a virus scanning system for this purpose, providing scanning as a service for multiple components of the public cloud.

  In certain embodiments, the public cloud infrastructure may maintain a service database that includes information about tenants (eg, customers) and their service subscriptions. The Nuviaq workflow may access this data to properly configure the web logic service as a client to other services that the tenant also subscribes to.

  Nuviaq system 2610 may rely on IDM 2100 for its security integration. In certain embodiments, a Java service instance may be associated with a CRM instance. With this association, a user application deployed on the Java service instance can access the CRM instance via a web service call.

  Various entities may use the services provided by Nuviaq system 2610. These clients of the Nuviaq system 2610 include a tenant console, which is a management server (eg, Oracle management server) based user interface that customers can access to manage applications on platform instances, and access to application lifecycle management operations. Several IDEs, such as Oracle IDEs (JDeveloper, NetBeans, and OEPE) that have been extended to provide one and more command line interfaces (Command Line) that can be used to access lifecycle operations on platform instances Interface: CLI).

The provisioning use case for the Nuviaq system 2610, ie the provisioning platform instance use case, is realized by the Nuviaq API creation platform instance operation. In the context of the cloud infrastructure system 2000, a service instance for a Nuviaq system corresponds to a Nuviaq platform instance. A platform instance is assigned a unique identifier that is used on all subsequent operations associated with this instance. The platform deployment descriptor provided in the create platform instance action allows you to set properties that modify the configuration of the platform instance to meet tenant subscription requirements. These properties may include, for example:
Property # 1 : oracle.cloud.service.weblogic.size
Value: Basic, Standard, Enterprise Description: Specifies the subscription type. This affects the number of servers, database limits and quality of service settings.

Property # 2 : oracle.cloud.service.weblogic.trial
Value: True, False Description: Indicates whether this is a trial subscription.

Property # 3 : oracle.cloud.service.weblogic.crm
Value: CRM service ID
Description: Specifies the CRM service to be associated with this web logic service instance.

  FIG. 26C shows an exemplary sequence diagram illustrating the steps of a provisioning process using a Nuviaq system according to an embodiment of the present invention. The sequence diagram shown in FIG. 26C is only an example and is not intended to be limiting.

The install / update application use case, i.e., install application operation, deploys the application to a running weblogic server after confirming that the application archive meets the security requirements of the public cloud. In one embodiment, an application deployment descriptor provided in the install application action may set properties that modify the application configuration to meet tenant subscription requirements. These properties may include, for example:
Property : oracle.cloud.service.weblogic.state
Value: Run, Stop Description: Specifies the initial state of the application after deployment.

  FIG. 26D shows an exemplary sequence diagram illustrating the steps of the deployment process using the Nuviaq system according to an embodiment of the present invention. The sequence diagram shown in FIG. 26D is only an example and is not intended to be limiting.

Thus, in particular embodiments, the TAS 2104 and SDI 2106 operating in concert provision resources for one or more services ordered by a customer from a set of services provided by the cloud infrastructure system 2000. Responsible for that. For example, in one embodiment, to provision a database service, an automated provisioning flow may be as follows for a paid subscription:
(1) The customer places an order for a paid subscription for the service via the store UI 2110.

(2) The TAS 2104 receives the subscription order.
(3) If the service is available, the TAS 2104 starts provisioning by using the SDI 2106 service. The TAS 2104 may perform orchestration of business processes and execute related business processes to complete the provisioning aspect of the order. In one embodiment, the TAS 2104 may use a BPEL (Business Process Execution Language) process manager to orchestrate the steps involved in provisioning and process lifecycle operations.

  (4) In one embodiment, to provision a database service, the SDI 2106 may call the PSQL API in the CLOUD_UI to associate the schema with the requesting customer.

  (5) After successfully associating the schema with the customer, the SDI informs the TAS and the TAS sends a notification to the customer that the database service is currently available for use by the customer.

  (6) The customer may log into the cloud infrastructure system 2000 (eg, using a URAL such as cloud.oracle.com) and activate the service.

  In some embodiments, the customer may also be allowed to subscribe to the service on a trial basis. For example, such a trial order may be received via the cloud UI 2112 (eg, using cloud.oracle.com).

  In certain embodiments, the cloud infrastructure system 2000 allows basic hardware and service instances to be shared between customers or tenants. For example, a database service may be provisioned as shown in FIG. 26E in one embodiment. FIG. 26E shows multiple Exadata compute nodes 2630 and 2632, each of which provides a database instance provisioned for database services. For example, compute node 2630 provides a database 2634 for database services. Each Exadata operation node may have a plurality of database instances.

  In particular embodiments, each database instance may comprise multiple schemas, which may be associated with different customers or tenants. For example, in FIG. 26E, database 2634 provides two schemas 2636 and 2638, each of which has its own table. Schema 2636 can be associated with a first customer or tenant that subscribes to the database service, and schema 2638 can be associated with a second customer or tenant that subscribes to the database service. Each tenant gets a completely isolated schema. Each schema acts like a container that can manage database objects including tables, views, stored procedures, triggers, etc. for the associated tenant. Each schema can have one dedicated tablespace, and each tablespace has one data file.

  Thus, a single database instance can provide database services to multiple tenants. This not only allows basic hardware resource sharing, but also allows service instances to be shared between tenants.

  In certain embodiments, such a multi-tenancy system is facilitated by IDM 2100, which allows multiple separate customers, each having its own separate identity domain, to be shared in the cloud and It is advantageously possible to use software. As a result, each customer does not need to have their own dedicated hardware or software resources, and in some cases, resources that are not used by some customers at any given time are made available to other customers, This prevents waste of those resources. For example, as shown in FIG. 26E, a database instance can be served to multiple customers, each having a respective identity domain. Each such database service instance may be a separate abstraction or view of a single physical multitenant database system shared within many separate identity domains, but each such database A service instance may have a different and possibly different schema than each other database service instance has. Thus, a multi-tenant database system can store a mapping between customer-specific database schemas and the identity domains to which those database schemas relate. A multi-tenant database system may cause a database service instance for a particular identity domain to use a schema that is mapped to that particular identity domain.

  Multi-tenancy can be extended to other services such as Java services. For example, multiple customers may have JAVA service instances located within their identity domain. Each such identity domain may have a JAVA virtual machine that can be considered a virtual “slice” of hardware. In one embodiment, a job monitoring service (eg, Hudson) in the cloud to allow each separate identity domain to have its own separate virtual “slice” of the JAVA Enterprise Edition platform. It may be combined with a JAVA enterprise edition platform (eg, Oracle Web Logic). Such a job monitoring service may monitor the execution of repetitive jobs such as, for example, software projects or job construction executed by an operating system time-based job scheduler. Such repeated jobs may include the continuous construction and / or testing of software projects. Additionally or alternatively, such repeated jobs may include monitoring the execution of an operating system boot job that is executed on a machine remote from the machine on which the job monitoring service is executed.

  As described above, a single IDM system may include multiple layers and multiple subsystems. Since at least some of these subsystems can be conceptually oriented horizontally relative to each other, they are conceptually located in the same layer of the IDM system. However, different components of the IDM system can be located between these different layers. Conceptually, the lowest layer can store identity data for the IDM system. Among other types of information, identity data may include user identities and definitions. The identity data may include the identities of all entities known by the IDM system, regardless of the particular partition or identity domain to which those entities are confined. Such entities may include people who interact with the IDM system. Such entities can include non-human systems.

  The identities stored in the identity data can be organized as a directory. Various products that interact with the IDM system can be configured and designed to have awareness of the directory. Such products may include, for example, an identity manager and / or access manager that implements a single sign-on (SSO) function. In an embodiment, all of the identities for the IDM system can be stored in the conceptually bottom layer of the IDM system, but these identities can also be organized in partitions that are separated from each other. In a sense, identity data can be imagined as the core of an IDM system. A number of different identity management services may rely on the separation achieved by this partitioning. These identity management services may provide tenancy abstraction. For each particular layer of an IDM system, the subsystems that reside in that particular layer may rely on the tenancy abstraction provided by the subsystems that reside in the layer immediately below (except the bottom layer), Subsystems within a particular layer may provide tenancy abstraction to subsystems that reside in the immediate upper layer (except the top layer).

  Embodiments of the invention may divide a single IDM system into multiple distinct identity domains. Data managed by the IDM system can be divided by identity domains. Data belonging to a particular identity domain can be separated from all other identity domains. As described above, the IDM system can be shared by multiple separate tenants. Each such tenant may be a customer who has created an identity domain for his organization within the IDM system. Therefore, the identity domain may be regarded as a unit of separation from a security point of view. An identity domain, or tenancy, may provide security separation for that tenant. In one example, a single customer may create multiple separate identity domains, or tenancy, within the IDM system. For example, a single customer may purchase from an IDM system provider one identity domain dedicated to test purposes and another identity domain dedicated to production purposes.

  In an embodiment of the invention, an upper layer subsystem that utilizes a lower level identity store may be designed to have awareness of how an identity domain is mapped to an identity store. These upper subsystems can receive identity domain handles from the identity store. These upper layer subsystems can use such an identity domain handle to create a mapping between the identity domain and the identity store. At each layer of the IDM system, subsystems within that layer can be consumers of information from other layers of the IDM system. Each subsystem can use its identity domain handle to manage information related to that partition of the identity store. Subsystems in a particular layer can pass their identity domain handles to subsystems in the immediate lower layer to ensure that those subsystems interact with the correct partition of the identity store.

  A variety of different subsystems may play a role in creating a multi-tenant IDM system. For example, the SSO subsystem may be designed to result in the appearance of multiple separate SSO deployments within the IDM system. Each subsystem may include runtime components and repositories that contain its metadata. Each such runtime component can be designed to interact with a separate identity domain in a multi-tenant environment.

  Applications can be similarly designed to interact with separate identity domains in a multi-tenant environment. For example, two different applications in such an environment can interact with each other, and both such applications can be multi-tenant aware. Under such circumstances, when the user interacts with the first application of the application, the first application can determine the identity domain (from the set of identity domains) to which the user belongs. After making this determination, the first application can then communicate the user's identity domain to the second application. The second application can then query the appropriate data partition in the second application's repository related to the user's identity domain when obtaining the data. Conceptually, an identity domain can be imagined as correlating one slice of information across multi-tenant aware application instances.

  Under a cloud computing environment, some applications may be multi-tenant aware and other applications may not be multi-tenant aware. In this specification, an application that is not multi-tenant-aware is referred to as a “single-tenant application”, and a multi-tenant-aware application is referred to as a “multi-tenant application”. In one embodiment, an instance of a single tenant application dedicated to a particular identity domain can be used only by entities belonging to that particular identity domain. For example, a separate instance of an Oracle Fusion application can be instantiated in each identity domain to which the application is provisioned and dedicated to that identity domain. Since a particular service instance can be dedicated to a particular identity domain, each separate identity domain can have its own dedicated instance of that particular service. Each transaction that occurs within a cloud computing environment can occur in the context of an identity domain, regardless of whether the application involved in the transaction is a single-tenant application or a multi-tenant application.

  FIG. 1 is a block diagram conceptually illustrating an example of a shared IDM system 100 from a tenant perspective, according to an embodiment of the invention. Shared IDM system 100 may include a shared IDM and security infrastructure 102, service instances in identity domains 110A, 110B, and 110C, and tenant users 112A, 112B, and 112C. Note that tenant A user 112A can use service instances in identity domain A 110A, tenant B user 112B can use service instances in identity domain B 110B, and tenant C user 112C can use service instances in identity domain C 110C. Can be used. Since each identity domain may be separated from each other in shared IDM system 100, each tenant's users may be allowed to use only service instances in that tenant's identity domain. As described above, a particular customer of the provider of the shared IDM system 100 can create one or more tenancy or identity domains within the cloud computing environment.

  Each identity domain in shared IDM system 100 may include a separate and possibly different set of service instances. Including a particular set of service instances within a particular identity domain may be the result of a customer of that particular identity domain purchasing or leasing the use of those service instances from a provider of shared IDM system 100. Similar to the manner in which customers can deploy applications in their own networks, customers can purchase or lease the use of service instances within a cloud computing environment. Thus, such service instances may be provided via hardware, software, and / or networks that are not owned or owned by the customer himself. Service instances in identity domain A 110A may include a database service instance 116A, a JAVA service instance 118A, and a fusion customer relationship management (CRM) service instance 120A. Service instances in identity domain B 110B may include a database service instance 116B and a JAVA service instance 118B. Service instances in identity domain C 110C may include a database service instance 116C, a fusion CRM service instance 120C, and a social network service 122C. Some service instances may actually be separate single tenant instances in each identity domain, while other service instances may be manifestations of the same single multi-tenant service instance. For example, database service instances 116A, 116B, and 116C can all be manifestations of the same single multi-tenant database service instance.

  If a particular customer wants a particular set of service instances associated with a particular identity domain, that particular customer will be informed when that particular customer purchases or leases that particular set of service instances. It can be shown to the provider of the shared IDM system 100. All identities (eg, users) within a particular identity domain may be centrally managed by one or more identity domain administrators for that particular identity domain. For example, a particular identity domain may contain identities for three different users. An identity administrator for a particular identity domain can have a first user access to a first subset of service instances of that particular identity domain, and a second user can have a second of service instances of that particular identity domain. It can be specified that a different subset can be accessed, and that a third user can access a third, different subset of service instances of that particular identity domain. Thus, each of the users can access a different subset of service instances of a particular identity domain, as all are identified by the identity domain administrator for the particular identity domain.

  In one embodiment, all service instances within a particular identity domain can use the same definition of user identity. Similar to a typical enterprise system, the identity of each user in the identity domain can be created once. The applications and services contained within that identity domain can then obtain information about the user identities created within that identity domain. Identity domain administrators can use a variety of techniques for mapping user identities to applications and services. For example, such a mapping can be constructed through the use of roles, groups, rules, etc. Roles with associated permissions and authorizations can be created in the identity domain. Each role may be associated with a different set of applications and services that are accessible by the user associated with that role. The identity domain administrator can then grant users in a set of identity domains access to applications and services in the identity domain to a set by associating each role with a different set of user identities. it can. Alternatively, the identity domain administrator can grant a user identity directly access to a customer-specified set of identity domain applications and services. In one embodiment of the invention, the role itself can be formatted and stored as an identity in the identity store of shared IDM system 100. Users can be associated with a variety of different roles.

  As mentioned above, in one embodiment, all of the identities created for the shared IDM system 100 can be stored in the same identity store, but this identity store can be divided into different “slices” Are associated with different identity domains. Thus, the identity of tenant A user 112A may exist in the first slice, the identity of tenant B user 112B may exist in the second slice, and the identity of tenant C user 112C exists in the third slice. Can do. In one embodiment of the invention, each identity in the identity store of shared IDM system 100 can indicate, as an attribute, the identity domain to which that identity belongs.

  Each of the identity domains included in shared IDM system 100 may include corresponding instances of Oracle platform security services, shown as Oracle platform security services 112A, 112B, and 112C, respectively. Each of Oracle platform security services 112A, 112B, and 112C may be a collection of application programming interfaces (APIs) designed to allow access to identity information. The shared IDM and security infrastructure 102 may include many different components such as an identity management module 104, a directory service and policy store 106, and an access management module 108. In one embodiment, each such component in infrastructure 102 implements the APIs for Oracle platform security services 112A, 112B, and 112C. These APIs can expose to service instances having each of the identity domains the methods that those service instances can call to access and use components within the infrastructure 102.

  In one embodiment of the invention, when a particular customer first purchases or leases a service instance from a provider of shared IDM system 100, at least one identity domain is explicitly or implicitly created for that customer. Alternatively, for a particular customer, if at least one identity domain has already been created associated with that customer, the shared IDM system 100 mechanism allows the customer to associate with that customer for that particular customer. Customers can be asked if they wish to add a newly purchased or leased service instance to an already created identity domain. If the customer answers YES, the shared IDM system 100 can add the newly purchased or leased service instance to the set of existing service instances already associated with the existing identity domain. In this way, a particular customer's service instance can all be associated with the same identity domain if it is the intent of a particular customer. Such service instances may include, for example, various SaaS and PaaS instances.

  In one embodiment of the invention, a customer can establish an account with a centralized store so that the customer can purchase cloud-based services via the centralized store. Using this account to purchase services through a centralized store, an identity domain-specific account can be created for the customer in the cloud computing environment. This identity domain specific account is associated with the identity domain created for the customer when the customer first purchases a cloud-based service via a centralized store and can be separated into that identity domain. Thus, one account can be created to interact with the centralized store and another separate account can be created to manage and process identity domains created via the shared IDM system 100.

  In one embodiment, when an identity domain is created for a customer, the customer can share IDM systems so that the customer can distinguish that identity domain from other identity domains that may have been created for the same customer. 100 can be instructed to associate the identified name and / or uniform resource locator (URL) with its identity domain. Customers and their users can use the associated URL to access the corresponding identity domain and its contained service instances in a cloud computing environment.

  The components of infrastructure 102 do not belong to any single identity domain created for any customer. The infrastructure 102 can instead be imagined as belonging to the entire cloud computing environment. However, in one embodiment of the invention, the infrastructure 102 may be associated with an identity domain for the overall cloud computing environment. This comprehensive cloud identity domain (sometimes referred to as the “operational identity domain”) can be distinguished from the identity domain associated with the customer. Users belonging to the cloud identity domain can be granted authority to access and manage service instances in any of the customer's identity domains. In this specification, such a user is referred to as an “operation user”. Customer service representatives (CSRs) may have operational user identities created for CSRs and associated with cloud identity domains. Thus, the cloud identity domain can be considered as a CSR identity domain. A common security model not only governs the separation of identity domain users into their corresponding identity domains, but can also facilitate the interaction required to centrally manage all identity domains. Thus, the shared IDM system 100 not only prevents users associated with customer identity domains from performing operations on resources outside those identity domains, but also allows operational users associated with cloud domains to It may also be possible to perform operations on resources across multiple identity domains. Therefore, the tenancy purpose has at least the following two aspects. First, separating tenancy from each other, and second, managing other tenancy (in the case of a cloud identity domain).

  FIG. 2 is a flowchart illustrating an example technique 200 for creating multiple identity domains for multiple customers via a shared IDM system, according to an embodiment of the invention. Although the technique 200 is shown as including certain operations performed in a certain order, alternative embodiments of the invention may include additional, fewer, or alternative operations that may be performed in a different order. . At block 202, a first customer creates a first identity domain via a shared IDM system. In one embodiment, the shared IDM system stores metadata that uniquely defines the first identity domain to create the first identity domain. At block 204, a first customer purchases a first set of service instances via or in connection with a shared IDM system. At block 206, service instances in the first set of service instances are mapped to a first identity domain. In some embodiments, the shared IDM system associates the first plurality of services with the first identity domain by creating a mapping between the first plurality of services and the first identity domain. For example, a shared IDM system may store such mappings permanently in computer readable storage memory. It should be noted that, as will be further seen below, each of several customers can utilize the same shared IDM system in establishing a separate, isolated identity domain, so that a separate IDM system is a customer. There is no need to instantiate every time. At block 208, a first set of user identities is created in the first identity domain via the shared IDM system. The user identities in the first set of user identities are mapped to the first identity domain.

  At block 210, the second customer creates a second identity domain via the shared IDM system. In one embodiment, the shared IDM system stores metadata that uniquely defines the second identity domain to create the second identity domain. At block 212, a second customer purchases a second set of service instances via or in connection with the shared IDM system. At block 214, service instances in the second set of service instances are mapped to a second identity domain. In one embodiment, the shared IDM system associates the second plurality of services with the second identity domain by creating a mapping between the second plurality of services and the second identity domain. For example, a shared IDM system may store such mappings permanently in computer readable storage memory. Thus, each of several customers can utilize the same shared IDM system in establishing a separate isolated identity domain, so a separate IDM system needs to be instantiated for each customer. Absent. At block 216, a second set of user identities is created in the second identity domain via the shared IDM system. The user identities in the second set of user identities are mapped to the second identity domain.

  At block 218, the shared IDM system shares the user identities in the first set of user identities between the first set of service instances and not between the second set of user instances. In some embodiments, the shared IDM system shares a first set of user identities based at least in part on each user-based mappings. At block 220, the shared IDM system shares the user identities in the second set of user identities between the second set of service instances and not between the first set of user instances. In certain embodiments, the shared IDM system shares a second set of identities of users based at least in part on each user-based mapping. Both the first and second sets of user identities may be stored in the same identity store of the same shared IDM system. At block 222, a first identity domain administrator for the first identity domain manages a first set of user identities using a shared IDM system. At block 224, the second identity domain administrator for the second identity domain manages the second set of user identities using the shared IDM system. User identity management may include, for example, adding user identities, erasing user identities, modifying user identity attributes, adding or removing associations between user identities and roles and / or groups, roles and / or This may include creating groups, granting or removing service instance access permissions to users, roles, and / or groups, and the like. In one embodiment of the invention, such management can be performed via an administrator interface provided by the shared IDM system. A variety of different identity domains can be managed through such an administrator interface. Accordingly, shared IDM system 100 determines that users in the first set of users are not the first set of services based at least in part on a mapping that defines one or more services assigned to each user. Preventing operations on services in the second set of services.

  In one embodiment of the invention, various policies may be specified within the shared IDM system. Each such policy may include a set of rules that must be satisfied if the policy is satisfied as a whole. A policy may specify that access to a service instance or system resource is granted only if all the rules of that policy are met. There may also be an implicit policy that a particular user's identity must belong to the same identity domain in order for that particular user to access a service instance in the customer's identity domain. However, this implicit policy may allow operational users who may be outside of any customer identity domain to access service instances in any customer identity domain. In a multi-tenant IDM system, each policy can be made to reflect the intent that service instances associated with a particular identity domain are segregated within that particular identity domain.

  For example, a cloud computing environment may include an access management system such as a directory and SSO system. The SSO system can protect many URLs. The SSO system may be configured to protect a specified set of URLs, but not a URL that is not in the specified set (ie, the latter URLs are not protected). A single host machine in a cloud computing environment can be associated with multiple different URLs. Conceptually, each host machine in a cloud computing environment can be imagined as having multiple gates standing between that host machine and the user who wants to access the host machine. When a user attempts to access a URL associated with a particular host machine, the SSO system can forward that user to the appropriate host machine. The gate protecting the host machine can look up the fully qualified URL that is being used to access the host machine. This gate can either transfer the user to the SSO server or execute with reference to the policy related to its host machine and URL. Such a policy may indicate that the user should be authenticated, that the user's attributes should be discovered, and that the user accesses the host machine using a URL based on the user's attributes. It may indicate that a decision should be made as to whether or not allowed. In one embodiment of the invention, such policies can be enhanced to reflect the identity domain boundaries defined by the shared IDM system.

  FIG. 3 is a block diagram illustrating a schematic example of a hierarchical cloud-based IDM system 300 according to an embodiment of the invention. The cloud-based IDM system 300 may include multiple layers, such as a cloud security foundation layer 302, a cloud shared IDM layer 304, and an Oracle IDM / security layer 306. In one embodiment, the cloud security foundation layer 302 interacts with the cloud shared IDM layer 304, and the cloud shared IDM layer 304 interacts with the Oracle IDM / security layer 306. The Oracle IDM / security layer 306 can implement a “raw” identity management system. Cloud shared IDM layer 304 includes a model for segregating each tenant's data, thereby creating an abstraction of a “raw” identity system that supports the concept of multiple tenants and segregated identity domains Can do. Each layer may include multiple sublayers and subsystems. Some of these are further described below.

  FIG. 4 is a block diagram illustrating an example subsystem of the cloud security foundation layer 400 according to an embodiment of the invention. The cloud security foundation layer 400 of FIG. 4 may correspond to the cloud security foundation layer 302 of FIG. The security foundation layer 400 includes a tenant management delegation model 404, a cloud infrastructure life cycle & runtime model 406, an operation user life cycle 408, a common policy 410, a cloud public key infrastructure (PKI) key provisioning 412, and an identity store and policy store. May include multiple subsystems, such as data security 414 for.

  The tenant management delegation model 404 can be a model that considers the existence of the architecture of identity domains and the association between those identity domains and service instances. This model can be used to identify the roles that various users associated with an identity domain have for the identity domain or elements therein. The model can specify permissions granted to each role (eg, for service instances, users, roles, etc.). The tenant management delegation model 404 may allow a customer who purchased an identity domain to appoint a user as an identity domain administrator for that identity domain. In one embodiment, such a customer can use the components of the cloud security foundation layer 400 to create a hierarchy of roles. Such a hierarchy can be created implicitly during the initial creation of an identity domain, and specifically can relate to the identity domain whose creation led to the creation of the hierarchy. Thus, each identity domain may be associated with a separate, possibly different hierarchy of roles. In one embodiment, the role implicitly created at the top or root of the hierarchy is the identity domain administrator role for the identity domain. Each identity domain may have one or more identity domain administrators. An identity domain administrator may have sufficient permissions and authorities to manage the identity domain as a whole, including all service instances, users, and other roles that exist within the identity domain.

  A service administrator can be placed under the identity domain administrator in the role hierarchy. In this document, the term “service administrator” is used to describe the classification of roles that have permission to manage service instances in an identity domain, but there is not necessarily a role called “service administrator”. Rather, there may be various specific roles that fall under all of the “service manager” categories. For example, each type of service instance may have a type of service administrator role that manages the service. Examples of service manager roles include JAVA service managers, database service managers, fusion application managers, and the like. An identity domain administrator can use the components of the cloud security foundation layer 400 to appoint one or more users associated with the identity domain as a service administrator. Because a “service administrator” can be a classification of roles rather than the role itself, the user interface that an identity domain administrator uses to assign other users to a service administrator role is Each particular type of service administrator role that can be appointed (eg, JAVA service administrator, database service administrator, fusion application administrator, etc.) may be listed. Each service administrator may have the necessary permissions and authorities to process and manage a particular service instance within that identity domain. Each service administrator may have the permissions and authorities necessary to manage a role that is specifically related to and limited in scope to a particular service instance that the service administrator manages. However, a particular service administrator does not necessarily have the authority to manage other service instances or to process the entire identity domain. Each service instance may have its own separate service administrator. In some cases, the same user may be appointed as a service administrator for multiple service instances in the same identity domain. An identity domain administrator can perform all of the functions that a service administrator can perform. This is because an identity domain administrator is higher in the role hierarchy and not vice versa. In one embodiment, the designer of each service for which a service instance can be created in the identity domain has a hierarchy of roles defined by the service designer associated with that service, typically at the root of the hierarchy. You are tasked with ensuring that the entire service-specific service administrator role is included.

  FIG. 7 is a block diagram illustrating an example of a cloud-based IDM system 700 that can use role hierarchies to manage identity domains, according to an embodiment of the invention. FIG. 7 shows a customer (store account administrator) 702, a customer identity domain 704, and a cloud identity domain 708. Customer 702 does not necessarily exist in any identity domain in practice. Alternatively, customer 702 may have a store with an online store. Thus, customer 702 is an administrator of a store account that can be an account outside of a completely cloud-based system. The customer 702 can use this account to purchase one or more identity domains, such as customer identity domain 704, and further purchase service instances that are deployed within such identity domain. Customer 702 can act as a buyer. Because customer 702 does not necessarily have a user identity in the identity domain, when purchasing customer identity domain 704 via an online store, customer 702 may obtain an identity domain administrator 710 for customer identity domain 704 (further described below). Another user can be designated (e.g., by specifying the other user's email address in the online store). In this manner, a user having a user identity in customer identity domain 704 can access customer identity domain 704 even if customer 702 does not have such a user identity.

  Customer identity domain 704 includes users that are in scope within customer identity domain 704 and assigned various roles that do not span any other identity domain. Among these roles may be the identity domain administrator 710 role described above. Identity domain administrator 710 may be nominated by customer 702. As part of that role, the identity domain administrator 702 can delegate at least some of the permissions and authorities it has to other roles in the customer identity domain 704. These other roles may include service and application administrator roles, such as identity administrator 712, JAVA service administrator 714, database service administrator 716, and fusion application administrator 718. Each of these service administrators may have the permissions and authorities necessary to process and manage users and roles for a particular service instance in customer identity domain 704, without limitation.

  Identity administrator 712 may have permission to perform role management 720 and user management 722 tasks within customer identity domain 704. Identity administrator 712 can delegate role management 720 and user management 722 as roles to other user identities in customer identity domain 704. These permissions may manage, for example, user identities and role identities related to customer identity domain 704 (eg, password reset operations, etc.). Identity administrator 712 may be the same user as identity domain administrator 710. The JAVA service administrator 714 may have permission to perform the JAVA administrator 724 task. JAVA service administrator 714 can delegate JAVA administrator 724 as a role to other user identities in customer identity domain 704. With these permissions, the JAVA virtual machine can be instantiated, modified, and deleted, for example. Database service administrator 716 may have permission to assign database specific roles to other users in customer identity domain 704. These database specific roles may include user 726, developer 728, and administrator 730 roles. Each such role may have different permissions for the database service instance. For example, user 726 may be limited to permissions that allow user 726 to query and otherwise use data stored in a database table. Developer 728 may additionally have permissions that allow developer 728 to modify the configuration of the database, including, for example, system parameters. Administrator 730 may have permission to perform all actions on that service instance, including managing other users for the database service instance. Administrator 730 may be the same user as database service administrator 716. Fusion application administrator 718 may have permission to create and modify CRM hierarchy 732 for use by a fusion application instance. With these permissions, the fusion application administrator can place users with user identities in customer identity domain 704 in CRM hierarchy 732. The fusion application administrator 718 may have permission to define a role for each position in the CRM hierarchy 732 and a corresponding permission, each such role being limited to performing operations on the fusion application instance. You can also define and assign other service administrator roles.

  In one embodiment, as described above, the identity domain administrator 710 nominated by the customer 702 (typically upon creation of the customer identity domain 704) can grant authorization and service instance roles within the customer identity domain 704. Can be delegated to other users. Further, in one embodiment, customer 702 can directly nominate users in customer identity domain 704 to be service administrators with their service instance roles. For example, in one embodiment, customer 702 can directly nominate each of identity domain administrator 710, identity administrator 712, JAVA service administrator 714, database service administrator 716, and fusion application administrator 718. In one example, customer 702 can nominate these other users to service instance roles as part of the purchase of the service instance to which those roles pertain. For example, when a customer 702 purchases a service instance, one or more emails of the users that the customer 702 nominates as the service instance administrator for that service instance in the online store where the service instance is purchased An address can be specified. User identities can be automatically created for users with these email addresses within the identity domain identified by customer 702, and these users have the service administrator role for the service instance identified by customer 702. Can be assigned.

  Further, as described above, the cloud-based IDM system 700 may include a generic cloud identity domain, such as the cloud identity domain 708, in addition to a customer identity domain, such as the customer identity domain 704. The cloud identity domain 708 may include the operation users described above. The cloud identity domain 708 does not belong to any customer and exists independently from any customer. Users in cloud identity domain 708 manage roles, users, and service instances in customer identity domains such as customer identity domain 704 (also other customer identity domains not shown that may exist in cloud-based IDM system 700). May have permission to do so. An operational role hierarchy 734 can be defined in the cloud identity domain 708. The operation role hierarchy 734 can define permissions, privileges, and roles owned by an operation user for each operation user in the cloud identity domain 708. The policies defined in the cloud identity domain 708 determine which customer identity domains an operation role can access and what operations roles do for services, users, and resources in those customer identity domains. Limits can be placed on the types of operations that can be performed. For example, a subset of operational user identities within the cloud identity domain 708 may be limited by roles and / or policies for performing identity management functions, but these operational user identities You may have the ability to perform such identity management functions on identities that are also defined in the customer identity domain. In each identity domain, a runtime instance can enforce such a policy.

  In cloud-based IDM system 700, roles can be defined hierarchically. Authority and permissions available to lower level roles in a hierarchy can be inherited by higher level roles in that hierarchy. A parent or ancestor role of another role in the role hierarchy may inherit the rights and permissions available to the child or descendant role. Accordingly, the identity administrator 712 may inherit the roles and corresponding authorization-based capabilities of the role management 720 and user management 722 roles, and the identity domain administrator 710 may inherit the roles of the identity administrator 712 and the corresponding authorization-based capabilities. Can be inherited, but inheritance does not flow in the opposite direction in the hierarchy. In one embodiment, a role hierarchy is automatically created for each service instance when the service instance is added to the identity domain, after which roles in that role hierarchy are created by users who have permission to do so. Can be assigned and / or modified. The role hierarchy of each service instance may differ in that a role that is different from the roles defined in the role hierarchy for other service instances can be defined.

  In one embodiment, predefined (possibly thousands) roles for a service instance can be automatically created in the identity domain based on the type of service instance being added to the identity domain, and the user can It is not always necessary to manually define each role in each role hierarchy. Each type of service is predefined by the service creator and automatically created when the service instance is added to the identity domain, before any instance of that service is added to any identity domain. Can be associated with a service type role hierarchy For example, a database service can be associated with a predefined database service role hierarchy, and a JAVA service can be associated with a predefined JAVA service role hierarchy. Thus, each type of service may be associated with a distinct and possibly different predefined “template” of hierarchically related roles for that type of service. Some roles, such as identity domain administrator 710, may be predefined in the cloud-wide role model (and may have immutable definitions in some cases), while other service instance specific roles are appropriate Can be created and manually defined to have customer permissions for a particular service instance.

  Permissions associated in predefined service type specific role hierarchies can be inherited by hierarchically higher roles defined in the cloud-wide model. For example, each service administrator role for a particular type of service (eg, database service) inherits all the roles (and associated permissions) predefined in that particular type of service-specific role hierarchy. obtain. An identity domain administrator role may inherit all roles (and associated permissions) inherited by all service administrator roles in the identity domain. Accordingly, identity domain administrator 710 can perform all of the operations that can be performed by all of service administrators 712-718 through role inheritance, while identity administrator 712 can perform other service administrators 714. Operations that ˜718 can perform cannot necessarily be performed. The identity manager 712 may be limited to performing general identity-based operations within the identity domain that are not specific to any particular service instance. Customer 702 in one embodiment does not inherit any role because it is outside the identity domain.

  In one embodiment, when a customer 702 uses an online store to nominate someone, such as either an identity domain administrator 710 or a service administrator 712-718, to have a specific role in the customer identity domain 704, online In response, the store can send an email message to the email address of the designated person. Customer 702 can provide an email address to the online store as part of the nomination process. The email message sent to the designated person's email address may include a hyperlink that points to a web-based form supplied by a web server in the cloud computing environment. Web-based forms may include fields that can be filled, through which message recipients can help create user names, passwords, and user identities for nominated persons in customer identity domain 704 Can be specified. When the nominated person submits the entered web-based form to the web server, the web server can cause the nominated person's user identity to be created in the customer identity domain 704, and the identified role can be Can be assigned to that user identity. Nomination can be viewed as a process in which an entity outside the identity domain assigns a role to a user identity in the identity domain, while delegation refers to a user identity in an identity domain being transferred to another user identity in that user identity domain It can be viewed as a process of assigning a role that the former user has the authority to assign (by its own role in the identity domain).

  FIG. 11 is a block diagram further illustrating role delegation in a multi-tenant IDM system as described above, according to an embodiment of the invention. System 1100 may include an online store 1102 and a customer identity domain 1104. A customer (store account administrator) 1106 may have an account in the online store 1102. Customer 1106 can nominate different users with identities in identity domain 1104 to different roles, as indicated by the dashed arrows in FIG. For example, customer 1106 can nominate such a user to identity domain administrator 1108 and / or service administrators 1112 and 1114 for different service instances. Such nomination may occur when customer 1106 purchases identity domain 1104 from online store 1102. These users with identities in identity domain 1104 can then delegate various roles to other users with identities in identity domain 1104, as shown by the solid arrows in FIG. For example, the identity domain administrator 1108 can delegate roles to other users, such as the identity domain security administrator 1110 and / or service administrators 1112 and 1114 for different service instances. These other users can further delegate roles to other users having identities in the identity domain 1104. For example, the identity domain security administrator 1110 can delegate the identity domain user / role management role 1116 to other users. For another example, the service administrator 1112 for one service instance can delegate the service instance specific role 1118 for that service instance to other users. For yet another example, the service administrator 114 for another service instance can delegate the service instance specific role 1120 for that other service instance to other users.

  FIG. 12 is a block diagram further illustrating permission inheritance in a multi-tenant IDM system as described above, according to an embodiment of the invention. System 1200 may include an online store 1202 and a customer identity domain 1204. A customer (store account administrator) 1206 may have an account in the online store 1202. In one embodiment, customer 1206 does not inherit permission because customer 1206 is not an identity in identity domain 1204. Within identity domain 1204, identity domain security administrator 1210 can inherit permissions from identity domain user / role management role 1216. A service administrator 1212 for one service instance can inherit permissions from a service instance specific role 1218 for that same service. A service administrator 1214 for another service instance can inherit permissions from a service instance specific role 1220 for that other service. The identity domain administrator 1208 can then inherit permissions from each of the identity domain security administrator 1210 and service administrators 1212 and 1214. Thus, in one embodiment, the identity domain administrator 1208 can inherit permission to manage all service instances in the identity domain 1204.

  FIG. 5 is a block diagram illustrating an example subsystem of the cloud shared IDM layer 500, according to an embodiment of the invention. The cloud shared IDM layer 500 in FIG. 5 may correspond to the cloud shared IDM layer 304 in FIG. The cloud shared IDM layer 500 may include a tenant and service provisioning automation API 502, an IDM lifecycle operation tool 504, a tenant-aware IDM component extension 506, and a tenant separation data model 520. The tenant-aware IDM component extension 506 includes a multi-tenant login user interface (UI) and authentication scheme 508, a cloud IDM console 510, an identity federation multi-tenant extension 512, a cloud infrastructure certificate service 514, and a user / role API 516. And an application plug-in module multi-tenant extension 518.

  In one example, each component of the shared IDM system may include a tenant separation construct for that artifact to perform separation between identity domains. Each such tenant separation construct may follow a tenant separation data model 520. An access management product may require, for example, an identity management service and a corresponding policy. Each customer may have its own “slice” of the policy store of the shared IDM system so that these policies are different, can be customized, and can be differentiated by customer. Thus, in one embodiment of the invention, the policies in the policy store of the shared IDM system can be divided by identity domain. The mechanism for storing and managing policies can be tenant specific. The tenant separation data model 520 can be followed by each of the subsystems within the tenant-aware IDM component extension 506 to implement separation between identity domains. By following the tenant separation data model 520, each shared IDM product can possess identity domain-aware features.

  For example, the multi-tenant login UI and authentication scheme 508 can follow the tenant separation data model 520 by providing a UI field through which a user can identify a particular identity domain that the user is trying to access. This feature allows a user to log into a specific identity domain within the cloud computing environment. The multi-tenant login UI and authentication scheme 508 can then select a particular identity domain for which the user is authenticated. In particular, the authentication scheme can use a specific identity domain to query the correct partition when referring to the actual password associated with the user identity supplied during the login process. Unqualified user identities may need to be unique within the identity domain, but such user identities may possibly be duplicated across separate identity domains. In one embodiment of the invention, fully authorized user identities can identify the identity domain to which those user identities belong, and such fully authorized user identities are separate identity domains. Is not duplicated across. Accordingly, embodiments of the invention provide a mechanism by which the authentication process becomes multi-tenant aware. Such a mechanism may determine a user's identity domain and may authenticate the user based on data specific to that identity domain.

  In one embodiment, the cloud IDM console 510 may be among tenant-aware component extensions 506 that follow the tenant separation data model 520. The cloud IDM console 510 can be used to change user passwords and perform other user identity management functions, for example. Cloud IDM console 510 may include controls through which the identity domain in which console operations are performed can be determined. Thus, when an identity domain administrator adds or deletes a user identity using the cloud IDM console 510, the cloud IDM console 510 can determine the identity domain to which the identity domain administrator belongs and add or delete user identities. It can be restricted to that identity domain only.

  The tenant and service provisioning automation API 502 can be used to provision purchased service instances to the identity domain from which they were purchased. The IDM lifecycle operations tool 504 can be used to upload data (eg, patch applications, etc.) to the identity domain, download from the identity domain, and synchronize within the identity domain.

  FIG. 6 is a block diagram illustrating an example of an Oracle IDM / security layer 600 subsystem, according to an embodiment of the invention. The Oracle IDM / security layer 600 of FIG. 6 may correspond to the Oracle IDM / security layer 306 of FIG. Oracle IDM / Security Layer 600 includes Oracle platform security services (OPSS) and Oracle web services manager (OWSM) 602, Oracle Internet directories (OID) 604, Oracle An Oracle Identity Federation (OID) module 606 and an Oracle Identity Manager (OIM) 608 may be included. In one embodiment of the invention, identities associated with each identity domain in the shared IDM system may be stored in OID 604. OID 604 may implement a Lightweight Directory Access Protocol (LDAP) directory. Thus, in one embodiment, all of the identities of all users in a shared IDM system can be stored in an LDAP directory that is divided by identity domains.

  The access control subsystem for each identity domain is granted only if access to the protected service or resource is defined in the identity domain and the policy associated with the protected service or resource is met Policy-driven in the sense that Each identity domain may have a runtime instance that enforces the policies defined within that identity domain. In one example, all policies for all identity domains can be stored in a common cloud-wide policy store, which can be partitioned by identity domain.

  As described above, in one embodiment of the invention, a customer can have an identity domain created in a cloud-based environment, and one or more services that are available within the identity domain from an online store. You can purchase an instance. In one embodiment of the invention, an API for a multi-tenant cloud-based IDM system is defined to ensure that service instance provisioning operations are performed in the correct order. Typically, the first operation performed on an identity domain is the creation of that identity domain in a cloud-based IDM system. One API method can receive a name for an identity domain and determine if any identity domain in the cloud-based IDM system already has that name. If an identity domain with that name does not currently exist, the API method may create that identity domain (in part, by storing metadata defining the identity domain). Regardless of whether the identity domain existed prior to the API method invocation, the API method may return information about the named identity domain to the entity that invoked the API method. The entity can use this information to invoke further methods of the API and perform operations on the named identity domain, such as adding a service instance.

  FIG. 13 is a block diagram illustrating an example system 1300 for provisioning service instances in an identity domain, according to an embodiment of the invention. The example operation assumes a situation where a customer is purchasing an identity domain and a service instance for that identity domain at the same time. For example, the service instance may be an instance of a fusion CRM application. At (A), the global single instance (GSI) module 1302 may send the approved customer order to the TAS module 1304. In (B), the TAS module 1304 may instruct the SDI module 1306 to create a service instance. In (C), the SDI module 1306 may determine that the identity domain itself for which the service instance is to be created has not yet been created, so the SDI module 1306 sends an identity domain creation request to the IDM provisioning API 1308. Can do. In response to this request, the IDM domain provisioning API 1308 may cause the customer identity domain 1310 to be created. At (D), the IDM domain provisioning API 1308 may send an identity domain creation response to the SDI module 1306. This identity domain creation response indicates that the identity domain has been created successfully, and the SDI module 1306 indicates the newly created identity domain (customer identity domain 1310) in a subsequent transaction with the IDM domain provisioning API 1308. Contains linkage information that can be used to point. In (E), the SDI module 1306 may send a service instance creation request to the IDM domain provisioning API 1308. In this request, the SDI module 1306 may point to the newly created identity domain (customer identity domain 1310) as the identity domain in which the service instance is to be created. In response to this request, the IDM domain provisioning API 1308 may create a service instance footprint in the IDM system 1312 that is specific to the created service instance (eg, a fusion CRM application). In (F), the IDM domain provisioning API 1308 may send a service instance creation response to the SDI module 1306. In (G), the SDI module 1306 “re-hydrates” the service instance seed IDM system artifact 1314 for the created service instance type (eg, fusion CRM application) in the customer identity domain 1310. Can do. Such rehydration creates a stored generic "image" copy of the service instance type, connects the service instance and the identity domain, and customizes the service instance for that identity domain Generating and storing linkage information. At (H), the SDI module 1306 may send a service instance creation confirmation response to the TAS module 1304 indicating that the service instance has been successfully instantiated in the customer identity domain 1310.

  Table 1 below shows the different components of the cloud-based multi-tenant IDM system and the cloud-based multi-tenant IDM system for the various cloud-based events described above with reference to FIG. 13, according to an embodiment of the invention. The different entities indicate the types of information that can communicate with each other as part of their events.

  Adding a service instance to an identity domain can include instantiation of one or more virtual machines under a cloud-based environment. Virtual machines for that type of service can be instantiated as part of adding a service instance to the identity domain. In one embodiment, instantiation of such a virtual machine, or “service instance runtime component”, is a configuration operation that ensures that such virtual machine is associated or “connected” with the appropriate identity domain. Can be achieved. In addition, instantiation of such virtual machines may be accomplished by configuration operations that ensure that such virtual machines are associated or “connected” with appropriate policy-based boundaries. In one embodiment of the invention, an API method for creating a specified type of service instance is implemented in a cloud-based IDM system. This invocation of the service instance creation API method may cause the cloud-based DM system to create a handle that can be used to establish an association between the service instance virtual machine and the appropriate identity domain. Such a handle may include adjustment information such as the name, username, password, etc. of the appropriate identity domain. A service instance virtual machine can use such a username and password to connect to a cloud-based IDM system, and the identity domain in which the service instance virtual machine will run in that context during the connection process The name can be specified. The service instance creation API method may ensure that the username and password specified by that handle are not duplicated in handles created for any other service instance virtual machine. For this reason, virtual machines for service instances in other identity domains are not inappropriately allowed to connect to identity domains other than their own identity domain. Thus, the service instance creation API method can return a vector of information containing all the data necessary to instantiate the service instance to the entity that invoked the method.

  Each service instance virtual machine can access identities defined in the identity domain in which the service instance virtual machine runs. This access can be granted, for example, so that the service instance virtual machine can authenticate the user and reference roles related to the identity domain. FIG. 8 is a block diagram illustrating a multi-tenant IDM system 800 that allows an application instance runtime component to access identities defined in an identity domain, according to an embodiment of the invention. In the illustrated example, the application instance runtime component is for an instance of a fusion (CRM) application. The system 800 may include a fusion application service 802, a fusion middleware 804, a policy store 806, an identity store 808, and a database 810. Fusion application service 802 and fusion middleware 804 together build a fusion application runtime component. Policy store 806 and identity store 808 may be implemented, for example, as an Oracle Internet Directory (OID) or other LDAP directory. A policy store 806 that may store policies from various separate identity domains may include a policy store root node 826, from which the logical security store node 824 may descend hierarchically, and the logical security store node From 824, policies 816, 818, 820 and 822 may descend hierarchically. Policies 816, 818, and 820 may relate to one identity domain, domain A, and policy 822 may relate to another identity domain, domain B. Policies 816 and 818 may relate to separate instances of JAVA services, and policies 820 and 822 may relate to separate instances of fusion application services. An identity store 808 that may store identities from various separate identity domains may include an LDAP root node 828 from which nodes for the various identity domains 830 may descend hierarchically, and the identity domain 830 Identities associated with identity domain A 832 and identities associated with identity domain B 834 may descend hierarchically. Database 810 is provided by fusion application service 802 and fusion middleware 804, such as fusion on-line transaction processing (OLTP) data 812 and schema 814 (which may include a fusion middleware schema and other database schemas as the case may be). The data used can be stored.

  The fusion application may be an example of a single tenant application that exists in the multi-tenant IDM system 800. Thus, a particular instance of the fusion application service 802 and fusion middleware 804 may be specific to a particular identity domain. In this example, they are specific to identity domain A. The identity store 808 may be constructed as an LDAP directory tree that includes various separate sub-trees related to separate identity domains in the multi-tenant IDM system 800 towards its leaf nodes. The identity store handle for the fusion application runtime component refers only to the node in the LDAP identity hierarchy that is the root node of the LDAP subtree that contains identities related to identity domain A 832. Thus, the identity store handle for the fusion application runtime component refers only to the “slice” of identity store 808 dedicated to identity domain A. This pointer is shown as an arrow in FIG. 8 starting from the fusion application runtime component and ending in the LDAP subtree 832. Such a pointer may be established as a result of invoking an API method when a fusion application service is added to identity domain A. The handle returned by the API method may include credentials that are recognized within the multi-tenant IDM system 800 and that identify a particular username and password that is specifically associated with identity domain A. Thus, this credential can be tied to an appropriate “slice”, or partition, of the identity store 808 associated with identity domain A. The fusion application runtime component may use this particular username and password to access the appropriate partition of the identity store 808. Because the internal access control of OID (which can be used to implement identity store 808) can restrict the visibility of the fusion application runtime component to only the appropriate partition of identity store 808, the fusion Application runtime components cannot access identities belonging to identity domains other than identity domain A.

  Each separate service instance in multi-tenant IDM system 800 may store its own separate set of policies related to that service instance in cloud-wide policy store 808. The policy store 808 may be constructed as an LDAP tree that includes a subtree for each identity domain and a policy node for service instances in each identity domain subtree. The policy store handle for the fusion application runtime component refers only to the node in the LDAP policy hierarchy that is the root node of the LDAP subtree that contains the policies related to the fusion application runtime instance belonging to identity domain A. This pointer is shown in FIG. 8 as an arrow originating from the fusion application runtime component and ending with the LDAP policy entry 820. Such a pointer may be established as a result of invoking an API method when a fusion application service is added to identity domain A. Thus, the fusion application runtime component is tied or “connected” to a particular partition of the policy store 808 that specifically relates to policies related to fusion application services belonging to identity domain A. As a result, when the fusion application runtime component queries the policy store 808, this query can be performed on the specific partition of the policy store 808 to which the fusion application runtime component is bound.

  More generally, in one embodiment of the invention, there is a boundary for each service instance runtime component. For a particular service instance runtime component, a credential can be created that points only to each partition of the identity store 806 and the policy store 808 that is associated with the appropriate identity domain and the appropriate service instance, respectively. Once created, these credentials can be passed to the provisioning system so that the provisioning system can store data about different service instances in different identity domains, each under different cloud computing environments. Service instance runtime components may be tied to appropriate partitions of store 806 and policy store 808. Identity store 806 may be implemented separately from policy store 808. This is because identities are not service specific, but policies can be service specific. Thus, the security boundaries associated with each type of data can vary in scope. Multiple service instances within the same identity domain may all be bound to the same LDAP subtree in identity store 806, but each service instance may be bound to a different LDAP policy entry in policy store 808.

  In one embodiment, one or more information stores such as identity store 806 may be stored in an LDAP directory such as OID. Such LDAP directories are typically organized hierarchically. In one embodiment, a single LDAP directory may store information related to multiple distinct identity domains within a cloud-based multi-tenant IDM system. FIG. 16 is a hierarchy diagram illustrating an example of the structure of a multi-tenant LDAP directory 1600 for a cloud-based IDM system, according to an embodiment of the invention. LDAP route 1602 can be the parent of multiple nodes such as system group node 1604, system identity node 1606, identity domain node 1608, and service template node 1610. The system group 1604 is not specific to an identity domain and can be the parent of a node that represents a group of cloud system wide identities. The system group 1604 can be the parent of an app ID group, and the app ID group can group together various application identities into identified groups. The system identity 1606 is not unique to the identity domain and can be the parent of a node that represents an individual identity that is cloud system wide. A system identity can be the parent of an app ID, which can identify individual applications that are cloud system wide, and that identity is not identity domain specific. Identity domain 1608 may be the parent of a node for various distinct identity domains, such as customer A identity domain 1616A, customer B identity domain 1616B, and CSR (or operations) identity domain 1618. As described above, each of these identity domain nodes can be the parent of many other nodes related to roles and identities within the respective identity domain. Further, while FIG. 16 shows a single identity domain per customer (eg, A and B), in an alternative embodiment, each customer may have multiple distinct identity domains. Service template 1610 can be the parent of a number of nodes that are the root of the role hierarchy for different service types. As mentioned above, different service types can be mapped to a predefined role hierarchy, which is automatically added to the identity domain when that type of service is added to the identity domain, It can save the user from manually creating the role for the service.

  FIG. 17 is a hierarchical diagram illustrating an example structure of an LDAP directory subtree related to role templates for different service types, according to an embodiment of the invention. Service context template node 1701 may correspond to service template node 1610 of FIG. Service context template node 1701 can be the parent of many nodes for different service types. Such nodes may include, for example, a JAVA service node 1702, a database service node 1704, and an Oracle social network (OSN) service node 1706. Each of nodes 1702-1706 may be the parent of the node that is the root of the subtree that contains the role node for that service type. For example, role template node 1708 may be the root of a subtree of nodes that describe a predefined role for a service having a JAVA service type. As another example, role template node 1710 can be the root of a subtree of nodes that describe a predefined role for a service having a database service type. As yet another example, role template node 1712 can be the root of a subtree of nodes that describe a predefined role for a service having an OSN service type. These subtrees are used for users in those identity domains, although users and administrators of those services, such as identity domain administrators and service administrators, do not need to manually create such roles. Can be defined by the designer and creator of the service.

  According to one embodiment of the invention, the multi-tenancy IDM system advantageously allows multiple separate customers, each having their own separate identity domain, to use hardware and software shared in the cloud. to enable. As a result, each customer does not need to have its own dedicated hardware or software resources, and in some cases, resources that are not used by some customers at one time can be made available to other customers. This prevents these resources from being wasted. For example, multiple customers may have JAVA service instances located within their identity domain. Each such identity domain may have a JAVA virtual machine that can be viewed as a virtual “slice” of hardware. As another example, in one embodiment, multiple customers may have database service instances located within their respective identity domains. Each such database service instance can be a separate abstraction or view of a single physical multi-tenant database system that is shared among many distinct identity domains, but each such database service instance is , May have a different, possibly different, schema than each other database service instance has. Thus, a multi-tenant database system can store a mapping between database schemas specified by customers and the identity domains to which those database schemas relate. A multi-tenant database system may cause a database service instance for a particular identity domain to use a schema mapped to that particular identity domain. In one embodiment, a job monitoring service (eg, Hudson) is combined with a JAVA enterprise edition platform (eg, Oracle Weblogic) in the cloud, and each distinct identity domain is its own separate identity of the JAVA enterprise edition platform. It may be possible to have a virtual “slice”. Such a job monitoring service may monitor the execution of repetitive jobs such as, for example, software projects or job construction executed by an operating system time-based job scheduler. Such repeated jobs may include the continuous construction and / or testing of software projects. Additionally or alternatively, such repeated jobs may include monitoring the execution of an operating system boot job that is executed on a machine remote from the machine on which the job monitoring service is executed.

  FIG. 14 is a block diagram illustrating an example of a multi-tenant cloud-based system 1400 where cloud hardware and software resources can be shared between identity domains, according to an embodiment of the invention. The system 1400 may include an Oracle JAVA cloud service management interface 1402, an application end user 1404, an Oracle cloud service deployment infrastructure 1406, a cloud application foundation 1408, and a provisioned system 1410. Oracle JAVA cloud service management interface 1402 may include various user interfaces such as a web-based interface and / or a command line interface. These interfaces can be used to interact with the Oracle cloud service deployment infrastructure 1406. Oracle cloud service deployment infrastructure 1406 may interact with cloud application foundation 1408. In one example, the cloud application foundation 1408 can be constructed using a fusion middleware component. In one example, the cloud application foundation 1408 may include an Oracle Virtual Assembly Builder (OVAB) pool 1410, a database server 1412, a web tier 1414, an IDM infrastructure 1416, and an enterprise manager cloud control 1422. The OVAB pool 1410 may include JAVA cloud service assemblies 1412A-N and CRM service assemblies 1414A-N. These assemblies may be instantiated during service provisioning for each JAVA cloud service instance 1428 of each of the identity domains 1424A-N. Each such assembly can be personalized for its associated JAVA cloud service instance 1428 by associating the assembly with an enterprise manager cloud control 1422 and a web tier 1414. Endpoint information used to access each assembly may be sent via email to an application end user (eg, application end user 1404). IDM infrastructure 1416 may include a directory 1418 and an access management module 1420. Provisioned system 1410 may include identity domains 1424A-N and Oracle virtual machine 1426. Each of the identity domains 1424A-N may include its own IDM / SSO module 1426, JAVA cloud service 1428, CRM service 1430, and database server 1432. Oracle cloud service deployment infrastructure 1406 and IDM infrastructure 1416 may interact with provisioned system 1410.

  FIG. 15 illustrates an example JAVA cloud service architecture 1500 that can be used in a cloud-based system to share virtual “slices” of cloud hardware among isolated customers, according to an embodiment of the invention. FIG. The architecture 1500 may include a JAVA cloud service instance 1502, an Exotic storage 1504, and a database cloud service instance 1506. JAVA cloud service instance 1502 may include a plurality of Exalogic compute nodes, such as Exalogic compute nodes 1508A and 1508B. Each Exalogic compute node may include an Oracle virtual machine (OVM) instance, such as OVM instances 1510A and 1510B. Each OVM instance may include managed servers such as managed servers 1512A and 1512B. Each managed server can run multiple separate applications. The managed servers 1512 together constitute a customer dedicated cluster 1514 that provides high availability. The Exalogic computing node 1508 can interact with Exalogic storage 1504. Exotic storage may include a binary volume 1518, a configuration volume 1520, and an application volume 1522. Database service instance 1506 may include Exadata (Oracle Database Schema--Real Application Cluster (RAC) node) 1516. In one embodiment, the web logic node manager may be configured for server restart due to thread deadlocks and JAVA virtual machine (JVM) crashes. Weblogic clustering can be used for standard and enterprise offerings. A service OVM instance, such as OVM instance 1510A-B, may be launched on a separate exologic computing node, such as Exotic computing node 1508A-B. When an OVM fails on one Exalogic compute node, an OVM on another Exalogic compute node can re-activate the failed OVM on the former Exotic compute node. Database cloud service instance 1506 may be in an Oracle RAC one-node configuration.

  FIG. 18 is a block diagram illustrating an example of a database cloud service multi-tenancy architecture 1800 that can be used in a cloud-based system that can use multiple schemas within the same database instance, according to an embodiment of the invention. is there. In terms of terminology, a database instance is a set that executes software processes that collectively function as a database server that can perform operations such as query execution and relational data manipulation. Traditionally, in an enterprise environment for a single organization, a database instance has a single database schema that specifies the format of a relational structure, such as a relational table into which all of the data maintained by that database instance is organized. Was. However, according to one embodiment of the invention, a single database instance hosted in a cloud computing environment can have multiple, separate, and possibly different schemas, each separate identity domain (or “tenancy”). ) One at a time. Advantageously, this many schema vs. one database instance approach allows multiple typically unrelated customers (ie tenants) to run the same set of running database software processes (single database instance). In order to be available, separate instances of those database software processes need not be instantiated for each customer identity domain.

  Architecture 1800 may include a plurality of Exadata compute nodes, such as Exadata compute nodes 1802A-B. Exadata compute nodes 1802A-B can be hardware compute machines. Each such machine may include one or more hardware processing units that perform processor-level fetch-decode-execute operations based on machine language instructions specified by software. Each such machine can be a separate server computing device owned and operated by a cloud-based service provider. Thus, in one embodiment, customers who subscribe to and use database functions provided by the database software running on the Exadata compute nodes 1802A-B do not own the Exadata compute nodes 1802A-B, It just uses a software process that runs on The Exadata compute node 1802A may be communicatively coupled to the Exadata compute node 1802B by one or more packetized networks. In one embodiment, the Exadata compute node 1802B operates as a replica on the Exadata compute node 1802A for redundancy purposes. If the Exadata compute node 1802A fails, the customer can automatically resume operations on the Exadata compute node 1802B until the Exadata compute node 1802A can be recovered.

  Exadata compute nodes 1802A-B may each execute a separate database instance, such as database instance 1804A-B. Each of the database instances 1804A-B may be a separate collection of processes executed from the same database software code set. Each of the database instances 1804A-B may maintain a plurality of separate, separate, typically different database schemas. For example, database instance 1804A may maintain database schema 1806AA-AN, and database instance 1804B may maintain database schema 1806BA-BN. Such maintenance of multiple database schemas per database instance, in accordance with one embodiment of the invention, is in contrast to the conventional one schema per database instance approach. Each of the database schemas 1806AA-AN may be mapped to a separate identity domain. Each of the database instances 1804A-B may maintain metadata identifying a mapping between its database schema and the identity domain to which those database schemas belong. The separation mechanism provided by the shared IDM access control described herein ensures that each identity domain's schema is only accessible and usable by the users and services associated with that identity domain. To do. Database instances 1804A-B can be shared between identity domains, but database schema 1806AA-AN (and their replicas 1806BA-BN) are specialized for individual identity domains and can be separated from all other identity domains Thus, the database schema 1806AA-AN (and their replicas 1806BA-BN) may alternatively be referred to as a “database service instance”. Thus, according to one embodiment of the invention, reference herein to “database service instance” refers to a schema-database instance pair rather than a database instance alone.

  Each database schema may specify multiple distinct relational tables. For example, within database instance 1804A, database schema 1806AA may identify relational table 1808AAA-1808AAN, and database schema 1806AN may identify relational table 1808ANA-1808ANN. As another example, within database instance 1804B, database schema 1806BA may identify relational table 1808BAA-1808BAN, and database schema 1806BN may identify relational table 1808BNA-1808BNN. Since the Exadata compute node 1802B can be a replica of the Exadata compute node 1802A, the database schema 1806BA-BN along with the relational table 1808BAA-1808BNN can be a replica of the database schema 1806AA-AN along with the relational table 1808AAA-1808ANN. Changes made to the database schema or relational tables on the Exadata compute node 1802A can be automatically communicated and replicated on the Exadata compute node 1802B. Each database schema may also specify a separate set of stored procedures, triggers, etc.

  Architecture 1800 may also include cloud storage 1810. The cloud storage 1810 may be composed of a plurality of hardware storage devices, such as hard disk drives, which may be separate but connected to each other. These storage apparatuses are not necessarily so, but may be different and different from the Exadata operation nodes 1802A-B in some cases. Since data accessed and managed by the Exadata compute nodes 1802A-B can be distributed among various storage devices, some of the data accessed and managed by individual compute nodes can be shared between multiple separate storage devices. And / or at least part of data accessed and managed by one computing node is stored in at least part of the same storage device as data accessed and managed by another computing node Can be done. In fact, in one embodiment, the Exadata compute node 1802B is a replica of the Exadata compute node 1802A, so that each of these compute nodes can share the same copy of database data. In such a scenario, computational resources such as execution of database software processes may be replicated, but data records accessed and maintained by those processes may be shared between replicas. The hardware storage devices that make up the cloud storage 1810 can be owned and operated by a cloud service provider, which typically stores its data records in those hardware storage devices as described above. Different and different from the customers who were made.

  The cloud storage 1810 can store the table areas 1812A-N. In one embodiment, each database schema has a separate dedicated tablespace in which data matching that database schema is stored. For example, tablespace 1812A may be dedicated to storing data that matches database schema 1806AA (and database schema 1806BA as its replica), and tablespace 1812B may be in database schema 1806AN (and database schema 1806BN as its replica). It may be dedicated to storing matching data. In one embodiment, these tablespaces are accessible only through database instance 1804A-B, so the separation imposed on database instance 1804A-B by the shared IDM access control described herein. The mechanism is sufficient to ensure that each of the table regions 1812A-N is separated from each of the table regions 1812A-N. As a result, in one embodiment, the various tablespaces 1812A-N may be physically distributed and stored among separate hardware storage devices that are not necessarily strictly dedicated to individual identity domains. Only users and service instances that belong to the same identity domain as a particular database schema (and if authorized by policy) are allowed to access any of the data that matches that particular database schema. The In other words, even if each physical storage device is dedicated to a separate identity domain, it does not necessarily guarantee that the tablespaces 1812A-N are dedicated to database schemas belonging to each of those identity domains.

  Each of the table areas 1812A-N can store a separate data file. For example, each of the table areas 1812A-N may store a data file 1814A-N, respectively. Each specific data file in data file 1814A-N is a data record (eg, a relational table row) that is logically contained within a relational table defined by a database schema that is dedicated to the tablespace that stores that specific data file. ) May be physically included. For example, assuming that tablespace 1812A is dedicated to database schema 1806AA, data file 1814A is logically included in relational table 1808AAA-AAN (and logically included in relational table 1808BAA-BAN, which is a replica thereof). Data records may be physically included. As another example, assuming that tablespace 1812B is dedicated to database schema 1806AN, data file 1814B is logically included in relational table 1808ANA-ANN (and logically in relational table 1808BNA-BNN which is a replica thereof). Data records) may be physically included.

  FIG. 19 is a block diagram illustrating an example of a Nuviaq cloud system 1900 according to an embodiment of the invention. A system 1900 includes a tenant provisioning system (SDI) 1902, a tenant console 1904, an integrated development environment (IDE) 1906, a command line interface (CLI) 1908, a web gate 1910, a Nuviaq proxy 1912, a Nuviaq manager 1918, and a Nuviaq database. 1924, platform instance 1926, virus scanning module 1934, IDM system 1936, CRM module 1942, and identity management 1940. Together, Nuviaq proxy 1912, Nuviaq manager 1918, and Nuviaq database 1924 conceptually constitute Nuviaq 1950. The tenant provisioning API 1902 and the tenant console 1904 can interact with the Nuviaq proxy 1912. IDE 1906 and CLI 1908 may interact with Nuviaq manager 1918. Webgate 1910 may interact with platform instance 1926. Nuviaq manager 1918 may interact with Nuviaq database 1924, virus scan module 1934, IDM system 1936, and platform instance 1926. Platform instance 1926 may interact with CRM module 1942 and identity management 1940. Nuviaq proxy 1912 may include an Oracle Hypertext Transfer Protocol server (OHS) 1914 and a web logic server 1916A-N. Nuviaq manager 1918 may include OHS 1920 and web logic servers 1922A-N. Platform instance 1926 may include a web logic server 1928A-N, a web logic management server 1930, and an instance database 1932.

  In one embodiment, Nuviaq manager 1918 may serve as an entry point to system 1900. As such an entry point, Nuviaq manager 1918 may provide secure access to PaaS operations via a secure web service API. Nuviaq manager 1918 may track the state of system 1900 in Nuviaq database 1924. Nuviaq manager 1918 may control job execution. The tenant provisioning system (SDI) 1902 may access the Nuviaq manager 1918 and instruct the Nuviaq manager 1918 to perform provisioning operations (eg, service instance provisioning operations) under a cloud-based computing environment. The tenant console 1914 can access the Nuviaq manager 1918 and instruct the Nuviaq manager 1918 to perform deployment operations (eg, service instance deployment operations) under a cloud-based computing environment. Nuviaq manager 1918 may execute jobs related to such operations asynchronously. Such a job may include a sequence of actions specific to the PaaS workflow. Nuviaq manager 1918 may perform job actions sequentially. Such actions may include delegating tasks to other components, such as an Enterprise Manager (EM) module command line interface. Nuviaq manager 1918 may be run on a cluster of web logic servers 1920A-N with OHS 1920.

  In one embodiment, the Nuviaq proxy 1912 can be an access point that other systems can communicate with via the API. Nuviaq proxy 1912 may receive requests from other systems via this API and forward those requests to Nuviaq manager 1918. In one embodiment, Nuviaq proxy 1912 may be located outside the firewall within which Nuviaq manager 1918 is located. Nuviaq proxy 1912 may be run on a cluster of web logic servers 1916A-N along with OHS 1914.

  In one example, Nuviaq database 1924 may track platform instance 1926 and data related to deployment plans, applications, web logic domains, jobs, and alerts. The primary key stored in the Nuviaq database 1924 is a cloud that contains mappings between customers (or “tenants”), their identity domains (or “tenancy”), and service instances to which those customers have subscribed. It may be matched with a key stored in a wide service database (not shown).

  In one embodiment, platform instance 1926 provides web logic service resources for a particular identity domain. Thus, a separate platform instance 1926 can be instantiated for each separate identity domain and dedicated to that identity domain under a cloud-based environment. However, since each such platform instance 1926 can be centrally managed by Nuviaq manager 1918, only one instance of Nuviaq manager 1918 need be instantiated. In one embodiment, Nuviaq manager 1918 is a component that creates each separate platform instance 1926 for each identity domain. Platform instance 1926 can be imagined as a “slice” dedicated to the identity domain of the Weblogic server. Some workflows processed by Nuviaq 1950, as indicated by the mappings stored in the service database, serve the web logic “slice” as a client to the various other service instances that the customer subscribes to. Access to the service database described above may be included. The tenant console 1904 provides a user interface for appointed administrators in an identity domain to allow those administrators to manage applications running on platform instances 1926 included in that identity domain. obtain. In addition, CLI 1908 can be used to manage such applications. Each platform instance 1926 can be assigned an identifier that is unique within the cloud computing environment, and can be used to reference the platform instance 1926 in operations that utilize that platform instance 1926.

  In one embodiment, Nuviaq 1950 may operate with components external to Nuviaq 1950 to perform web logic workflows. Of these external components, the tenant provisioning module (SDI) 1902 may include an assembly deployer subsystem. The assembly deployer subsystem may manage the interaction between Nuviaq 1950, Oracle Virtual Assembly Builder (OVAB) and Oracle Virtual Machine (OVM). Nuviaq 1950 can use an assembly deployer subsystem to deploy assemblies, undeploy assemblies, describe assembly deployments, and scale appliances. Nuviaq 1950 may access the assembly deployer subsystem via a web service API.

  In addition, among external components, the virus scanning module 1934 scans various artifacts for viruses and other harmful executable instructions, and then those artifacts are deployed to any application in the cloud computing environment. Allow. Virus scan module 1934 may provide “scan as a service” to multiple distinct components in a cloud computing environment. In one embodiment, the virus scanning module 1934 may provide its services to components in multiple separate identity domains, so that no separate virus scanning module needs to be instantiated for each identity domain. The IDM system 1936, described in detail above, can provide security for jobs performed by Nuviaq 1950. CRM module 1942 may be associated with JAVA service instances located in various identity domains. Such an association between these JAVA service instances and the CRM module 1942 is such that an application executed by such a JAVA service instance makes a CRM service of the CRM module 1942 by making a web service call to the CRM module 1942. Makes it possible to do.

Hardware Overview FIG. 9 is a simplified block diagram illustrating components of a system environment 900 that may be used in accordance with an embodiment of the present invention. As shown, the system environment 900 includes one or more client computing devices 902 configured to run client applications, including unique client applications and possibly other applications such as web browsers, etc. 904, 906 and 908. In various embodiments, client computing devices 902, 904, 906 and 908 may interact with server 912.

  Client computing devices 902, 904, 906 and 908 include general purpose personal computers (by way of example, personal computers and / or laptop computers running various versions of Microsoft Windows and / or Apple Macintosh operating systems). ), Mobile phones or PDAs (running software such as Microsoft Windows Mobile and being the Internet, e-mail, SMS, BlackBerry or other communication protocols that can be used) and / or various commercially available UNIX® ) Or operating systems such as UNIX (including various GNU / Linux operating systems) There may be a workstation computer running one of those not be) to be limited thereto. Alternatively, client computing devices 902, 904, 906 and 908 are thin client computers that can communicate over a network (eg, network 910 described below), games capable of connecting to the Internet. Other electronic devices such as personal computers and / or personal messaging devices. Although an exemplary system environment 900 is shown with four client computing devices, any number of client computing devices may be supported. Other devices, such as devices having sensors, may interact with the server 912.

  System environment 900 may include a network 910. The network 910 is familiar to those skilled in the art that can support data communications using any of a variety of commercially available protocols including, but not limited to, TCP / IP, SNA, IPX, AppleTalk, etc. It can be any type of network. By way of example only, network 910 includes an Ethernet network, a local area network (LAN) such as a token ring network, a wide area network, or a virtual private network (VPN). But not limited to virtual networks, the Internet, intranets, extranets, public switched telephone networks (PSTN), infrared networks, wireless networks (eg IEEE 802.11 series of protocols, known in the art) Network that operates under any of the Bluetooth® protocols and / or other wireless protocols), and / or these and / or other networks. It may be any combination of the work.

  The system environment 900 also includes one or more server computers 912. The server computer 912 may be a general-purpose computer, a specialized server computer (including, for example, a PC server, a UNIX server, a midrange server, a mainframe computer, a rack mount server, etc.), a server farm, a server cluster, or other appropriate Any arrangement and / or combination. In various embodiments, server 912 may be adapted to execute one or more services or software applications.

  Server 912 may execute an operating system including any of the above in addition to commercially available server operating systems. Server 912 may execute any of a variety of additional server applications and / or middle tier applications, including HTTP servers, FTP servers, CGI servers, Java servers, database servers, and the like. Exemplary database servers include, but are not limited to, those commercially available from Oracle, Microsoft, Sybase, IBM, and the like.

  System environment 900 may also include one or more databases 914 and 916. Databases 914 and 916 may exist at various locations. As an example, one or more of databases 914 and 916 may reside on a non-transitory storage medium that is local to server 912 (and / or resides on server 912). Alternatively, the databases 914 and 916 may be remote from the server 912 and communicate with the server 912 via a network-based connection or a dedicated connection. In one set of embodiments, the databases 914 and 916 may reside in a storage-area network (SAN) familiar to those skilled in the art. Similarly, any files necessary to perform functions attributable to server 912 may be stored locally and / or remotely on server 912 as appropriate. In one set of embodiments, databases 914 and 916 include relational databases adapted to store, update and retrieve data in response to SQL formatted commands, such as those provided by Oracle. obtain.

  FIG. 10 is a simplified block diagram of a computer system 1000 that may be used in accordance with an embodiment of the present invention. For example, the server 912 or the clients 902, 904, 906, or 908 may be realized using a system such as the system 1000. A computer system 1000 is shown that includes hardware elements that can be electrically connected via a bus 1024. The hardware elements include one or more central processing units (CPUs) 1002, one or more input devices 1004 (eg, mouse, keyboard, etc.), and one or more output devices 1006 (eg, display devices, printers). Etc.). Computer system 1000 may also include one or more storage devices 1008. As an example, the storage device 1008 may be a disk drive, optical storage device, and solid state storage device, eg, random access memory (RAM) and / or read only memory (RAM), which may be programmable, flash updatable, etc. A storage device such as a read-only memory (ROM) may be included.

  The computer system 1000 includes a computer readable storage media reader 1012, a communication subsystem 1014 (eg, a modem, network card (wireless or wired), infrared communication device, etc.), and working memory that may include the RAM and ROM devices described above. 1018 may additionally be included. In some embodiments, the computer system 1000 may also include a processing acceleration unit 1016 that may include a digital signal processor (DSP), a dedicated processor, and the like.

  Further, the computer readable storage media reader 1012 is a remote, local, fixed for containing computer readable information both temporarily (and optionally in combination with the storage device 1008) temporarily and / or more permanently. And / or connectable to a computer readable storage medium 1010 representative of a removable storage device plus storage medium. The communication system 1014 may allow the exchange of data with the network 910 and / or any other computer described above with respect to the system environment 900.

  Computer system 1000 is also located at this time in working memory 1018 that includes an operating system 1020 and / or other code 1022, such as an application program (which may be a client application, a web browser, a middle tier application, an RDBMS, etc.), and the like. Software elements shown as such. In a specific embodiment, working memory 1018 may include executable code and associated data structures used for a multi-tenant cloud-based IDM system as described above. It is to be understood that alternative embodiments of computer system 1000 can have multiple variations from those described above. For example, customized hardware may be used and / or certain elements may be implemented in hardware, software (including highly portable software such as applets) or both. In addition, connections to other computing devices such as network input / output devices may be utilized.

  Storage media and computer readable media for containing code or portions of code may include any suitable media known or used in the art, including storage media and communication media, Volatile and non-volatile (non-transitory) implemented in any method or technique for storing and / or transmitting information such as computer readable instructions, data structures, program modules or other data RAM, ROM, EEPROM, flash memory or other memory technology, such as removable and non-removable media that can be used to store or transmit the desired information and is accessible by the computer, CD -ROM, digital versatile disk (DVD) or Including but not limited to other optical storage devices, magnetic cassettes, magnetic tapes, magnetic disk storage devices or other magnetic storage devices, data signals, data transmissions, or other media.

  27, 28 and 29 show functional block diagrams of computing devices 2700, 2800, 2900, respectively, configured in accordance with the principles of the present invention as described above. The functional blocks of the computing device may be implemented by hardware, software, or a combination of hardware and software to implement the principles of the present invention. Those skilled in the art will appreciate that the functional blocks described in FIGS. 27, 28 and 29 can be combined or divided into sub-blocks to implement the principles of the invention as described above. Accordingly, the description herein may support any feasible combination or division or further definition of the functional blocks described herein.

  As shown in FIG. 27, the computing device 2700 includes a first creation unit 2702, a first association unit 2704, a first sharing unit 2706, a second creation unit 2708, a second association unit 2710, and A second sharing unit 2712 is included.

  The first creation unit 2702 may create the first identity domain via a shared identity management system. The first association unit 2704 may associate the first plurality of services with the first identity domain. The first sharing unit 2706 may share a first set of identities of users managed by the shared identity management system among the first plurality of services. The second creation unit 2708 may create a second identity domain that is separate from the first identity domain via a shared identity management system. The second association unit 2710 may associate the second plurality of services with the second identity domain. The second sharing unit 2712 may share a second set of identities of users managed by the shared identity management system among the second plurality of services.

  Computing device 2700 may further include first and second mapping units 2714 and 2716. The first mapping unit 2714 provides (a) a first user of a first set of users to a (b) first access permission for a first subset of services via a shared identity management system. Can be mapped. The second mapping unit 2716 provides, via the shared identity management system, (c) second users of the second set of users to (d) second access permissions for the second subset of services. Can be mapped.

  Computing device 2700 may further include third and fourth mapping units 2718 and 2720. The third mapping unit 2718 provides (a) a first user of the first set of users to a (b) first access permission for the first subset of services via a shared identity management system. It can be mapped to the mapped first role. The fourth mapping unit 2720 provides (c) a second user of the second set of users to a second access permission for the second subset of services via a shared identity management system. It can be mapped to the mapped second role.

  Computing device 2700 may further include first and second prevention units 2722, 2724 and an authorization unit 2726. The first prevention unit 2722 may prevent a user in the first set of users from performing operations on services in the second set of services rather than the first set of services. Second prevention unit 2724 may prevent users in the second set of users from performing operations on services in the first set of services rather than the second set of services. Authorization unit 2726 may allow a user to perform operations on both services in the first set of services and services in the second set of services.

  The computing device 2700 further includes a first storage unit 2728 that stores a first set of identities of users in a first partition of a Lightweight Access Protocol (LDAP) directory that is divided by an identity domain; And a second storage unit 2730 that stores the second set of identities of the users in the second partition.

  The computing device 2700 further includes a first presentation unit that presents a user interface that includes a user interface element that allows a particular user to identify a particular identity domain that the particular user is attempting to access as part of the login process. 2732 may further be included.

  The computing device 2700 further includes a second presentation unit 2734 that presents a console that provides control for adding and removing user identities to the identity domain, and a second that receives commands from the identity domain administrator via the console. One receiving unit 2736, a determination unit 2738 for determining a particular identity domain to which the identity domain administrator belongs, and limiting user identity addition and deletion operations performed by the identity domain administrator to a particular identity domain via the console And a limiting unit 2740.

  Computing device 2700 may further include first, second and third allocation units 2742, 2744 and 2746. The first assignment unit 2742 provides identity domain management that gives a first user the ability to assign a service administrator role to a first user of the first set of users to other users in the first set of users. Person roles can be assigned. The second allocation unit 2744 is capable of managing a first service of the first plurality of services to a second user of a first set of users selected by a first user as an identity domain administrator. May be assigned a first service administrator role that grants to a second user. The third allocation unit 2746 is capable of managing a second service of the first plurality of services to a third user of a first set of users selected by the first user as an identity domain administrator. Can be assigned a second service administrator role that grants to a third user.

  The computing device 2700 further does not have a user identity in the first identity domain, but obtains a user identity in the first identity domain from a first person associated with the account from which the first identity domain was purchased. Similarly, from a first person, the first person nominates a second person in the first identity domain, receiving a second person's email address that does not have a second person's email address. An email message that includes a third receiving unit 2750 that receives the role and a hyperlink to a second person's email address that can be used to create a user identity in the first identity domain. Transmitting unit 275 for transmitting A first additional unit 2754 for adding the second person's identity to the user's first set of identities based on information provided by the second person via the web-based form; and a first identity And a fourth assignment unit 2756 that assigns the role to the identity of a second person in the domain.

  The computing device 2700 further includes a fourth receiving unit 2758 that receives a request to add a particular service to the first set of services, and a second that adds the particular service to the first set of services upon request. And a definition unit 2762 that defines a hierarchy of roles automatically selected from a hierarchy of roles based on a particular type of service in the first identity domain.

  The computing device 2700 further includes a first service in an identity store that stores identities for a plurality of identity domains defined under a cloud computing environment, with particular service instances being instances of services in the first set of services. A first bind unit 2764 that binds to a partition, and a particular service instance to a second partition of a policy store that stores policies for multiple service instances belonging to different identity domains defined under a cloud computing environment A second binding unit 2766 for binding. The first partition contains only identities belonging to the first identity domain, and the second partition contains only policies relating to a particular service instance.

  Referring to FIG. 28, the computing device 2800 includes a creation unit 2802, an execution unit 2804, an addition unit 2806, a first storage unit 2808, and a second storage unit 2810. Creation unit 2802 may create multiple identity domains within the cloud computing environment. Enforcement unit 2804 may perform separation between identity domains within multiple identity domains. Add unit 2806 may add a service instance to a particular identity domain of multiple identity domains. The first storage unit 2808 may store data that associates service instances with specific partitions of an identity store that store identities for each identity domain of the plurality of identity domains. The second storage unit 2810 may store data that associates service instances with particular partitions of a policy store that stores policies for multiple service instances associated with different identity domains of multiple identity domains.

  Computing device 2800 may further include a first allocation unit 2812 and a second allocation unit 2814. A first assignment unit 2812 may assign a first role from a hierarchy of roles to a first user having a first user identity stored in an identity store and associated with a particular identity domain. The first role is a role that allows a user having the first role to manage all service instances associated with a particular identity domain. The second assignment unit 2814 may assign a second role from a hierarchy of roles to a second user having a second user identity stored in the identity store. The second role is a role that allows a user with the second role to manage a single service instance associated with a particular identity domain.

  In one example, the second assignment unit 2814 may assign a second role to the second user in response to the first user delegating the second role to the second user.

  In one example, the add unit 2806 further includes a third role defined by a plurality of roles associated with a particular service instance type stored in the identity store and associated with a particular identity domain. A third assignment unit 2816 for assigning to a third user having

  The computing device 2800 may further include a first inheritance unit 2818 and a second inheritance unit 2820. The first inheritance unit 2818 may cause the second role to inherit all permissions associated with the third role. The second inheritance unit 2820 may cause the first role to inherit all permissions inherited by the second role.

  In one example, the creation unit 2802 may create a particular identity domain within the cloud computing environment. In this case, the creation unit 2802 may further include a sending unit 2822 that sends an email message to the identified email address, where the email message recipient has managed identity within a particular identity domain. Provide a mechanism to establish

  With reference to FIG. 29, the computing device 2900 includes an establishment unit 2902, a first provision unit 2904, and a second provision unit 2906. The establishment unit 2902 may establish a single identity management (IDM) system under a cloud computing environment. The first provisioning unit 2904 is associated with the first identity domain in the single IDM system that is defined in the cloud computing environment and separated from the second identity domain defined in the cloud computing environment. The first service instance may be provided with IDM functionality. The second providing unit 2906 may cause the single IDM system to provide IDM functionality to the second service instance associated with the second identity domain.

  The computing device 2900 may further include first and second storage units 2908, 2910 and first and second generation units 2912, 2914. The first storage unit 2908 stores the user identity associated with the first identity domain, rather than the second identity domain in a single identity store maintained in the cloud computing environment, in a single IDM system. Can be. The second storage unit 2910 may cause the single IDM system to store the user identity associated with the second identity domain rather than the first identity domain in a single identity store. A first generation unit 2912 may cause a single IDM system to generate a first credential, where the first credential includes a single service identity that includes a user identity that is not associated with a first identity domain. Allows interaction with a portion of a single identity store that includes a user identity associated with the first identity domain, rather than a portion of the identity store. The second generation unit 2914 may cause the single IDM system to generate the second credential, where the second credential is a single that includes a user identity whose second service instance is not associated with a second identity domain. Allows to interact with a portion of a single identity store that includes a user identity associated with a second identity domain, rather than a portion of the identity store.

  The computing device 2900 may further include third and fourth storage units 2916, 2918 and third and fourth generation units 2920, 2922. The third storage unit 2916 allows the single IDM system to have a security access policy associated with the first service instance, rather than a second service instance in a single policy store maintained in the cloud computing environment. Can be stored. The fourth storage unit 2918 may cause the single IDM system to store the security access policy associated with the second service instance instead of the first service instance in a single policy store. The third generation unit 2920 may cause the single IDM system to generate the first credential, the first credential including a single security access policy that does not associate the first service instance with the first service instance. Allows interaction with a portion of a single policy store that includes a security access policy associated with the first service instance, rather than a portion of one policy store. The fourth generation unit may cause the single IDM system to generate the second credential, the second credential being a single that includes a security access policy in which the second service instance is not associated with the second service instance. Allow interaction with a portion of a single policy store that includes a security access policy associated with the second service instance, rather than a portion of the policy store.

  While specific embodiments of the invention have been described, various modifications, changes, alternative configurations and equivalents are also encompassed within the scope of the invention. Embodiments of the present invention are not limited to operation within a specific specific data processing environment, but can operate freely within a plurality of data processing environments. Further, while embodiments of the present invention have been described using a specific sequence of transactions and steps, it is to be understood that the scope of the present invention is not limited to the set of transactions and steps described. Should be obvious to the contractor.

  Further, although embodiments of the invention have been described using specific combinations of hardware and software, it should be recognized that other combinations of hardware and software are also within the scope of the invention. Embodiments of the present invention may be implemented in hardware only, software only, or a combination thereof.

  Furthermore, an embodiment of the present invention can be defined functionally as follows. Specifically, a system is provided that includes single identity management (IDM) within a cloud computing environment. The system provides IDM functionality to a first service instance that is defined in a cloud computing environment and associated with a first identity domain that is separated from a second identity domain defined in the cloud computing environment. And means for providing IDM functionality to a second service instance associated with the second identity domain.

  Preferably, the system further comprises means for storing a user identity associated with the first identity domain rather than a second identity domain in a single identity store maintained in the cloud computing environment, Means for storing a user identity associated with the second identity domain instead of the first identity domain in the first identity store and means for generating the first credential, the first credential comprising: One service instance is not part of a single identity store that contains user identities that are not associated with a first identity domain, but a user identity associated with a first identity domain. Allowing the system to further interact with a portion of a single identity store that includes the ity, and the system further includes means for generating a second credential, wherein the second credential is the second service instance Allows to interact with a portion of a single identity store that includes a user identity associated with a second identity domain, rather than a portion of a single identity store that includes a user identity that is not associated with a domain.

  Preferably, the system further comprises means for storing a security access policy associated with the first service instance, rather than a second service instance in a single policy store maintained in the cloud computing environment. Means for storing a security access policy associated with the second service instance instead of the first service instance in one policy store, and means for generating the first credential, wherein the first credential is A single service instance includes a security access policy associated with the first service instance, rather than being part of a single policy store that includes a security access policy that is not associated with the first service instance. Allowing the interaction with the portion of the resource store, the system further includes means for generating a second credential, wherein the second credential is a security in which the second service instance is not associated with the second service instance. Allow to interact with the portion of the single policy store that contains the security access policy associated with the second service instance, rather than the portion of the single policy store that contains the access policy.

  The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense. However, it will be apparent that additions, reductions, deletions and other variations and modifications may be made thereto without departing from the broader spirit and scope.

Claims (49)

A computer-implemented method comprising:
Creating a first identity domain via a shared identity management system;
Associating a first plurality of services with the first identity domain;
Sharing a first set of identities of users managed by the shared identity management system between the first plurality of services;
Creating a second identity domain separated from the first identity domain via the shared identity management system;
Associating a second plurality of services with the second identity domain;
Sharing a second set of identities of users managed by the shared identity management system between the second plurality of services. Via the shared identity management system, (a) mapping a first user of the first set of users to a first access permission for a subset of the first plurality of services. When,
Via the shared identity management system, (c) mapping a second user of the second set of users to a second access permission for a subset of the second plurality of services. The computer-implemented method of claim 1, further comprising: Via the shared identity management system, (a) a first user of the first set of users is mapped to a first access permission for (b) a subset of the first plurality of services. Mapping to a first role;
Via the shared identity management system, (c) a second user of the second set of users is mapped to a second access permission for (d) a subset of the second plurality of services. The computer-implemented method of claim 1, further comprising mapping to a second role. Preventing users in the first set of users from performing operations on services in the second set of services rather than the first set of services;
Preventing users in the second set of users from performing operations on services in the first set of services rather than the second set of services;
2. The computer-implemented method of claim 1, further comprising: allowing a user to perform operations on both services in the first set of services and services in the second set of services. Method. Storing the identity of the first set of users in a first partition of a Lightweight Access Protocol (LDAP) directory divided by an identity domain;
The computer-implemented method of claim 1, further comprising storing the identities of the second set of users in a second partition of the LDAP directory.   The computer of claim 1, further comprising presenting a user interface including a user interface element that allows a particular user to identify a particular identity domain that the particular user is trying to access as part of a login process. The method performed by. Presenting a console that provides control for adding and removing user identities from the identity domain;
Receiving a command from the identity domain administrator via the console;
Determining a particular identity domain to which the identity domain administrator belongs;
2. The computer-implemented method of claim 1, further comprising: limiting user identity addition and deletion operations performed by the identity domain administrator to the particular identity domain via the console. Further comprising assigning an identity domain administrator role to a first user of the first set of users, the identity domain administrator role assigning a service administrator role to other users in the first set of users. Giving the first user the ability to assign, the method further comprising:
Assigning a first service administrator role to a second user of the first set of users selected by the first user as an identity domain administrator, the first service administrator role Grants the second user the ability to manage a first service of the first plurality of services, the method further comprising:
Assigning a second service administrator role to a third user of the first set of users selected by the first user as the identity domain administrator, the second service administrator The computer-implemented method of claim 1, wherein a role grants the third user the ability to manage a second service of the first plurality of services. Does not have a user identity in the first identity domain, but also has a user identity in the first identity domain from a first person associated with the account from which the first identity domain was purchased. Receiving no second person's email address;
Receiving from the first person a role in which the first person nominates the second person in the first identity domain;
Sending an email message to the email address of the second person that includes a hyperlink to a web-based form that can be used to create a user identity in the first identity domain;
Adding the identity of the second person to the identity of the first set of users based on information provided by the second person via the web-based form;
The computer-implemented method of claim 1, further comprising assigning the role to the identity of the second person in the first identity domain. Receiving a request to add a particular service to the first set of services;
Adding the particular service to the first set of services in response to the request;
Defining a hierarchy of roles automatically selected from multiple hierarchies of roles in the first identity domain based on the particular service type. A method executed by the computer according to claim 1. Binding a particular service instance that is an instance of a service in the first set of services to a first partition of an identity store that stores identities for a plurality of identity domains defined under a cloud computing environment;
Binding the particular service instance to a second partition of a policy store that stores policies for multiple service instances belonging to different identity domains defined under the cloud computing environment;
The first partition includes only identities belonging to the first identity domain;
The computer-implemented method of claim 1, wherein the second partition includes only policies relating to the particular service instance. A computer readable storage memory storing specific instructions capable of causing one or more processors to perform specified operations, the specific instructions comprising:
Instructions to create multiple identity domains within the cloud computing environment;
Instructions for performing separation between identity domains within the plurality of identity domains;
An instruction to add a service instance to a particular identity domain of the plurality of identity domains;
Instructions for storing data associating the service instance with a particular partition of an identity store that stores identities for each identity domain of the plurality of identity domains;
Computer readable storage comprising: instructions for storing data associating the service instance with a particular partition of a policy store that stores policies for a plurality of service instances associated with different identity domains of the plurality of identity domains memory. The specific instruction is further
Instructions for assigning a first role from a hierarchy of roles to a first user stored in the identity store and having a first user identity associated with the particular identity domain;
The first role is a role that allows a user having the first role to manage all service instances associated with the specific identity domain, the specific instruction further comprising:
Instructions to assign a second role from a hierarchy of roles to a second user having a second user identity stored in the identity store;
The computer of claim 12, wherein the second role is a role that allows a user having the second role to manage a single service instance associated with the particular identity domain. Readable storage memory.  The instruction to assign the second role to the second user is a second instruction to the second user in response to the first user delegating the second role to the second user. The computer readable storage memory of claim 13, comprising instructions for assigning a plurality of roles.  The instruction to add the service instance to the specific identity domain of the plurality of identity domains stores a third role defined by a plurality of roles associated with the type of the specific service instance in the identity store 14. The computer readable storage memory of claim 13, comprising instructions that are assigned to a third user having a third identity associated with the particular identity domain.  The specific instruction includes an instruction that causes the second role to inherit all permissions associated with the third role, and the specific instruction includes the second role and the second role. The computer-readable storage memory of claim 15, comprising instructions for inheriting all permissions inherited by.  The instructions for creating the plurality of identity domains in the cloud computing environment include instructions for creating the specific identity domain in the cloud computing environment, and the specific identity domain in the cloud computing environment. The creating instruction includes an instruction to send an email message to a specified email address, wherein the email message is a mechanism by which a recipient of the email message can establish a management identity within the particular identity domain The computer readable storage memory of claim 12, wherein: An apparatus, the apparatus comprising:
One or more processors;
A computer readable storage memory storing specific instructions, wherein the specific instructions are:
Instructions to establish a single identity management (IDM) system in a cloud computing environment;
A first service instance associated with a first identity domain defined in the cloud computing environment and separated from a second identity domain defined in the cloud computing environment in the single IDM system An instruction to provide the IDM function,
An apparatus comprising: causing the single IDM system to provide an IDM function to a second service instance associated with the second identity domain. The specific instruction is further
Instructions for causing the single IDM system to store a user identity associated with the first identity domain rather than the second identity domain in a single identity store maintained in the cloud computing environment;
Instructions for causing the single IDM system to store a user identity associated with the second identity domain instead of the first identity domain in the single identity store;
Instructions for causing the single IDM system to generate a first credential, wherein the first credential includes the single service instance including a user identity that is not associated with the first identity domain. Allowing to interact with a portion of the single identity store that includes a user identity associated with the first identity domain, rather than a portion of the identity store of
Instructions for causing the single IDM system to generate a second credential, wherein the second credential includes the single identity that includes a user identity that is not associated with the second identity domain. 19. The apparatus of claim 18, which allows interaction with a portion of the single identity store that includes a user identity associated with the second identity domain rather than a portion of an identity store. The specific instruction is further
Instructions for causing the single IDM system to store a security access policy associated with the first service instance rather than the second service instance in a single policy store maintained within the cloud computing environment; ,
Instructions for causing the single IDM system to store a security access policy associated with the second service instance instead of the first service instance in the single policy store;
Instructions for causing the single IDM system to generate a first credential, wherein the first credential includes the security access policy in which the first service instance is not associated with the first service instance. Allowing to interact with a portion of the single policy store that includes a security access policy associated with the first service instance, rather than a portion of one policy store, and the specific instruction further comprises:
Instructions for causing the single IDM system to generate a second credential, wherein the second credential includes a security access policy in which the second service instance is not associated with the second service instance. 19. The apparatus of claim 18, which permits interaction with a portion of the single policy store that includes a security access policy associated with the second service instance, rather than a portion of the policy store. A computer-implemented method comprising:
Storing metadata defining the identity domain to create a first identity domain via a shared identity management system;
Associating a first plurality of services with the first identity domain by creating a mapping between them;
Sharing a first set of identities of users managed by the shared identity management system between the first plurality of services based at least in part on each user-based mapping;
Storing metadata defining another identity domain via the shared identity management system to create a second identity domain separated from the first identity domain;
Associating a second plurality of services with the second identity domain;
Sharing a second set of identities of users managed by the shared identity management system between the second plurality of services. Via the shared identity management system, (a) mapping a first user of the first set of users to a first access permission for a subset of the first plurality of services. When,
Via the shared identity management system, (c) mapping a second user of the second set of users to a second access permission for a subset of the second plurality of services. The computer-implemented method of claim 21, further comprising: Via the shared identity management system, (a) a first user of the first set of users is mapped to a first access permission for (b) a subset of the first plurality of services. Mapping to a first role;
Via the shared identity management system, (c) a second user of the second set of users is mapped to a second access permission for (d) a subset of the second plurality of services. 23. The computer-implemented method of claim 21 or 22, further comprising the step of mapping to a second role. Based at least in part on a mapping that defines one or more services assigned to each of the users, a user in the first set of users is not a first set of services but a second of the services. Preventing operations on services in the set of:
Preventing users in the second set of users from performing operations on services in the first set of services rather than the second set of services;
24. allowing a user to perform operations on both a service in the first set of services and a service in the second set of services. A method performed by the computer described. Storing the identity of the first set of users in a first partition of a Lightweight Access Protocol (LDAP) directory divided by an identity domain;
25. The computer-implemented method of any of claims 21-24, further comprising storing the identity of the second set of users in a second partition of the LDAP directory.   26. The method of any of claims 21-25, further comprising presenting a user interface including a user interface element that allows a particular user to identify a particular identity domain that the particular user is trying to access as part of a login process. A method executed by the computer according to claim 1. Presenting a console that provides control for adding and removing user identities from the identity domain;
Receiving a command from the identity domain administrator via the console;
Determining a particular identity domain to which the identity domain administrator belongs;
27. Performed by a computer according to any one of claims 21 to 26, further comprising the step of restricting user identity addition and deletion operations performed to the particular identity domain via the console by the identity domain administrator. How to be. Assigning to the first user of the first set of users an identity domain administrator role that grants the first user the ability to assign a service administrator role to other users in the first set of users. When,
The second user of the first set of users selected by the first user as an identity domain administrator has the ability to manage a first service of the first plurality of services. Assigning a first service administrator role to be granted to a user;
A third user of the first set of users selected by the first user as the identity domain administrator has the ability to manage a second service of the first plurality of services. 28. A computer-implemented method according to any one of claims 21 to 27, further comprising assigning a second service administrator role to be granted to the user. Does not have a user identity in the first identity domain, but also has a user identity in the first identity domain from a first person associated with the account from which the first identity domain was purchased. Receiving no second person's email address;
Receiving from the first person a role in which the first person nominates the second person in the first identity domain;
Sending an email message to the email address of the second person that includes a hyperlink to a web-based form that can be used to create a user identity in the first identity domain;
Adding the identity of the second person to the identity of the first set of users based on information provided by the second person via the web-based form;
29. The computer-implemented method of any one of claims 21 to 28, further comprising assigning the role to the identity of the second person in the first identity domain. Receiving a request to add a particular service to the first set of services;
Adding the particular service to the first set of services in response to the request;
30. further comprising defining a hierarchy of roles automatically selected from a plurality of hierarchies of roles based on the particular service type in the first identity domain. A computer-implemented method according to claim 1. Binding a particular service instance that is an instance of a service in the first set of services to a first partition of an identity store that stores identities for a plurality of identity domains defined under a cloud computing environment;
Binding the particular service instance to a second partition of a policy store that stores policies for multiple service instances belonging to different identity domains defined under the cloud computing environment;
The first partition includes only identities belonging to the first identity domain;
31. The computer-implemented method according to any one of claims 21 to 30, wherein the second partition includes only policies relating to the specific service instance. A computer readable program that causes one or more processors to perform specified operations, the computer readable program comprising:
Instructions for storing metadata defining identity domains to create multiple identity domains in a cloud computing environment;
Instructions for performing separation between identity domains within the plurality of identity domains;
An instruction to add a service instance to a particular identity domain of the plurality of identity domains;
Data that associates the service instance with a specific partition of an identity store that stores identities for each identity domain of the plurality of identity domains by creating a mapping between the service instance and the specific identity domain An instruction to store
A computer readable program comprising: instructions for storing data associating the service instance with a particular partition of a policy store that stores policies for a plurality of service instances associated with different identity domains of the plurality of identity domains. . Further comprising instructions for assigning a first role from a hierarchy of roles to a first user having a first user identity stored in the identity store and associated with the particular identity domain;
The first role is a role that allows a user having the first role to manage all service instances associated with the particular identity domain, the computer-readable program further comprising:
Instructions to assign a second role from a hierarchy of roles to a second user having a second user identity stored in the identity store;
The computer of claim 32, wherein the second role is a role that allows a user having the second role to manage a single service instance associated with the particular identity domain. A readable program.   The instruction to assign the second role to the second user is a second instruction to the second user in response to the first user delegating the second role to the second user. 34. The computer readable program of claim 33, comprising instructions for assigning a role.   The instruction to add the service instance to the specific identity domain of the plurality of identity domains stores a third role defined by a plurality of roles associated with the type of the specific service instance in the identity store 35. The computer readable program of claim 33 or 34, comprising instructions for assigning to a third user having a third identity associated with the particular identity domain.   And further including an instruction that causes the second role to inherit all permissions associated with the third role, wherein the specific instruction is all inherited by the second role to the first role. 36. The computer readable program of claim 35, comprising instructions for inheriting the permissions of.   The instructions for creating the plurality of identity domains in the cloud computing environment include instructions for creating the specific identity domain in the cloud computing environment, and the specific identity domain in the cloud computing environment. The creating instruction includes an instruction to send an email message to a specified email address, wherein the email message is a mechanism by which a recipient of the email message can establish a management identity within the particular identity domain 37. A computer readable program according to any one of claims 32-36, wherein: A system including single identity management (IDM) in a cloud computing environment, the system comprising:
Providing IDM functionality to a first service instance defined in the cloud computing environment and associated with a first identity domain that is separate from a second identity domain defined in the cloud computing environment Means,
Means for providing IDM functionality to a second service instance associated with the second identity domain. Means for storing a user identity associated with the first identity domain instead of the second identity domain in a single identity store maintained within the cloud computing environment;
Means for storing a user identity associated with the second identity domain rather than the first identity domain in the single identity store;
Means for generating a first credential, wherein the first credential includes a portion of the single identity store where the first service instance includes a user identity that is not associated with the first identity domain Rather, allowing the system to interact with a portion of the single identity store that includes a user identity associated with the first identity domain, the system further comprises:
Means for generating a second credential, wherein the second credential is not part of the single identity store where the second service instance contains a user identity that is not associated with the second identity domain. 39. The system of claim 38, allowing to interact with a portion of the single identity store that includes a user identity associated with the second identity domain. Means for storing a security access policy associated with the first service instance rather than the second service instance in a single policy store maintained in the cloud computing environment;
Means for storing a security access policy associated with the second service instance instead of the first service instance in the single policy store;
Means for generating a first credential, wherein the first credential includes a security access policy in which the first service instance is not associated with the first service instance. Allowing to interact with a portion of the single policy store that includes a security access policy associated with the first service instance rather than a portion, the system further comprising:
Means for generating a second credential, wherein the second credential is a portion of the single policy store that includes a security access policy in which the second service instance is not associated with the second service instance. 40. The system of claim 38 or 39, wherein the system permits interaction with a portion of the single policy store that includes a security access policy associated with the second service instance. A computer readable medium, wherein the computer readable medium, when executed by one or more processors,
Instructions to create multiple identity domains within the cloud computing environment;
Instructions for performing separation between identity domains within the plurality of identity domains;
Instructions to add a service instance to a particular identity domain of the plurality of identity domains;
Instructions for storing data associating the service instance with a particular partition of an identity store that stores identities for each identity domain of the plurality of identity domains;
Computer-readable, comprising instructions for storing data that associates the service instance with a particular partition of a policy store that stores policies for a plurality of service instances associated with different identity domains of the plurality of identity domains Medium. When the instructions are executed by the one or more processors, the instructions are
Causing a first user stored in the identity store and having a first user identity associated with the particular identity domain to be assigned a first role from a hierarchy of roles;
The first role is a role that allows a user having the first role to manage all service instances associated with the particular identity domain, the instructions further comprising the one When executed by the above processor, the computer
Causing a second user having a second user identity stored in the identity store to be assigned a second role from the hierarchy of roles;
42. The computer of claim 41, wherein the second role is a role that allows a user having the second role to manage a single service instance associated with the particular identity domain. A readable program.   When the instructions are executed by the one or more processors, the second user is responsive to the computer from the first user delegating the second role to the second user. 43. The computer-readable program according to claim 41 or 42, wherein the computer assigns the second role to the computer.   When the instructions are executed by the one or more processors, the computer stores a third role defined by a plurality of roles associated with the particular service instance type in the identity store. 44. A computer readable medium according to any one of claims 41 to 43, which is assigned to a third user having a third identity associated with the particular identity domain.   When the instructions are executed by the one or more processors, the computer causes the second role to inherit all permissions associated with the third role, the instructions being the one 45. Computer according to any one of claims 41 to 44, wherein when executed by the above processor, the computer causes the first role to inherit all permissions inherited by the second role. A readable medium.   The instructions, when executed by the one or more processors, cause the computer to create the specific identity domain in the cloud computing environment, and the instructions are executed by the one or more processors. Causing the computer to send an e-mail message to a specified e-mail address, the e-mail message providing a mechanism by which a recipient of the e-mail message can establish a management identity within the specific identity domain The computer-readable medium according to any one of claims 41 to 45. A system, the system comprising:
One or more processors;
A computer-readable medium, the computer-readable medium being executed by the one or more processors,
Instructions to establish a single identity management (IDM) system in a cloud computing environment;
A first service instance associated with a first identity domain defined in the cloud computing environment and separated from a second identity domain defined in the cloud computing environment in the single IDM system An instruction to provide the IDM function,
A system that retains instructions that cause the single IDM system to provide IDM functionality to a second service instance associated with the second identity domain. The computer-readable medium, when executed by the one or more processors, causes the computer to
Instructions for causing the single IDM system to store a user identity associated with the first identity domain rather than the second identity domain in a single identity store maintained in the cloud computing environment;
Instructions for causing the single IDM system to store a user identity associated with the second identity domain instead of the first identity domain in the single identity store;
Instructions for causing the single IDM system to generate a first credential, wherein the first credential includes the single service instance including a user identity that is not associated with the first identity domain. Allowing to interact with a portion of the single identity store that includes a user identity associated with the first identity domain, rather than a portion of one identity store, the computer-readable medium further comprising the one When executed by the above processor, the computer
An instruction to cause the single IDM system to generate a second credential, wherein the second credential includes the single identity that includes a user identity that is not associated with the second identity domain. 48. The system of claim 47, which allows interaction with a portion of the single identity store that includes a user identity associated with the second identity domain, rather than a portion of the identity store. The computer-readable medium, when executed by the one or more processors, causes the computer to
Instructions for causing the single IDM system to store a security access policy associated with the first service instance rather than the second service instance in a single policy store maintained within the cloud computing environment; ,
Instructions for causing the single IDM system to store a security access policy associated with the second service instance instead of the first service instance in the single policy store;
Instructions for causing the single IDM system to generate a first credential, wherein the first credential includes a security access policy in which the first service instance is not associated with the first service instance. Allowing interaction with a portion of the single policy store that includes a security access policy associated with the first service instance rather than a portion of a single policy store, the computer-readable medium further comprising: When executed by one or more processors, the computer includes:
Instructions for causing the single IDM system to generate a second credential, wherein the second credential includes the security access policy in which the second service instance is not associated with the second service instance. 49. A system according to claim 47 or 48 that allows interaction with a portion of the single policy store that includes a security access policy associated with the second service instance rather than a portion of one policy store.

Images