Unified identity service for multi-tenant architecture

Abstract

A method for using a unified identity in a multi-tenant architecture system is discussed. The method includes receiving a request to provide a service to a user at a first service provider. The method includes accessing a representation of a second service provider in a first hierarchical data structure managed by the first service provider. The method includes determining that user data required for the service is managed by a second service provider that manages a user identity of the user. The method includes determining that the representation is linked to a full identity reference for the second service provider in a second hierarchical data structure managed by the second service provider. The method includes accessing the user data at the second hierarchical data structure using the full identity reference. The method includes accessing the service at the first service provider via a lightweight identity reference and using the user data.

Description

Background Art

[0001] Embodiments of the present disclosure relate generally to the field of software architecture, and more particularly, to managing how various entities are onboarded, managed, and / or accessed in a multi-tenant system architecture.

[0002] Complex software systems can have a variety of architectures, including single-tenant software architectures and multi-tenant software architectures. In a single-tenant software architecture, each entity (such as a company or part of that company) can have its own instance of each software application, data, and any supporting infrastructure. In a single-tenant architecture, the software for each tenant entity can be customized as needed. However, the disadvantages of using a single-tenant architecture include: expensive resource costs, and the need to host, customize, and maintain separate software applications for each tenant.

[0003] In contrast, in a multi-tenant software architecture, each entity can share the same instance of an application, data, and / or infrastructure. A multi-tenant software provider can provide its applications and / or resources to multiple entities from a single software architecture. In a multi-tenant software architecture, access to data can be shared between various entities. By sharing many applications, data, and software, various resources such as installation, configuration, the number of physical servers, maintenance, and even electricity can be optimized. However, the disadvantages of using a multi-tenant architecture include: managing the complexity of how to share and configure multiple software applications between multiple clients. Moreover, it may be problematic to provide secure and reliable access to data based on the design of a multi-tenant architecture for a software system. In addition, interoperability difficulties may arise when software applications that were originally managed and / or hosted by different enterprises are used in a multi-tenant architecture system. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] The present embodiments may be better understood, and its numerous objects, features and advantages made apparent to those skilled in the art by referencing the accompanying drawings.

[0005] Figure 1 is a system diagram illustrating an embodiment of a multi-tenant software architecture system that may be accessed through communications with a user device.

[0006] Figure 2 It shows the unified identity service Figure 1 A system diagram of an embodiment of a multi-tenant software architecture.

[0007] Figure 3 is a diagram showing a hierarchical data structure used by a multi-tenant software architecture system providing a unified identity service.

[0008] Figure 4 is another diagram illustrating a hierarchical data structure used by a multi-tenant software architecture system providing a unified identity service.

[0009] Figure 5 is a flow diagram illustrating an embodiment of operations for onboarding and accessing tenants in a tenant software architecture system using a unified identity service.

[0010] Figure 6 is a flow diagram illustrating an embodiment of the operation of a system for using a multi-tenant software architecture providing a unified identity service.

[0011] Figure 7 It shows that Figure 1-6 A block diagram of an embodiment of an electronic device used in a communication system. DETAILED DESCRIPTION

[0012] The following description includes exemplary systems, methods, techniques, instruction sequences, and / or computer program products that implement the techniques of the present disclosure. However, it should be understood that the described embodiments may be practiced without these specific details. For example, although some examples involve accessing tenant services, other types of service providers, such as software as a service (SaaS), etc., are also contemplated.

[0013] In the multi-tenant software architecture described herein, each tenant can share applications, data, and / or infrastructure. A multi-tenant software provider can use a multi-tenant software platform to supply applications and / or resources to multiple entities. The multi-tenant software platform can facilitate the addition of new tenants and the loading of data and / or services provided by these new tenants. The multi-tenant software platform can use identity services to provide access to these services, such as accessing services provided by another tenant from an entity associated with one tenant. The multi-tenant software platform can also implement rules and policies for data access by various entities throughout the tenants.

[0014] A multi-tenant software platform (also referred to as a multi-tenant platform) may include multiple tenants that have been previously loaded. A multi-tenant platform may use a unified identity associated with a user to facilitate access to entities, policies, and services of these tenants. Tenants may be hosted and managed by a service provider. Access to services may be determined based on the privileges of the unified identity and the policies of each tenant. Services may include various merchant services, such as in-store checkout via a user device (associated with a unified identity), access to a tenant's online store, advance ordering at a tenant's store, a deposit process at a tenant (e.g., at an automated teller machine (ATM)), a cash withdrawal process (e.g., at an ATM), automatic checkout for refueling at a tenant's gas station, and the like. Services may include SaaS and platform as a service (PaaS) services and / or other cloud services accessible to user devices. For example, a solution provider may provide access to user devices, various software applications, or deliver such software to user devices.

[0015] Therefore, the multi-tenant platform can provide access to selected services and / or data of tenants using a unified identity service based on policies associated with each tenant. The multi-tenant platform can use a separate database to store data to achieve isolation, such as when a new tenant is loaded into an existing platform, which provides logical and / or physical data isolation. Shared data access can be performed by loading tenants and selectively cross-exposing services. For example, for a multi-tenant platform managed by PAYPAL, certain capabilities of the multi-tenant platform (e.g., Risk as a Service (RaaS)) can be provided to certain users of tenants (such as XOOM) that have been loaded. Similarly, certain capabilities of XOOM (such as fund sending) can be provided to certain users of PAYPAL. Therefore, in some embodiments, the multi-tenant platform may include a core tenant (such as PAYPAL) that provides core services and infrastructure (including identity as a service (IaaS) functions) and any other data access to selected tenants and / or users who access the multi-tenant platform from this tenant. The level of access to core services and / or infrastructure can be determined by the rules and / or policies of each tenant and / or multi-tenant platform.

[0016] The multi-tenant platform can load new tenants as needed by using one or more hierarchical data structures. In some embodiments, the multi-tenant platform can expose a suitable user experience for user applications based on user requests. The multi-tenant platform can implement methods for providing IaaS services to various entities and / or tenants. The multi-tenant platform can provide IaaS and other services based on the hierarchical data structure. As described below, the multi-tenant platform can process user requests (e.g., users from core tenants or users of already loaded tenants) and determine how to access specific services.

[0017] In some embodiments, a multi-tenant platform may receive a request to provide a service to a user at a first service provider. The multi-tenant platform may access a representation of a second service provider in a first hierarchical data structure managed by the first service provider. In some embodiments, the multi-tenant platform is a first service provider that may provide certain services to an entity referenced by an identifier determined using IaaS. The multi-tenant platform may determine that the user data required for the service is managed by a second service provider that manages the user identity of the user. The multi-tenant platform may determine that the representation is linked to a full identity reference (identity reference) for the second service provider in a second hierarchical data structure managed by the second service provider. The multi-tenant platform may access user data at the second hierarchical data structure using a full identity reference. The multi-tenant platform may access services at the first service provider via a lightweight identity reference and using user data. The following description and associated drawings illustrate various embodiments for the ideas listed above.

[0018] Figure 1 1 is a system diagram illustrating an embodiment of a multi-tenant software architecture system that can be accessed by communicating with a user device. In the overview of system diagram 100, a user device 104 can communicate with a multi-tenant platform 102. The multi-tenant platform 102 can provide access to multiple service providers 108, 110, and 112. The multi-tenant platform 102 includes core services at elements 132-148 and additional services 130(1)-130(5). The multi-tenant platform 102 can provide services to the service providers 108-112, such as IaaS services that may be required to access other services. Thus, the multi-tenant platform 102 can manage multiple tenants, each of which can be associated with one or more services, which in turn are exposed for access.

[0019] The multi-tenant platform 102 can store user information for users at accounts 142. In some embodiments, accounts 142 include information for users of core tenants (also referred to as "core users"). The core tenant can be one of the service providers 108-112, or a service provider that is fully integrated into the multi-tenant platform 102. The multi-tenant platform 102 can facilitate the provision of various core services to core users. The core services can include identity services 132, risk services 138, compliance services 140, and payment services 148. In one embodiment, the multi-tenant platform 102 provides IaaS services at the identity service 132 element. The identity service 132 can generate and maintain a core hierarchical data structure for managing its core entities. The core services can also include access to policy configurations 136, as well as access to accounts 142, merchants 144, and consumers 146. Accounts 142 are associated with identity services 132.

[0020] Service provider 108 may include entity 114, policy 123, and service 116. Similarly, service providers 110 and 112 include entities 118 and 122, policies 125 and 127, and certain elements of services 120 and 124, respectively. In some embodiments, a service provider may be fully integrated into multi-tenant platform 102, which may include generating a core hierarchical data structure for core tenants. In this example, identity service 132 may manage core users, meaning that service provider 108 does not have its own identity service for its own users. Service providers 108, 110, and 112 may be loaded onto multi-tenant platform 102 and manage their own identities. Any access from service provider 110 to access services other than its own service 120 (such as access service 130(1)) uses a unified identity to access services and / or data across multi-tenant platform 102.

[0021] The multi-tenant platform can load service providers 108-112. As described below, the loading process can include accessing identity services to determine at least a portion of the entities managed by the corresponding identity services. If the entity is not migrated (e.g., by full integration) to the identity service 132, the identity service can generate a representation of the entity being loaded in the core hierarchical data structure. The IaaS service then uses these representations to determine and use a unified identity (for a certain user) across the multi-tenant platform 102. These representations can include lightweight elements and / or linked elements. The identity service 132 can manage and access policy configurations 136, such as to implement access to a certain consumer and / or merchant domain. The policy configuration 136 can be accessed via the hierarchical data structure of each entity (discussed below). The process of generating and using user representations will be described in more detail below.

[0022] The multi-tenant platform 102 can communicate with the service providers 108-112 and / or the user devices 104 via the multi-tenant API 126. The multi-tenant platform 102 can provide tenant-related information, associated services, and / or associated user experiences to the requesting entity based on a unified identity via the multi-tenant API 126. In addition, the multi-tenant platform 102 can facilitate communication between the various tenants 108-112, such as by providing IaaS services and using a unified identity.

[0023] For example, as referenced Figure 5 As discussed in more detail, a new tenant (such as service provider 112) may be onboarded by multi-tenant platform 102. Information about the new tenant may be stored by one or more of core services 132-148. In some embodiments, one or more services of the new tenant (such as service 124) may be exposed to other users of multi-tenant platform 102 for access. In one embodiment, multi-tenant platform 102 may also generate a representation 130(5) of service 124 at multi-tenant platform 102. Thus, any access to service 124 from other tenants (such as from user device 104 or from service provider 110) is performed at service representation 130(5) via a unified identity (e.g., by using IaaS).

[0024] The user device 104 may be any type of computing device that can transmit a user request to the multi-tenant platform 102. The user device 104 may be implemented as a self-service terminal, a point of sale (PoS) terminal, a mobile device, etc. The user device 104 includes a user interface (UI) 106 through which a user can interact with a displayed user experience, such as accessing certain services provided via the multi-tenant platform 102. The user device 104 can generate and transmit a user request for a certain service at the multi-tenant platform 102. The user device 104 can interface with a multi-tenant API 126, which can interface with various other components of the multi-tenant platform 102.

[0025] In some embodiments, one of the tenants (such as core service provider 108) can implement one or more payment system functions. In this embodiment, for the services provided via the user experience accessed at UI 106, the core service provider (integrated into the multi-tenant platform 102) can handle payment and order fulfillment. The core service provider can perform risk analysis (e.g., via risk core service 138) to determine whether to perform a certain service and / or process payment for the service. In some embodiments, the core service provider can perform risk and / or verification services for the new tenant 112 being loaded by the multi-tenant platform 102. The core service provider can process payments from user accounts associated with user devices 104. The core service provider can provide financial services to users, such as fund transfers (e.g., transfers of a certain amount). The core service provider can include payment accounts, each of which can be associated with a buyer or a seller. Once loaded as a core tenant, the core service provider's account can be stored and accessed directly at the account 142 element on the multi-tenant platform. For example, a buyer (e.g., a user of a user device 104) can be associated with a payment account, and a seller (e.g., one of the tenants) can be associated with another payment account at the payment system. After successfully performing a risk analysis on the requested service (eg, a requested transaction at the tenant), the core service provider may perform (eg, via payment core service 148) a funds transfer from the buyer's payment account to the seller's payment account.

[0026] The payment system may be implemented via PAYPAL or other online payment systems that allow users to send, receive and request fund transfers. In some embodiments, the user experience may also provide access to certain services. Thus, in addition to or in lieu of payment services, the user experience may include other features unique to a particular tenant, such as selecting order items, accessing certain SaaS features, and the like. Thus, the solution provider may provide a funds inflow / funds outflow service determined based on location data from the payment system to the user of the user device.

[0027] To keep it simple, Figure 1 Only a single user device 104 is shown. However, as discussed herein, the multi-tenant platform 102 interfaces with multiple user devices, thereby providing access to services to many different users. Similarly, the multi-tenant platform 102 can also load multiple tenants in addition to those shown. The multi-tenant platform 102 can also have multiple core tenants that are incorporated as part of the core services 132-148.

[0028] Figure 2 It shows the unified identity service Figure 1 A system diagram of an embodiment of a multi-tenant software architecture. Figure 2 An embodiment of how identity services may be implemented by each service provider 108-112 and the multi-tenant platform 102 is shown. As shown, the service provider 108 may include a third-party identity provider (3P-IDP) 204 that manages entities for merchants 206(1) and 206(2) and entities for consumers 208(1) and 208(2). Similarly, the service provider 110 may include a 3P-IDP 204 that manages entities for consumers 214(1) and 214(2). The service provider 112 may include a 3P-IDP 222 that manages entities for merchants 224(1) and 224(2). The multi-tenant platform 102 includes identity services 132, account 142 elements, risk 138 elements, and services 130(1) and 130(2). In some embodiments, the 3P-IDPs 204, 212, and 222 are representations (in a hierarchical data structure 244) of actual IDPs provided by the service providers 108, 110, and 112.

[0029] exist Figure 2 In the illustrated embodiment, the service provider 108 may be onboarded by the multi-tenant platform 102, rather than fully integrated. By making the service provider core to the multi-tenant platform 102, the service provider may be fully integrated with the multi-tenant platform 102. Therefore, a link 211 is shown indicating an onboarded, rather than fully integrated, state of the service provider 108. The identity service 132 includes an access layer 242 and a hierarchical data structure 244 managed by the MT-IDP 246. The multi-tenant platform 102 also includes services 138, 142, and 130(1)-130(2).

[0030] The access layer 242 is part of the identity service 132 and customizes data associated with a service provider when the service provider is onboarded using the multi-tenant platform 102. For example, the access layer 242 includes information about products and / or services provided by the service provider 108, and service endpoints for accessing services provided by the service provider 108. The service endpoints can be referenced by corresponding nodes for the service provider 108 in the hierarchical data structure 244. Figure 3 and Figure 4 Various embodiments of how to generate and access the hierarchical data structure 244 are discussed. The MT-IDP 246 can generate and manage representations of the entities 206(1), 206(2), 208(1), and 208(2) of the onboarding tenant 108. Similarly, the MT-IDP 246 can generate and manage representations of the entities of the tenants of the service providers 110 and 112.

[0031] As discussed, since each tenant 108-112 includes its own 3P-IDP 204, 212, and 222, respectively, each of these tenants continues to manage the identity of its respective entity. For example, the service provider 110 continues to manage the entities 214(1)-214(2), including managing the identity information, contact data, and any characteristics of the consumers 214(1) and 214(2). The service provider 110 can update any changes to the entities 214(1) and 214(2) to the multi-tenant platform 102. These updates originating from the 3P-IDP 212 are used to keep the data represented by each of them up to date. Similarly, any services (such as core services) performed via the representation of the hierarchical data structure 244 are also propagated back to the 3P-IDP 212.

[0032] Figure 3 is a diagram showing a hierarchical data structure used by a multi-tenant software architecture system providing a unified identity service. Figure 3 FIG. 2 shows a hierarchical data structure managed by MT-IDP 246. Figure 3 In , there is no additional IDP, and entities 301, 302, 304, 306, 310, 312, 316, 318, 324, 326, and 328 are fully integrated into the multi-tenant platform 102. Figure 3 , the first layer of the hierarchy includes service provider 301, which may correspond to a fully integrated core service provider (eg, PAYPAL). Figure 3 The organization and linkage of hierarchical data structures can be called a dependency graph. Figure 3 (or Figure 4 ), but each merchant can include multiple users (e.g., consumers) as child nodes. Figure 3And / or other nodes in 4 may similarly have additional child nodes. Figure 3 and Figure 4 As shown, the multi-tenant platform 102 can use a hierarchical data structure 244 to model various organizations, including small merchants, large merchants, BYO merchants, BYO consumers, marketplaces, and the like.

[0033] The next level of the hierarchy includes service providers 304 and 306. Service providers 304 and 306 may be loaded rather than fully integrated. Service providers 304 and 306 may inherit policies and configurations from service provider 301. The hierarchical data structure shows that merchants 316 and 318 are child nodes of the service provider 306 node and are therefore acted upon by service provider 306. Service provider 306 (inherited from service provider 301 and modified by the access permissions associated with service provider 306) defines the permissions of the merchant, including how merchants 316 and 318 may communicate with other entities of the hierarchical data structure (including the consumers of merchant 316).

[0034] The hierarchical data structure shows that consumers 310 and 312 are children of merchant 302 and are therefore acted upon by merchant 302. Merchant 302 (inherited from service provider 301 and modified by access permissions associated with merchant 302) defines the permissions of consumers, including how consumers 310 and 312 can communicate with other entities in hierarchical data structure 244. For example, merchant 302 can define that consumer 310 can view its own profile and access certain core services (such as services 130(1) and 130(2)). Service provider 306 can be associated with small merchants, so merchants 316 and 318 can both represent small merchants.

[0035] Service provider 306 includes merchant 316 and 318 child nodes. The hierarchical data structure shows that merchants 316 and 318 are linked to service provider 304 (but not its child nodes). Therefore, merchants 316 and 318 can be acted upon by service provider 306, but can also be accessed by service provider 304 (such as having read privileges but not having write privileges). Such an example is that merchants 316 and 318 are two merchants that operate as part of service provider 306 (which can implement a certain branch of PAYPAL). In this example, service provider 304 can be a market tenant (such as EBAY), which includes one entity (merchant 302) and links to two merchants 316 and 318. Service provider 306 (inherited from service provider 301 and modified by the access rights associated with service provider 306) defines the permissions of the merchant, including how merchants 316 and 318 can communicate with other entities of the hierarchical data structure (including consumers of merchant 316). Note that since the same MT-IDP 246 manages all of the nodes 316, 318, and 306, these links are used to link with the nodes 316 and 318, rather than using representations (as described below). Figure 3 Also shown are administrative entities 330 and 332 that can respectively access merchant 302 and service provider 306. Administrators 330 and 332 may have various access rights (such as the ability to read configuration data).

[0036] Figure 4 is another diagram illustrating a hierarchical data structure used by a multi-tenant software architecture system providing a unified identity service. Figure 4 Several hierarchical data structures 402-406 are shown. A first hierarchical data structure 402 is managed by MT-IDP 246. A second hierarchical data structure 404 is managed by 3P-IDP 212, and a third hierarchical data structure 406 is managed by 3P-IDP 232. Figure 4 Relationships between entities of the hierarchical data structure 402-406 are shown. Figure 4 The organization and linkage of the hierarchical data structure may be referred to as a dependency graph. Note that the organization and type of hierarchical data structures 404 and / or 406 are shown for illustrative purposes only, and one or more of the 3P-IDPs 212 and 222 may implement different data structures as desired. In this case, the Identity as a Service (IaaS) service may further map the different modes used by the 3P-IDPs 212 and / or 222 to the hierarchical data structure 402. It should also be noted that the hierarchical data structure managed by the MT-IDP 246 is also shown for illustrative purposes only, and other implementations may be envisioned. In some embodiments, the 3P-IDPs 212 and 222 are representations (in the hierarchical data structure 244) of the actual IDPs provided by the service providers 110 and 112.

[0037] exist Figure 4 2, entities 412(1), 412(2), 414(1), 414(2), 416, 420(1), and 420(2) are fully integrated into multi-tenant platform 102 and are managed by MT-IDP 246. Entities 214(1) and 214(2) are not fully integrated into multi-tenant platform 102, but are onboarded to multi-tenant platform 102. Entities 214(1) and 214(2) are managed by 3P-IDP 212. Similarly, entities 224(1) and 224(2) are onboarded, but not fully integrated into multi-tenant platform 102. Entities 224(1) and 224(2) are managed by 3P-IDP 222.

[0038] During the process of onboarding a service provider 110, the multi-tenant platform 102 may generate representations for consumers 214(1) and 214(2) managed by the tenant's 3P-IDP 212. The multi-tenant platform 102 may generate these representations by generating linked consumers 414(1) and 414(2). A linked consumer is an entity that represents a corresponding entity in another hierarchical data structure and contains a limited amount of data for the corresponding entity. Linked consumers 414(1) and 414(2) are linked to consumers 214(1) and 214(2), respectively.

[0039] Similarly, during the process of onboarding a service provider 112, the multi-tenant platform 102 may generate representations of merchants 224(1) and 224(2) managed by the tenant's 3P-IDP 222. The multi-tenant platform 102 may generate these representations by generating lightweight merchants 420(1) and 420(2). A lightweight merchant is an entity that represents a corresponding entity in another hierarchical data structure and contains some data for the corresponding entity. Lightweight merchants 420(1) and 420(2) are linked to merchants 224(1) and 224(2), respectively. Types of representations may include linked entities and lightweight entities. In some embodiments, a linked entity (e.g., a linked consumer or a linked merchant) differs from a lightweight entity (e.g., a lightweight merchant or a lightweight consumer) in that a lightweight entity includes an additional amount of information for its corresponding entity, which type may be selected during onboarding.

[0040] Hierarchical data structure 402 indicates that linked consumers 414(1) and 414(2) are children of the service provider 412(1) node and are therefore acted upon by the service provider 412(1). However, the service provider 412(1) does not directly modify the links to consumers 214(1) and 214(2). Similarly, hierarchical data structure 402 indicates that lightweight merchants 420(1) and 420(2) are children of the service provider 412(2) node and are therefore acted upon by the service provider 412(2). However, the service provider 412(2) does not directly modify the links to merchants 224(1) and 224(2).

[0041] An example of this is merchants 224(1) and 224(2) operating as merchants of service provider 3P-IDP 222 (note that for simplicity, Figure 4 3P-IDP 222 and its service provider are shown as one box, and similarly for 3P-IDP 212), service provider 3P-IDP 222 can be a marketplace tenant. Although lightweight merchants 420(1) and 420(2) inherit access rights from service provider 412(2), 3P-IDP 222 provides access rights to merchants 224(1) and 224(2). In the event of conflicting access rights, the access rights of merchants 224(1) and 224(2) prevail.

[0042] Figure 5 is a flow chart illustrating an embodiment of operations for onboarding and accessing tenants in a multi-tenant software architecture system using a unified identity service. Figure 5 The operations are exemplary and are intended to illustrate how a user of user device 104 can access services available at multi-tenant platform 102. Identity 132 elements and service 130(1) are part of multi-tenant platform 102, and the user is accessing third-party service provider 112.

[0043] At step 1, a user of a user device 104 may establish an identity with a service provider 112. For example, the user may establish an identity with a 3P-IDP 222 by providing information via the UI 106, and the 3P-IDP 222 then manages the identity for any transactions performed with any merchants (e.g., merchants 224(1) and / or 224(2)) also managed by the 3P-IDP 222. The user's interactions with the service provider 112 may be performed without the service provider 112 being onboarded using the multi-tenant platform 102. The 3P-IDP 222 may have its own hierarchical data structure (or a similar structure for managing its entities) that indicates its merchants and / or other entities.

[0044] At step 2, service provider 112 is onboarded using multi-tenant platform 102. Identity service 132 of multi-tenant platform 102 may configure (such as at access layer 242) services and capabilities (such as service 130(1)) that are available for access by service provider 112 at multi-tenant platform 102. Identity service 132 may also integrate service provider 112 into its tenant hierarchy, such as by adding a representation of the service provider, representations of any consumers and / or merchants of service provider 112, and representations of users including that user.

[0045] Step 3 shows a communication initiated from service provider 112 to multi-tenant platform 102 in response to a user request. The user request may be, for example, a call from a user to a service that is only available at multi-tenant platform 102. The call may be made to a merchant that is part of 3P-IDP 222, where service 130(1) is exposed to the user as if provided by service provider 112 (i.e., the user may not be aware of the relationship between service provider 112 and multi-tenant platform 102). Although Figure 3 Service 130(1) is shown as a core service at multi-tenant platform 102, but the service may be a service provided by another onboard service provider. At step 3, service provider 112 may route the call to identity service 132, including the user's credentials, the service provider's 112 credentials, and / or the credentials of the merchant to whom the user may make the call. In some embodiments, multi-tenant platform 102 may also return an access token (or another credential) to service provider 112. The access token may indicate a representation of the user and / or merchant in a hierarchical data structure of multi-tenant platform 102.

[0046] At step 4, service provider 112 may use the access token to access service 130(1). At step 4, multi-tenant platform 102 may determine that service 130(1) requires additional user information to perform the service because the representation in the hierarchical data structure does not include certain required information. At step 5, service 130(1) may access the hierarchical data structure (at identity service 132) to obtain the additional user information. At step 6A, identity service 132 may communicate with 3P-IDP 222 to obtain the additional user information. At step 6B, identity service 132 returns the additional user information and any additional information from the hierarchical data structure to service 130(1). At step 7, service 130(1) completes the call and returns the results to service provider 112. Note that as a result of the service being completed, the hierarchical data structure at multi-tenant platform 102 and a separate hierarchical data structure managed by 3P-IDP 222 may be updated.

[0047] Figure 6is a flow chart illustrating an embodiment of the operation of a system for using a multi-tenant software architecture that provides a unified identity service. Figure 1-5 The systems and components described in Figure 6 The example operations may be performed by the multi-tenant platform 102.

[0048] Beginning at 602, the multi-tenant platform 102 receives a request at a first provider to provide a service to a user. The multi-tenant platform 102 may receive the user request from a user device 104. The user request may be made via a UI 106 of the user device 104. For example, the user request may be made at the multi-tenant platform 102 (which may act as a service provider).

[0049] At 604, the multi-tenant platform 102 accesses a representation of a second service provider in a first hierarchical data structure managed by the first service provider. In some embodiments, the second service provider is configured to provide a second set of services directly to users. The second set of services can be accessed from the first service provider using the first representation. For example, a representation (such as a lightweight merchant or a linked consumer) can be accessed at the hierarchical data structure 244. In some embodiments, the hierarchical data structure 244 can be implemented as a dependency graph.

[0050] At 606, multi-tenant platform 102 determines whether the service is available at the first service provider. If the service is available at the first service provider, flow continues to 610. Otherwise, flow continues to 608. At 608, multi-tenant platform 102 determines which service provider provides the requested service. For example, it is determined whether the requested service is one of the core services 130(1) available at multi-tenant platform 102 (acting as the first service provider) or a service provided by another service provider (also referred to as the "requested service provider").

[0051] At 610, the multi-tenant platform 102 determines whether the user data is accessible through another data structure managed by another service provider. If the user data is available at the other service provider, flow continues to 612. Otherwise, flow continues to 616. For example, the multi-tenant platform 102 can determine that additional user information (information for the user and / or the second service provider) required to access the service is not available at the first hierarchical data structure. For example, the multi-tenant platform 102 can determine certain user data based on the representation in the first data structure, and also determine that additional user information is required to perform the service.

[0052] At 612, the multi-tenant platform 102 determines that the representation is linked to a complete identity reference in another hierarchical data structure managed by another service provider. Figure 4, the representation of 414 ( 1 ) may be linked to the full identity reference 214 ( 1 ) from the 3P-IDP 212 managed by the service provider 110 .

[0053] At 614, the multi-tenant platform 102 uses the full identity reference to access the user data at another data structure. For example, the multi-tenant platform 102 can access additional user data from the 3P-IDP 212 via the full identity reference 214(1). At 616, the multi-tenant platform 102 uses the representation to access the user data at the first level data structure. For example, since no additional data is required to access the service, the multi-tenant platform 102 can access the user data from the MT-IDP 246 via the linked consumer 414(1). At 618, the multi-tenant platform 102 accesses the service via the representation and using the user data (which may include the additional data if 614 is performed). The multi-tenant platform 102 can access the service at the requested service provider (as determined at 608).

[0054] It should be understood that Figure 1-6 The operations described herein are examples intended to aid in understanding the embodiments and should not be used to limit the embodiments or to limit the scope of the claims. Embodiments may perform additional operations, fewer operations, operations in a different order, operations in parallel, and some different operations. For example, referring to Figure 4 and Figure 5 One or more elements, steps, or processes described in the flowcharts may be omitted, described in a different order, or combined as needed or appropriate.

[0055] As will be appreciated by those skilled in the art, aspects of the present disclosure may be implemented as systems, methods, or computer program products. Therefore, aspects of the present disclosure may take the form of a complete hardware embodiment, a software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects (which are generally all referred to herein as "modules" or "systems"). In addition, aspects of the present disclosure may take the form of a computer program product implemented in one or more computer-readable media having computer-readable program code implemented thereon.

[0056] Any combination of one or more computer-readable media can be utilized. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared or semiconductor system, device or equipment, or any suitable combination of the foregoing. A more specific example (non-exhaustive list) of a computer-readable storage medium will include the following items: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this article, a computer-readable storage medium can be any tangible and / or non-transient medium that can contain or store a program used by or in conjunction with an instruction execution system, device or device.

[0057] Computer readable signal media may include, for example, a propagated data signal having computer readable program code implemented therein, in baseband or as part of a carrier wave. This propagated signal may take any of a variety of forms, including but not limited to electromagnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can transmit, propagate, or transport a program for use by or in conjunction with an instruction execution system, device, or apparatus.

[0058] Computer program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0059] Computer program code for performing the operations of various aspects of the present disclosure may be written in any combination of one or more programming languages, including object-oriented programming languages ​​(such as Java, Smalltalk, C++, etc.) and traditional procedural programming languages ​​(such as "C" programming language or similar programming languages). The computer program code may be executed (e.g., compiled into computer program instructions) entirely on a user's computer, partially on a user's computer as a stand-alone software package, partially on a user's computer and partially on a remote computer or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or a connection may be established with an external computer (e.g., via the Internet using an Internet service provider).

[0060] Various aspects of the present disclosure are described with reference to flowchart illustrations and / or block diagrams of methods, devices (systems) and computer program products according to embodiments of the present disclosure. It will be understood that each frame of the flowchart illustration and / or block diagram and the combination of frames in the flowchart illustration and / or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer or other programmable data processing device to produce a machine, so that the computer program instructions executed by the processor of the computer or other programmable data processing device create functions / actions specified in the frames of the flowchart and / or block diagram.

[0061] These computer program instructions may also be stored in a computer-readable medium, which may instruct a computer, other programmable data processing apparatus, or other device to operate in a specific manner so that the instructions stored in the computer-readable medium produce the following product: the product includes instructions for implementing the functions / actions specified in the boxes of the flowchart and / or block diagram.

[0062] Computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other devices to produce a computer-implemented process, such that the instructions executed on the computer or other programmable apparatus provide a process for implementing the functions / actions specified in the boxes of the flowchart and / or block diagram.

[0063] Figure 7 It shows that Figure 1-6 Block diagram of an embodiment of an electronic device 700 used in a communication system. In some embodiments, the electronic device 700 may be a laptop computer, a tablet computer, a mobile phone, a self-service terminal, a power line communication device, a smart device (PDA), a server and / or one or more other electronic systems. For example, a mobile device such as a mobile phone or a tablet computer can be used to implement a user device. For example, one or more servers can be used to implement a payment system. The electronic device 700 may include a processor unit 702 (which may include multiple processors, multiple cores, multiple nodes and / or implement multi-threading, etc.). The electronic device 700 may also include a memory unit 706. The memory unit 706 may be a system memory (e.g., one or more of a cache, SRAM, DRAM, zero capacitor RAM, dual transistor RAM, eDRAM, EDORAM, DDR RAM, EEPROM, NRAM, REAM, SONOS, PRAM, etc.) or any one or more of the implementations of the machine-readable medium described above. The electronic device 700 may also include a bus 710 (e.g., PCI, ISA, PCI-Express, The electronic device 700 may include a communication interface 708 for network communication. The communication interface 708 may include at least one wireless network interface (e.g., a WLAN interface, a Bluetooth interface, a WiMAX interface, a ZigBee interface, a wireless USB interface, etc.). In some embodiments, the electronic device 700 may support multiple network interfaces, each of which is configured to couple the electronic device 700 to a different communication network.

[0064] The memory unit 706 can implement functions to achieve the above Figure 1-6 In one embodiment, the memory unit 706 may include one or more functions for using a unified identity service in a multi-tenant architecture system. Any of these functions may be partially (or fully) implemented in hardware and / or implemented on the processor unit 702. For example, some functions may be implemented with a dedicated integrated circuit, with logic implemented in the processor unit 702, with a coprocessor on a peripheral device or card, etc. In addition, the implementation may include Figure 7 704, and communication interface 708 are coupled to bus 710. Although shown as being coupled to bus 710, memory unit 706 may be coupled to processor unit 702.

[0065] Although embodiments are described with reference to various implementations and developments, it will be understood that these embodiments are illustrative and the scope of the present disclosure is not limited to them. In general, the techniques described herein for using a unified identity service in a multi-tenant architecture system can be implemented with facilities consistent with any one or more hardware systems. Many variations, modifications, additions, and improvements are possible.

[0066] Multiple instances may be provided for components, operations, or structures described herein as single instances. Finally, the boundaries between individual components, operations, and data storage devices are arbitrary, and specific operations are described in the context of a particular illustrative configuration. Other allocations of functions may be envisioned, and these allocations may fall within the scope of the present disclosure. Typically, structures and functions represented as separate components in an exemplary configuration may be implemented as combined structures or components. Similarly, structures and functions presented as single components may be implemented as separate components. These and other variations, modifications, additions, and improvements may fall within the scope of the present disclosure.

Claims

1. A method for using a unified identity service in a multi-tenant architecture system, the method comprising: receiving, at a first service provider, a request to provide a first service to a user; accessing a first representation of a second service provider in a first hierarchical data structure, the first hierarchical data structure being managed by the first service provider, the second service provider managing a user identity of the user, the first service provider being configured to provide a first set of services, the first set of services including the first service for the user, wherein the first service provider and the second service provider are tenants of the multi-tenant architecture system; Determining that user data required to complete the first service is managed by the second service provider; determining that the first representation at the first hierarchical data structure is linked with a full identity reference for the second service provider at a second hierarchical data structure, the second hierarchical data structure being managed by the second service provider; accessing user data of the user via the second hierarchical data structure using the full identity reference; as well as The first service for the user is accessed at the first service provider via the first representation and using the user data.

2. The method according to claim 1, wherein: The second service provider is configured to provide a second set of services directly to the user; and The second set of services is accessible from the first service provider using the first representation.

3. The method according to claim 1, wherein: Relationship data associated with the first representation is used to determine a link between one or more first entities at the first hierarchical data structure and one or more second entities at the second hierarchical data structure.

4. The method according to claim 1, wherein: The access rights associated with the second service provider are used to determine at the first service provider how to access the user data.

5. The method according to claim 1, further comprising: A dependency graph is determined, the dependency graph indicating relationships and access permissions between entities of the first hierarchical data structure and further entities of the second hierarchical data structure, wherein the determination that the first representation is linked with the complete identity reference is based on the dependency graph.

6. The method according to claim 1, further comprising: The second service provider is loaded into the hierarchical data structure of the first service provider to expose services provided by the second service provider to the link identity reference from the first service provider.

7. The method according to claim 1, further comprising: Based on one or more changes to the second hierarchical data structure resulting from performing services at the second service provider, it is determined to update the first hierarchical data structure.

8. The method according to claim 1, further comprising: A communication for updating the second hierarchical data structure is generated based on one or more changes to the first hierarchical data structure, the one or more changes to the first hierarchical data structure being based on the first service.

9. The method according to claim 1, further comprising: receiving another request from another user to access a second service at the second service provider via a third service provider; accessing another representation of the third service provider in the first hierarchical data structure, a second service provider entity configured to provide a second set of services including the second service to the another user; determining that the further representation is linked with another complete identity reference to a third service provider entity in the second hierarchical data structure, the second hierarchical data structure being managed by the second service provider; as well as The second service for the other user is accessed at the second service provider via the other representation.

10. A system for using a unified identity service in a multi-tenant architecture system, comprising: a non-transitory memory storing instructions; as well as a processor configured to execute the instructions so that the system: receiving, at a first service provider, a request to provide a first service to a user, wherein the first service provider is a first tenant of a multi-tenant system; accessing a first lightweight identity reference of the user in a first hierarchical data structure, the first hierarchical data structure being managed by the first service provider; determining that user data required to complete the first service is managed by a representation of the first lightweight identity reference at a second service provider, wherein the second service provider is a second tenant of the multi-tenant system; determining that the first lightweight identity reference is linked with a full identity reference for the user in a second hierarchical data structure, the second hierarchical data structure being managed by the second service provider, accessing the user data at the second hierarchical data structure using the full identity reference; as well as The first service for the user is accessed at the first service provider via the first lightweight identity reference and using the user data.

11. The system according to claim 10, wherein: The second service provider is an original provider of the user identity, the second service provider comprising a second set of services; and One or more services in the second set of services are accessible from the first service provider using the first lightweight identity reference.

12. The system according to claim 10, wherein: Execution of the instructions further causes the system to: Determining a dependency graph indicating relationships and access permissions between entities of the first hierarchical data structure and further entities of the second hierarchical data structure, wherein the dependency graph indicates the entities, wherein the determination that a first lightweight identity reference is linked with the full identity reference is based on the dependency graph.

13. The system according to claim 10, wherein: Execution of the instructions further causes the system to: The second service provider is loaded into the hierarchical data structure of the first service provider to expose services provided by the second service provider to the link identity reference from the first service provider.

14. The system according to claim 10, wherein: Execution of the instructions further causes the system to: Based on one or more changes to the second hierarchical data structure resulting from performing services at the second service provider, it is determined to update the first hierarchical data structure.

15. A non-transitory machine-readable medium having instructions stored thereon, the instructions being executable to cause operations to be performed, the operations comprising: receiving, at a first service provider, a request to provide a first service to a user, wherein the first service provider is a first tenant of a multi-tenant system; determining that the first service is provided by a second service provider; accessing a complete identity reference of the user in a first hierarchical data structure, the first hierarchical data structure being managed by the first service provider; determining that the full identity reference is linked with a first lightweight identity reference for the user in a second hierarchical data structure, the second hierarchical data structure being managed by a second service provider, wherein the second service provider is a second tenant of the multi-tenant system; as well as The first service for the user is accessed at the second service provider via the first lightweight identity reference.

16. The non-transitory machine-readable medium of claim 15, wherein: The second service provider is an original provider of the user identity, the second service provider comprising a second set of services; and One or more services in the second set of services are accessible from the first service provider using the first lightweight identity reference.

17. The non-transitory machine-readable medium of claim 15, wherein: The operations also include: Determining a dependency graph indicating relationships and access permissions between entities of the first hierarchical data structure and further entities of the second hierarchical data structure, wherein the dependency graph indicates the entities, wherein the determination that the first lightweight identity reference is linked with the full identity reference is based on the dependency graph.

18. The non-transitory machine-readable medium of claim 15, wherein: The operations also include: The second service provider is loaded into the hierarchical data structure of the first service provider to expose services provided by the second service provider to the link identity reference from the first service provider.

19. The non-transitory machine-readable medium of claim 15, wherein: The operations also include: Based on one or more changes to the second hierarchical data structure resulting from performing services at the second service provider, it is determined to update the first hierarchical data structure.

20. The non-transitory machine-readable medium of claim 15, wherein: relationship data associated with the first lightweight identity reference is used to determine a link between one or more entities at the first hierarchical data structure and one or more entities at the second hierarchical data structure; and The access rights associated with the second service provider are used to determine how to access user data at the first service provider.

Images