Multi-tenant system, access control method, and program

Abstract

To provide a multi-tenant system that manages data of each of a plurality of tenants by a regional system in any of a plurality of regions, and performs appropriate access control when a subdomain is assigned to each of the plurality of tenants.SOLUTION: In the multi-tenant system, data of each of a plurality of tenants is managed by a regional system 30 in any of a plurality of regions, and a subdomain is assigned to each of the plurality of tenants. The reception unit 201 receives, from the computer 50, a request including a subdomain assigned to any of a plurality of tenants. When a request is received, the identification unit 202 identifies an access destination regional system that is the regional system 30 and manages data of a tenant to which a subdomain included in the request is assigned. The access control unit 203 causes the computer 50 to access the access destination regional system.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present disclosure relates to a multi-tenant system, an access control method, and a program. [Background technology]

[0002] Conventionally, a multi-tenant system has been known in which multiple tenants each share common resources (for example, a server, storage, or application). For example, Non-Patent Document 1 describes a multi-tenant system that routes a request to an appropriate backend service among multiple backend services based on a URL map that associates each of multiple URLs with a destination to which the request containing the URL is to be distributed.

[0003] For example, Patent Document 1 describes a multi-tenant system including an authentication server located in each of a plurality of regions, an integrated entrance server that provides a login page, and a client on which a browser is installed. In response to receiving user information entered by the user via the login page on the browser, the multi-tenant system of Patent Document 1 identifies the region to which the user belongs and causes the client to access the authentication server related to the identified region.

[0004] For example, Patent Document 2 describes a multi-tenant system that receives requests from users in a tenant-specific application, which is an application prepared for each tenant, and manages subdomains as tenant identification information. When a user inquires about a tenant's server name using an FQDN (Fully Qualified Domain Name), the multi-tenant system of Patent Document 2 calls the tenant-specific application of the tenant identified by the subdomain in the FQDN. [Prior art documents] [Non-patent literature]

[0005] [Non-Patent Document 1] "External Application Load Balancer Overview", Internet, retrieved July 31, 2023, online, https: / / cloud.google.com / load-balancing / docs / https?hl=ja#url-maps [Patent documents]

[0006] [Patent Document 1] Japanese Patent Application Publication No. 2019-101668 [Patent Document 2] Japanese Patent Application Publication No. 2022-168948 Summary of the Invention [Problem to be solved by the invention]

[0007] For example, in a multi-tenant system, data for each of multiple tenants may be managed in one of multiple regional systems. Furthermore, in a multi-tenant system, a subdomain may be assigned to each of the multiple tenants. When a request is received from a computer in such a multi-tenant system, the computer must access the appropriate regional system.

[0008] However, the URL map in Non-Patent Document 1 was not created with a focus on the subdomains assigned to individual tenants. The allocation destinations defined in the URL map are not region-specific. For this reason, the technology in Non-Patent Document 1 cannot properly perform access control in a multi-tenant system such as the one described above. The technology in Patent Document 1 merely places an authentication server in each region. The technology in Patent Document 2 does not achieve region-specific data management. For this reason, the technologies in Patent Documents 1 and 2, like the technology in Non-Patent Document 1, cannot properly perform access control in a multi-tenant system such as the one described above.

[0009] One of the objectives of the present disclosure is to perform appropriate access control when data for each of multiple tenants is managed in a regional system in one of multiple regions and a subdomain is assigned to each of the multiple tenants. [Means for solving the problem]

[0010] The multi-tenant system of the present disclosure is a multi-tenant system in which data for each of multiple tenants is managed in one of multiple regional systems, and a subdomain is assigned to each of the multiple tenants, and includes: a reception unit that receives a request from a computer including the subdomain assigned to one of the multiple tenants; an identification unit that, when the request is accepted, identifies an access destination regional system that is the regional system and manages the data of the tenant to which the subdomain included in the request is assigned; and an access control unit that causes the computer to access the access destination regional system. [Effects of the Invention]

[0011] The present disclosure enables appropriate access control when data for each of multiple tenants is managed in a regional system in one of multiple regions and a subdomain is assigned to each of the multiple tenants. [Brief explanation of the drawings]

[0012] [Figure 1] FIG. 1 illustrates an example of a hardware configuration of a multi-tenant system. [Figure 2] FIG. 10 is a diagram illustrating an example of a page of a URL including a subdomain assigned to a tenant. [Figure 3] FIG. 1 illustrates an example of access control performed in a multi-tenant system. [Figure 4] FIG. 1 is a diagram illustrating an example of functions realized in a multi-tenant system. [Figure 5]FIG. 10 is a diagram illustrating an example of a domain map. [Figure 6] FIG. 10 is a diagram illustrating an example of an address database. [Figure 7] FIG. 10 illustrates an example of processing executed in a multi-tenant system. [Figure 8] FIG. 10 is a diagram illustrating an example of a hardware configuration in a modified example. [Figure 9] FIG. 10 is a diagram illustrating an example of a function realized in a modified example. [Figure 10] FIG. 20 is a diagram illustrating an example of access control in Modification 6. DETAILED DESCRIPTION OF THE INVENTION

[0013] [1. Hardware configuration of multi-tenant system] An example of an embodiment of a multi-tenant system, an access control method, and a program according to the present disclosure will be described. A multi-tenant system is a system that provides services to multiple tenants based on common resources. A tenant is a subscriber of a service. For example, a tenant may be a company, a government agency, another organization, or an individual. A resource is a tangible or intangible entity used to provide a service. For example, a resource may be a computer, a communication device, a memory, other hardware, software, or a database.

[0014] In this embodiment, cloud-based groupware will be described as an example of a service provided by a multi-tenant system. The groupware supports the business operations of tenants. For example, the groupware provides tenants with various functions such as schedule management functions, communication functions such as threads, or data management functions using a database. When a tenant is an organization, the groupware supports the business operations of each of multiple users (e.g., employees of a company) who belong to the tenant organization. When a tenant is an individual, the individual who is the tenant corresponds to a user of the groupware.

[0015] The services provided by the multi-tenant system may be any multi-tenant type services. The services provided by the multi-tenant system are not limited to groupware. For example, the multi-tenant system may be a data management service that manages data on the cloud, a shared email service that manages shared emails, a communication tool service such as chat, a social networking service, or other services. In this embodiment, the term "groupware" may be replaced with any other service.

[0016] 1 is a diagram illustrating an example of the hardware configuration of a multi-tenant system. For example, the multi-tenant system 1 includes a management server 10, a Japanese load balancer 20A, a US load balancer 20B, a European load balancer 20C, a Japanese regional system 30A, a US regional system 30B, a European regional system 30C, a domain name system 40, and a user terminal 50. These are connected to a network N such as the Internet or a LAN.

[0017] Hereinafter, the Japanese load balancer 20A, the American load balancer 20B, and the European load balancer 20C may be referred to simply as the load balancer 20, with the letters at the end of the reference numerals omitted. For the same reason, the letters at the end of the reference numerals of the control units 21A, 21B, and 21C, the memory units 22A, 22B, and 22C, and the communication units 23A, 23B, and 23C may be referred to as the control unit 21, the memory unit 22, and the communication unit 23, respectively.

[0018] Furthermore, the Japanese regional system 30A, the American regional system 30B, and the European regional system 30C may be referred to simply as the regional system 30, with the letters at the end of the reference numerals omitted. For the same reason, the letters at the end of the reference numerals of the control units 31A, 31B, and 31C, the memory units 32A, 32B, and 32C, and the communication units 33A, 33B, and 33C may be referred to as the control unit 31, the memory unit 32, and the communication unit 33, respectively. Note that FIG. 1 is an example of the hardware configuration of the multi-tenant system 1, and in this embodiment, the user terminal 50 does not directly access the regional system 30 through the network N.

[0019] The management server 10 is a server computer that comprehensively manages groupware. For example, the management server 10 includes a control unit 11, a storage unit 12, and a communication unit 13. The control unit 11 includes at least one processor. The storage unit 12 includes at least one of a volatile memory such as RAM and a non-volatile memory such as flash memory. The communication unit 13 includes at least one of a communication interface for wired communication and a communication interface for wireless communication.

[0020] The program stored in the storage unit 12 may be supplied to the management server 10 via the network N. The management server 10 may include at least one of a reading unit (e.g., a memory card slot) that reads an information storage medium and an input / output unit (e.g., a USB terminal) that connects to the information storage medium. In this case, the program stored in the information storage medium may be supplied to the management server 10 via at least one of the reading unit and the input / output unit.

[0021] The load balancer 20 is a device that executes access control (routing) in groupware. The load balancer 20 may be deployed for the purpose of achieving load balancing, but in this embodiment, it is deployed for the purpose of achieving appropriate access control rather than load balancing. In this embodiment, the load balancer 20 does not execute any processing specifically for load balancing, but the load balancer 20 may execute processing for load balancing.

[0022] For example, the load balancer 20 includes a server computer, a personal computer, a data storage device, a communication device, or a combination thereof. The load balancer 20 may have a known hardware configuration. For example, the load balancer 20 includes a control unit 21, a storage unit 22, and a communication unit 23. The hardware configurations of the control unit 21, the storage unit 22, and the communication unit 23 may be similar to those of the control unit 11, the storage unit 12, and the communication unit 13, respectively.

[0023] The multiple load balancers 20 are each located in a different region. In this embodiment, an example is given in which Japan, the United States, and Europe each correspond to a region. A region may be an area of ​​a certain size, such as a continent, country, state, prefecture, or city, ward, town, or village. The region is not limited to the example in this embodiment. In this embodiment, the phrases Japan, the United States, or Europe may be replaced with any other region.

[0024] In this embodiment, an example is given in which one load balancer 20 is placed in one region, but multiple load balancers 20 may be placed in one region. Furthermore, the number of regions in which the load balancers 20 are placed is not limited to three as in this embodiment. The number of regions in which the load balancers 20 are placed may be two, or may be four or more. As with the management server 10, the program stored in the load balancer 20 may be supplied to the load balancer 20 via the network N, a reading unit, or an input / output unit.

[0025] The regional system 30 is a system that manages tenant data. The regional system 30 manages data so as to comply with the laws, ordinances, requests from government agencies, and other regulations of the region in which the regional system 30 is located. For example, the regional system 30 includes a server computer, a personal computer, data storage, communication equipment, or a combination thereof. The regional system 30 includes a control unit 31, a memory unit 32, and a communication unit 33. The hardware configurations of the control unit 31, the memory unit 32, and the communication unit 33 may be similar to those of the control unit 11, the memory unit 12, and the communication unit 13, respectively.

[0026] The multiple regional systems 30 are each located in a different region from each other. In this embodiment, an example is given in which the regional system 30 is located in the same region as the load balancer 20, but the regional system 30 does not have to be located in the same region as the load balancer 20. For example, as long as the load balancer 20 can mediate communication between the regional system 30 and the user terminal 50 at a certain communication speed, the regional system 30 may be located in a different region from the load balancer 20. In this case, the load balancer 20 closest to the user terminal 50 accepts a request from the user terminal 50.

[0027] In this embodiment, an example is given in which one regional system 30 is deployed in one region, but multiple regional systems 30 may be deployed in one region. Furthermore, the number of regions in which regional systems 30 are deployed is not limited to three as in this embodiment. The number of regions in which regional systems 30 are deployed may be two, or four or more. As with the management server 10, the programs stored in the regional system 30 may be supplied to the regional system 30 via the network N, a reading unit, or an input / output unit.

[0028] The domain name system 40 is a system for managing domain names. For example, the domain name system 40 includes a server computer, a personal computer, a data storage device, a communication device, or a combination thereof. The domain name system 40 includes a control unit 41, a memory unit 42, and a communication unit 43. The hardware configurations of the control unit 41, the memory unit 42, and the communication unit 43 may be similar to those of the control unit 11, the memory unit 12, and the communication unit 13, respectively.

[0029] As with the management server 10, the programs stored in the domain name system 40 may be supplied to the domain name system 40 via the network N, a reading unit, or an input / output unit. Although one domain name system 40 is shown in FIG. 1, each of multiple domain name systems 40 may be connected to the network N. For example, each of the multiple domain name systems 40 may be located in the same region as the load balancer 20 and the regional system 30. In the example of this embodiment, a domain name system 40 may be located in each of Japan, the United States, and Europe.

[0030] The user terminal 50 is a computer of a user who belongs to a tenant. For example, the user terminal 50 is a personal computer, a tablet, a smartphone, or a wearable terminal. The user terminal 50 includes a control unit 51, a memory unit 52, a communication unit 53, an operation unit 54, and a display unit 55. The hardware configurations of the control unit 51, the memory unit 52, and the communication unit 53 may be similar to those of the control unit 11, the memory unit 12, and the communication unit 13, respectively.

[0031] For example, the operation unit 54 is an input device such as a touch panel or a mouse. The display unit 55 is a liquid crystal or organic EL display. As with the management server 10, the programs stored in the user terminal 50 may be supplied to the user terminal 50 via the network N, a reading unit, or an input / output unit. Although one user terminal 50 is shown in FIG. 1, each of multiple user terminals 50 may be connected to the network N.

[0032] The multi-tenant system 1 only needs to include at least one computer. The computers included in the multi-tenant system 1 are not limited to the example in FIG. 1. For example, the multi-tenant system 1 may include only one load balancer 20 in one of multiple regions. In this case, the management server 10, the load balancers 20 in the other regions, the regional systems 30, the domain name systems 40, and the user terminals 50 exist outside the multi-tenant system 1.

[0033] For example, the multi-tenant system 1 may include only a load balancer 20 in one of a plurality of regions and a domain name system 40. The multi-tenant system 1 may include only a management server 10 and a load balancer 20 in one of a plurality of regions. For example, the multi-tenant system 1 may include at least one of the regional systems 30A, 30B, and 30C. The multi-tenant system 1 may include any combination of the computers in FIG. 1, and other computers may exist outside the multi-tenant system 1.

[0034] For example, if this disclosure is a document filed with the Japan Patent Office, multi-tenant system 1 may include only Japan load balancer 20A. An embodiment in which multi-tenant system 1 includes only the functionality of Japan load balancer 20A is also within the scope of this disclosure. If this disclosure is a document filed with the United States Patent and Trademark Office, multi-tenant system 1 may include only U.S. load balancer 20B. An embodiment in which multi-tenant system 1 includes only the functionality of U.S. load balancer 20B is also within the scope of this disclosure. Similarly, for other regions, an embodiment in which multi-tenant system 1 includes only the functionality implemented by load balancer 20 in a certain region is also within the scope of this disclosure.

[0035] [2. Overview of the multi-tenant system] In this embodiment, data for each of a plurality of tenants is managed by a regional system 30 in one of a plurality of regions, and a subdomain is assigned to each of the plurality of tenants. For example, the regional system 30 manages data registered by users belonging to the tenants. The data managed by the regional system 30 may be of any type. For example, the regional system 30 manages document files, image files, audio files, a database in groupware, messages exchanged using communication tools, login authentication information, information on individual tenants, information on individual users, or other data.

[0036] Each tenant is assigned a subdomain for users belonging to that tenant to use the groupware. The subdomain may be fixed so that users belonging to the tenant cannot change it, but this embodiment illustrates an example in which users can change the subdomain after the fact. For example, when a user inputs a URL including the subdomain assigned to the tenant to which the user belongs via the operation unit 54 in order to use the groupware, the user terminal 50 displays the page of the URL on the display unit 55.

[0037] FIG. 2 is a diagram showing an example of a page of a URL including a subdomain assigned to a tenant. In this embodiment, an example is given in which page P is displayed on a browser installed on user terminal 50, but page P may also be displayed on a program other than a browser. For example, the other program may be a program dedicated to groupware. The other program may also be able to call the browser using a function called web view.

[0038] Generally, there is no unique, clear definition for domains and subdomains, and various definitions exist. In this embodiment, an example is given in which, in a URL, in the string between the ": / / " immediately after the protocol name and the following " / ", the part after the first "." is the domain, and the part before the first "." is the subdomain. In the example of Figure 2, in the string "aaa.xxx-gate.com", the part after the first ".", "xxx-gate.com", is the domain. In this example, a case is given in which the part before the first ".", "aaa", is the subdomain.

[0039] There is also a definition in the world that in a URL, the entire string between the ": / / " immediately after the protocol name and the following " / " is the domain, and the part of the string before the first "." is the subdomain. This definition may be applied to this embodiment. In the case of this definition, in the example of FIG. 2, the entire string "aaa.xxx-gate.com" is the domain. In the string "aaa.xxx-gate.com", the part "aaa" before the first "." is the subdomain. Domains and subdomains may have other well-known definitions.

[0040] In the example of FIG. 2, the user enters a URL including the subdomain "aaa" assigned to the tenant "AAA Corporation," where the user works, into the browser. For example, the user terminal 50 displays, on the display unit 55, page P of the cloud-based groupware contracted by the tenant "AAA Corporation." The user terminal 50 can access the regional system 30 that manages data for the tenant "AAA Corporation," where the user works, among the multiple regional systems 30, to display the data on page P or download the data. Logging in to the groupware may be performed by the regional system 30 or by another computer, such as the management server 10.

[0041] 3 is a diagram illustrating an example of access control executed in the multi-tenant system 1. For example, a user terminal 50 of a user in a certain region uses the domain name system 40 to resolve the name of a URL entered in a browser by the user, and obtains the address of a regional system 30 corresponding to the subdomain included in the URL. The user terminal 50 transmits a request including the URL specified by the user and the address obtained from the domain name system 40 to a load balancer 20 in the region where the user is located, among multiple load balancers 20. The load balancer 20 causes the user terminal 50 to access the regional system 30 indicated by the address.

[0042] For example, suppose that data for tenant "AAA Corporation" is managed in the Japanese regional system 30A. When a user in Japan enters a URL including the subdomain "aaa" into a browser, the user terminal 50 resolves the name of the URL using the domain name system 40 and obtains the address of the Japanese regional system 30A. The user terminal 50 sends a request including the URL and the address of the Japanese regional system 30A to the Japanese load balancer 20A where the user is located. Upon receiving the request, the Japanese load balancer 20A causes the user terminal 50 to access the Japanese regional system 30A that manages the data of the tenant to which the user belongs. In this case, communication is completed within Japan.

[0043] For example, suppose a user belonging to the tenant "AAA Corporation" is on a business trip to the United States. When the user on a business trip to the United States enters a URL including the subdomain "aaa" into a browser, the user terminal 50 resolves the name of the URL using the domain name system 40 and obtains the address of the Japanese regional system 30A. The user terminal 50 sends a request including the URL and the address of the Japanese regional system 30A to the load balancer 20B in the United States where the user is located. Upon receiving the request, the load balancer 20B in the United States causes the user terminal 50 to access the Japanese regional system 30A that manages data of the tenant to which the user belongs. In this case, the user terminal 50 in the United States communicates with the Japanese regional system 30A via the load balancer 20B in the United States.

[0044] For example, suppose a user belonging to the tenant "AAA Corporation" is on a business trip to Europe. When the user on a business trip to Europe enters a URL including the subdomain "aaa" into a browser, the user terminal 50 resolves the name of the URL using the domain name system 40 and obtains the address of the Japanese regional system 30A. The user terminal 50 sends a request including the URL and the address of the Japanese regional system 30A to the European load balancer 20C where the user is located. Upon receiving the request, the European load balancer 20C causes the user terminal 50 to access the Japanese regional system 30A that manages data of the tenant to which the user belongs. In this case, the user terminal 50 in Europe communicates with the Japanese regional system 30A via the European load balancer 20C.

[0045] The above-described access control is also applicable to other tenants besides the tenant "AAA Inc." In the example of FIG. 3, it is assumed that the data of the tenant "BBB Inc." is managed in the regional system 30B in the United States. Furthermore, it is assumed that the subdomain "bbb" is assigned to the tenant "BBB Inc." When a user belonging to the tenant "BBB Inc." enters a URL including the subdomain "bbb" in a browser, as indicated by the dotted arrow in FIG. 3, the user terminal 50 accesses the regional system 30B in the United States due to the access control of the load balancer 20 in the region where the user is located, among the multiple load balancers 20.

[0046] In the example of FIG. 3, it is assumed that data for tenant "CCC Corporation" is managed in a European regional system 30C. Furthermore, it is assumed that a subdomain "ccc" is assigned to tenant "CCC Corporation." When a user belonging to tenant "CCC Corporation" enters a URL including the subdomain "ccc" in a browser, the user terminal 50 accesses the European regional system 30C due to access control by the load balancer 20 in the region where the user is located, among the multiple load balancers 20.

[0047] As described above, in the multi-tenant system 1 of this embodiment, data for each of a plurality of tenants is managed by a regional system 30 in one of a plurality of regions, and a subdomain is assigned to each of the plurality of tenants. When the multi-tenant system 1 receives a request including a subdomain assigned to a tenant from a user terminal 50, the multi-tenant system 1 causes the user terminal 50 to access the regional system 30 that manages the data of the tenant to which the subdomain is assigned. This enables the multi-tenant system 1 to achieve appropriate access control. Details of the multi-tenant system 1 will be described below.

[0048] [3. Functions realized by a multi-tenant system] Fig. 4 is a diagram showing an example of functions realized in the multi-tenant system 1. Since the load balancers 20A, 20B, and 20C have similar functions, they are shown in Fig. 4 as one load balancer 20. Similarly, since the regional systems 30A, 30B, and 30C have similar functions, they are shown in Fig. 4 as one regional system 30.

[0049] [3-1. Functions realized by the management server] For example, the management server 10 includes a data storage unit 100 and a relationship reflecting unit 101. The data storage unit 100 is realized by the storage unit 12. The relationship reflecting unit 101 is realized by the control unit 11.

[0050] [Data storage section] The data storage unit 100 stores management data for the groupware. For example, the data storage unit 100 stores a domain map M, which is a database in which subdomains of tenants are stored. The domain map M may be stored in the data storage unit 200 of the load balancer 20. In this case, when the domain map M in the data storage unit 100 is updated, the update is reflected in the domain map M in the data storage unit 100.

[0051] 5 is a diagram illustrating an example of a domain map M. For example, the domain map M stores tenant identification information, subdomains, and regional system identification information. Any data may be stored in the domain map M, and the data stored in the domain map M is not limited to the example in FIG. 5. For example, the domain map M may store other information such as the name and address of a tenant, information such as the account of a user belonging to the tenant, or a change history of a subdomain.

[0052] The tenant identification information is information that enables a computer to identify a tenant. In this embodiment, a case where the tenant identification information is not changed afterward is exemplified, but the tenant identification information may be changed afterward. For example, the tenant identification information may be a tenant ID assigned to a tenant, the tenant's name, the tenant's email address, the tenant's phone number, or other information. The subdomain associated with the tenant identification information is a subdomain assigned to the tenant identified by the tenant identification information.

[0053] In this embodiment, a case where tenant identification information and subdomains have a one-to-one relationship will be exemplified. That is, a case where one subdomain is assigned to one tenant will be exemplified. Note that tenant identification information and subdomains may have a one-to-many or many-to-one relationship. That is, multiple subdomains may be assigned to one tenant, or one common subdomain may be assigned to multiple tenants.

[0054] The regional system identification information is information that enables a computer to identify the regional system 30. In this embodiment, since the address of the regional system 30 is specified by the domain name system 40, the regional system identification information is information other than the address of the regional system 30. For example, the regional system identification information may be the name of the regional system 30, the name of the region in which the regional system 30 is located, or other information. Note that the regional system identification information may also be the address of the regional system 30.

[0055] For example, when a new tenant signs up for groupware, the management server 10 issues tenant identification information for the new tenant so that the tenant identification information does not overlap with the tenant identification information of other tenants. The management server 10 stores the issued tenant identification information, the subdomain assigned to the new tenant, and the regional system identification information of the regional system 30 that manages the data of the new tenant in the domain map M.

[0056] In this embodiment, a case where a new tenant specifies the subdomain to be assigned to the new tenant by itself is taken as an example, but the management server 10 may automatically issue the subdomain to be assigned to the new tenant. Similarly, a case where a new tenant specifies the regional system 30 or region in which its data will be managed by itself is taken as an example, but the management server 10 may automatically determine the regional system 30 or region in which its data will be managed based on information such as the address of the new tenant.

[0057] It should be noted that the data stored in the data storage unit 100 is not limited to the domain map M. The data storage unit 100 may store any data. For example, the data storage unit 100 may store a database similar to the address database DB described below. The data storage unit 100 may store a database in which authentication information for users to log in to the groupware is stored. The data storage unit 100 may store a database in which basic information about tenants is stored. The data storage unit 100 may store a database in which information such as the addresses of each of multiple regional systems 30 is stored. The data storage unit 100 may store a database in which various other information in the groupware is stored.

[0058] [Relationship Reflection Section] The relationship reflection unit 101 reflects the relationship between the subdomains assigned to each of the multiple tenants and the addresses of the regional system 30 that manages the data of the tenant in the domain name system 40. For example, when a new tenant signs up for groupware, the relationship reflection unit 101 transmits data indicating domain information including the subdomain assigned to the tenant and the address of the regional system 30 that manages the data of the tenant to the domain name system 40. The domain name system 40 updates the address database DB, which will be described later, based on the data transmitted by the relationship reflection unit 101.

[0059] [3-2. Functions realized by load balancer] For example, the load balancer 20 includes a data storage unit 200, a reception unit 201, an identification unit 202, and an access control unit 203. The data storage unit 200 is realized by the storage unit 22. The reception unit 201, the identification unit 202, and the access control unit 203 are realized by the control unit 21.

[0060] [Data storage section] The data storage unit 200 stores data necessary for access control performed by the load balancer 20. For example, the data storage unit 200 may store a database similar to the address database DB described below. In this case, the user terminal 50 may send a request including a URL entered by the user to the load balancer 20 without inquiring about the address of the regional system 30 from the domain name system 40. In this case, the request does not include the address of the regional system 30. The identification unit 202 described below may identify the address of the regional system 30 based on a database similar to the address database DB.

[0061] For example, the data storage unit 200 may store a database similar to the domain map M. Furthermore, the database may store the address of the regional system 30. In this case, the user terminal 50 may send a request including a URL entered by the user to the load balancer 20 without inquiring about the address of the regional system 30 from the domain name system 40. In this case, the request does not include the address of the regional system 30. The identification unit 202, which will be described later, may identify the address of the regional system 30 based on a database similar to the domain map M.

[0062] [Reception] The reception unit 201 receives a request including a subdomain assigned to one of multiple tenants from a computer. In this embodiment, a case where the user terminal 50 corresponds to the computer is taken as an example. The computer may be any computer that is capable of sending a request. The computer is not limited to the user terminal 50. For example, the computer may be a computer located between the load balancer 20 and the user terminal 50, or may be a computer of another service (e.g., another groupware) that is affiliated with the groupware of this embodiment.

[0063] The request is a request for the user terminal 50 to access tenant data, and is a request for the user terminal 50 to access the regional system 30 that manages tenant data. In this embodiment, an example is given in which the reception unit 201 receives an HTTP request from the user terminal 50, but the reception unit 201 may also receive other requests, such as an FTP request or an SSH request. The format of these requests may be a format defined by a known communication protocol. The reception unit 201 can receive requests of any communication protocol.

[0064] For example, the user terminal 50 sends a DNS request to the domain name system 40 and obtains the address of the regional system 30 from the domain name system 40. A request for the user terminal 50 to access the regional system 30 is routed by a communication device in the network N so that the request is sent to the load balancer 20 in the same region as the user terminal 50. In this embodiment, a different subdomain is assigned to each tenant, but the domain is common to multiple tenants. A request including a domain common to multiple tenants may be routed in the network N so that the request is sent to the load balancer 20 in the same region as the user terminal 50. The series of processes until the reception unit 201 receives a request from the user terminal 50 can use processes adopted in known load balancers.

[0065] For example, the reception unit 201 may allow a load balancer 20 in the same region to receive a request from the user terminal 50 based on the Cloud Load Balancing method provided by Google (registered trademark). The reception unit 201 can also receive a request from the user terminal 50 based on various other methods. If a load balancer 20 is not located in the region where the user terminal 50 is located, the reception unit 201 of a load balancer 20 in a region relatively close to the region where the user terminal 50 is located (for example, the region closest to the region where the user terminal 50 is located) receives the request. The processing in this case can also use processing adopted by known load balancers.

[0066] [Specific part] When the receiving unit 201 receives a request, the identifying unit 202 identifies the regional system 30 that is the access destination regional system and that manages the data of the tenant to which the subdomain included in the request is assigned. The regional system 30 that is the access destination of the user terminal 50, among the multiple regional systems 30. In other words, the regional system 30 that is the access destination of the user terminal 50 is the regional system 30 that the access control unit 203, described below, should access, among the multiple regional systems 30.

[0067] In this embodiment, the relationship between domain information including subdomains and addresses corresponding to the domain information is defined in the domain name system 40. Furthermore, before sending a request to the load balancer 20, the user terminal 50 sends a DNS request to the domain name system 40 and obtains the address of the destination regional system from the domain name system 40. Therefore, when a request is accepted, the identification unit 202 identifies the destination regional system based on an address managed by the domain name system 40 and associated with the subdomain included in the request. The request received by the load balancer 20 from the user terminal 50 includes the address obtained by the user terminal 50 from the domain name system 40. Therefore, the identification unit 202 identifies the destination regional system by referring to the address included in the request (an address managed by the domain name system 40 and included in the request sent to the load balancer 20 by the user terminal 50).

[0068] [Access Control Unit] The access control unit 203 causes the user terminal 50 to access the destination regional system identified by the identification unit 202. In this embodiment, the user terminal 50 acquires the address of the destination regional system from the domain name system 40 before sending a request to the load balancer 20, and therefore the access control unit 203 causes the user terminal 50 to access the destination regional system indicated by the address included in the request sent by the user terminal 50. The access control unit 203 executes routing (path control) for the user terminal 50 so that the user terminal 50 accesses the destination regional system.

[0069] For example, the access control unit 203 transmits data transmitted by the user terminal 50 to the destination regional system identified by the identification unit 202. The access control unit 203 transmits data managed by the destination regional system identified by the identification unit 202 to the user terminal 50. In other words, the access control unit 203 mediates communication between the destination regional system and the user terminal 50. The mediation method itself may be a method adopted by a known load balancer.

[0070] For example, the access control unit 203 may mediate communication between the accessed regional system and the user terminal 50 based on the Cloud Load Balancing technique provided by Google (registered trademark). The access control unit 203 can mediate communication between the accessed regional system and the user terminal 50 based on various other techniques. Every time the user terminal 50 sends a request, the load balancer 20 executes processing by the reception unit 201, the identification unit 202, and the access control unit 203, and mediates communication between the accessed regional system and the user terminal 50.

[0071] [3-3. Functions realized by the regional system] For example, the regional system 30 includes a data storage unit 300, a transmission unit 301, and a reception unit 302. The data storage unit 300 is realized by the storage unit 32. The transmission unit 301 and the reception unit 302 are each realized by the control unit 31.

[0072] [Data storage section] The data storage unit 300 stores tenant data. For example, tenant data corresponds to content in groupware. The data storage unit 300 stores data registered by a user belonging to a certain tenant from page P. Tenant data may be data other than content. For example, the data storage unit 300 may store a database that stores authentication information for a user belonging to a certain tenant to log in to the groupware. In this case, the database corresponds to tenant data. Information such as user accounts and passwords is stored in the database.

[0073] [Transmitter] The transmission unit 301 transmits various data to a computer that is a communication partner of the regional system 30. For example, the transmission unit 301 transmits data of a certain tenant to a user terminal 50 of a user that belongs to the tenant via a load balancer 20 in the region where the user terminal 50 is located.

[0074] [Receiver] The receiving unit 302 receives various data from a computer that is a communication partner of the regional system 30. For example, the receiving unit 302 receives data of a tenant from a user terminal 50 of a user that belongs to the tenant via a load balancer 20 in the region where the user terminal 50 is located.

[0075] [3-4. Functions realized by the Domain Name System] For example, the domain name system 40 includes a data storage unit 400, a transmission unit 401, and a reception unit 402. The data storage unit 400 is realized by the storage unit 42. Each of the transmission unit 401 and the reception unit 402 is realized by the control unit 41.

[0076] [Data storage section] The data storage unit 400 stores data necessary for managing domain names. For example, the data storage unit 400 stores an address database DB in which domain information and addresses of the domains are stored. Note that the data storage unit 400 may store databases other than the address database DB.

[0077] FIG. 6 is a diagram showing an example of an address database DB. In the example of FIG. 6, domain information indicates subdomains and domains. Domain information may indicate only subdomains. Information stored as domain information may be publicly known information. In this embodiment, the word "address" refers to an IP address. The address may be a virtual IP address. The address database DB may store domain information and addresses of domains other than the groupware domain.

[0078] [Transmitter] The transmitting unit 401 transmits various data to a computer that is a communication partner of the domain name system 40. For example, when the domain name system 40 receives a DNS request from a user terminal 50, the transmitting unit 401 transmits an address corresponding to the DNS request to the user terminal 50 based on the address database DB.

[0079] [Receiver] The receiving unit 402 receives various data from computers that are communicating with the domain name system 40. For example, the receiving unit 402 receives a DNS request from the user terminal 50.

[0080] [3-5. Functions implemented on user devices] For example, the user terminal 50 includes a data storage unit 500, a transmission unit 501, and a reception unit 502. The data storage unit 500 is realized by the storage unit 52. The transmission unit 501 and the reception unit 502 are each realized by the control unit 51.

[0081] [Data storage section] The data storage unit 500 stores various data for the groupware. For example, the data storage unit 500 stores a browser. The data storage unit 500 may also store a program dedicated to the groupware.

[0082] [Transmitter] The transmitter 501 transmits various data to a computer with which the user terminal 50 communicates. For example, the transmitter 501 transmits a DNS request to the domain name system 40. The transmitter 501 transmits a request including a subdomain of the tenant to which the user belongs to an external computer. The request includes an address obtained from the domain name system 40. The request is routed by a communication device in the network N so that it is sent to a load balancer 20 in the same region as the user terminal 50. For example, the transmitter 501 may transmit data of a certain tenant (e.g., a file that the user wants to register in the regional system 30) to a regional system 30 that manages the data of the certain tenant via a load balancer 20 in the region where the user terminal 50 is located.

[0083] [Receiver] The receiving unit 502 receives various data from a computer with which the user terminal 50 communicates. For example, the receiving unit 502 receives an address in response to a DNS request from the domain name system 40. The receiving unit 502 receives data of a certain tenant from a regional system 30 that manages the data of the tenant via a load balancer 20 in the region where the user terminal 50 is located.

[0084] [4. Processing performed in a multi-tenant system] Fig. 7 is a diagram showing an example of processing executed in the multi-tenant system 1. The processing in Fig. 7 is executed by the control units 21, 31, 41, and 51 executing programs stored in the storage units 22, 32, 42, and 52, respectively. Although Fig. 7 does not show the processing of the management server 10, it is assumed that, when the processing in Fig. 7 is executed, the management server 10 requests the domain name system 40 to register the domain information and addresses of the tenants, and that the domain information and addresses are stored in the address database DB.

[0085] 7, when a user inputs a URL including a subdomain assigned to the tenant to which the user belongs in the browser of the user terminal 50, the user terminal 50 sends a DNS request corresponding to the URL to the domain name system 40 (S1). The domain name system 40 receives the DNS request from the user terminal 50 (S2). The domain name system 40 sends the address of the regional system 30 to the user terminal 50 based on the address database DB (S3). The user terminal 50 receives the address of the regional system 30 from the domain name system 40 (S4).

[0086] The user terminal 50 transmits a request including the URL entered by the user and the address received in S4 (S5). As described above, the request is routed by communication devices in the network N so that it is sent to one of the multiple load balancers 20 that is located in the same region as the user terminal 50. The load balancer 20 receives the request from the user terminal 50 (S6).

[0087] Based on the address included in the request, the load balancer 20 causes the user terminal 50 to access one of the multiple regional systems 30 that is indicated by the address received from the domain name system 40 (S7). The regional system 30 accepts the access from the user terminal 50 (S8), and this processing ends. Thereafter, data communication is performed between the load balancer 20, the regional system 30, and the user terminal 50 via the load balancer 20. The user terminal 50 downloads tenant data from the regional system 30. The user terminal 50 registers new data and updates or deletes existing data in the regional system 30. These communications are mediated by the load balancer 20 in the same region as the user terminal 50.

[0088] [5. Summary of embodiments] The multi-tenant system 1 of this embodiment accepts a request from a user terminal 50, the request including a subdomain assigned to one of multiple tenants. When the multi-tenant system 1 accepts the request, it identifies a destination regional system that manages the data of the tenant to which the subdomain included in the request is assigned. The multi-tenant system 1 allows the user terminal 50 to access the destination regional system. The multi-tenant system 1 can perform appropriate access control when the data of each of multiple tenants is managed by one of the regional systems 30 in multiple regions and each of the multiple tenants is assigned a subdomain. For example, when a tenant directly accesses the regional system 30 that manages its data from a region other than the region where the regional system 30 is located, the time required to download the data increases due to distance. In this regard, the time required for downloading can be shortened by controlling the load balancer 20.

[0089] Furthermore, the multi-tenant system 1 reflects in the domain name system 40 the relationship between the subdomains assigned to each of the multiple tenants and the addresses of the regional systems 30 that manage the data of the tenants. When a request is accepted, the multi-tenant system 1 identifies the regional system to be accessed based on an address managed by the domain name system 40 and associated with the subdomain included in the request. The multi-tenant system 1 can accurately identify the access destination of the user terminal 50 using the domain name system 40 and perform appropriate access control. For example, by managing information for access control in the address database DB of the domain name system 40, the load balancer 20 does not need to manage the information. This allows the multi-tenant system 1 to reduce the management burden on the load balancer 20. For example, by having the user terminal 50 obtain the address of the regional system to be accessed from the domain name system 40 before sending a request to the load balancer 20, the destination IP addresses of communication packets that the load balancer 20 may receive from the user terminal 50 can be limited to the number of regional systems 30. Furthermore, the number of rules required for routing can be the same. As the number of rules increases, it takes time for the load balancer 20 to verify the rules, which increases communication latency, but the multi-tenant system 1 of this embodiment has a small number of rules, so communication latency can be reduced. Even when the load balancer 20 acquires an address from the domain name system 40, communication latency may increase, but the multi-tenant system 1 of this embodiment can reduce communication latency by having the user terminal 50 acquire the address.

[0090] [6. Modifications] The present disclosure is not limited to the examples of the embodiments, and can be modified without departing from the spirit of the present disclosure.

[0091] 8 is a diagram showing an example of a hardware configuration in a modified example. The multi-tenant system 1 in the modified example includes a login server 60 and a partner server 70. Each of the login server 60 and the partner server 70 is a server computer. For example, the login server 60 includes a control unit 61, a storage unit 62, and a communication unit 63. The partner server 70 includes a control unit 71, a storage unit 72, and a communication unit 73. The hardware configurations of the control units 61 and 71, the storage units 62 and 72, and the communication units 63 and 73 may be similar to those of the control unit 11, the storage unit 22, and the communication unit 13, respectively.

[0092] FIG. 9 is a diagram showing an example of functions realized in the modified example. For example, the management server 10 includes a subdomain change unit 102. The subdomain change unit 102 is realized by the control unit 11. The load balancer 20 includes a storage unit 204 and a transmission unit 205. The storage unit 204 and the transmission unit 205 are each realized by the control unit 21. The user terminal 50 includes a session management unit 503. The session management unit 503 is realized by the control unit 51. The login server 60 includes a data storage unit 600 and a login execution unit 601. The data storage unit 600 is realized by the storage unit 62. The login execution unit 601 is realized by the control unit 61.

[0093] [6-1. Variation 1] For example, as explained somewhat in the embodiment, a user belonging to a certain tenant may change the subdomain assigned to that tenant after the fact. In the first modification, an example is given in which a user with administrative authority for a certain tenant changes the subdomain, but a user without administrative authority may also be allowed to change the subdomain.

[0094] The management server 10 of the first modification includes a subdomain change unit 102. The subdomain change unit 102 changes the subdomain assigned to a plurality of tenants based on a request from each of the tenants. The request is a request from the user terminal 50 of the user who instructed the subdomain change. The request includes a new subdomain (changed subdomain) designated by the user. The user can designate any character string as the new subdomain from another page to which a transition can be made from page P in FIG. 2.

[0095] For example, the subdomain change unit 102 updates the domain map M so that a subdomain assigned to a certain tenant is changed to a new subdomain entered by a user with management authority for the tenant. The subdomain change unit 102 changes the subdomain associated with the tenant identification information of the tenant in the domain map M to the new subdomain included in the request. The subdomain change unit 102 may request the regional system 30 that manages the data of the tenant to change the subdomain. Upon receiving the request from the management server 10, the regional system 30 may change the subdomain of the tenant to the new subdomain.

[0096] When the domain name system 40 is used as in the embodiment, the relationship reflecting unit 101 reflects the change of the subdomain in the address database DB as in Variation 2 described below. When the domain name system 40 is not used, as described in the embodiment, the data storage unit 100 stores the relationship between the subdomain and the address of the area system 30. The relationship is stored in the domain map M or another database. The subdomain changing unit 102 may change the subdomain in the other database. Furthermore, the subdomain changing unit 102 may determine whether a new subdomain entered by the user is already in use, and if the new subdomain is not yet in use, change the subdomain.

[0097] When a request including a changed subdomain is received, the identification unit 202 of Modification 1 identifies the regional system 30 that manages the data of the tenant to which the changed subdomain included in the request is assigned as the destination regional system. This is different from the embodiment in that the subdomain included in the request is the changed one, but other aspects of the process by which the identification unit 202 identifies the destination regional system are as described in the embodiment. The process of the identification unit 202 when the domain name system 40 is used will be described in Modification 2 below. When the domain name system 40 is not used, the identification unit 202 can identify the destination regional system corresponding to the changed subdomain based on the domain map M or another database.

[0098] The multi-tenant system 1 of Variation 1 changes the subdomain assigned to a tenant based on a request from each of the tenants. When a request including the changed subdomain is accepted, the multi-tenant system 1 identifies the regional system 30 that manages the data of the tenant to which the changed subdomain included in the request is assigned as the destination regional system. The multi-tenant system 1 can perform appropriate access control even if the subdomain is changed. Users belonging to a tenant can change their subdomain after the fact, which improves user convenience.

[0099] [6-2. Variation 2] For example, in Modification 1, when a user belonging to a certain tenant changes his / her subdomain, the change in the subdomain may be automatically reflected in the domain name system 40. When a subdomain assigned to one of a plurality of tenants is changed, the relationship reflecting unit 101 in Modification 2 reflects the change in the subdomain in the domain name system 40 that manages the relationship between the subdomain assigned to each of the plurality of tenants and the address of the regional system 30 that manages the data of the tenant.

[0100] For example, when a user belonging to a tenant changes a subdomain assigned to the tenant, the relationship reflection unit 101 transmits to the domain name system 40 data indicating the domain information before the change, the domain information after the change, and the address of the regional system 30 that manages the data of the tenant. The domain name system 40 updates the address database DB based on the data transmitted by the relationship reflection unit 101. Note that the information included in the data is not limited to the above example, as long as the data contains information that enables the domain name system 40 to identify the domain information to be changed and the domain information after the change. For example, the address of the regional system 30 does not need to be included in the data.

[0101] When a request including a changed subdomain is received, the identification unit 202 of the second modification identifies the destination regional system by acquiring an address associated with the changed subdomain included in the request. In the second modification, the user terminal 50 also acquires an address associated with the changed subdomain from the domain name system 40 and includes it in the request. Since the request includes an address associated with the changed subdomain, the identification unit 202 can identify the destination regional system by referring to the address. This differs from the embodiment in that the subdomain included in the request is the changed one, but other aspects of the process by which the identification unit 202 identifies the destination regional system are as described in the embodiment.

[0102] In the multi-tenant system 1 of the second modification, when a subdomain assigned to one of multiple tenants is changed, the change in the subdomain is reflected in the domain name system 40 that manages the relationship between the subdomain assigned to each of the multiple tenants and the address of the regional system 30 that manages the data of that tenant. When a request including the changed subdomain is accepted, the multi-tenant system 1 identifies the regional system to be accessed by obtaining the address associated with the changed subdomain included in the request. The multi-tenant system 1 can use the domain name system 40 to perform appropriate access control even when the subdomain is changed.

[0103] [6-3. Variation 3] For example, when the load balancer 20 mediates communication between a user terminal 50 of a user belonging to a certain tenant and a regional system 30 that manages data of the tenant, the load balancer 20 may temporarily store non-confidential data among the data. When the user terminal 50 or a user terminal 50 of another user belonging to the same tenant accesses the non-confidential data, the non-confidential data stored in the load balancer 20 may be transmitted to the user terminal 50.

[0104] The load balancer 20 of the third modification includes a storage unit 204 and a transmission unit 205. The storage unit 204 does not store confidential data, which is among the data transmitted from the accessed regional system to the user terminal 50, in the data storage unit 200 of the load balancer 20, but stores non-confidential data, which is not confidential, in the data storage unit 200. The load balancer 20 is an example of a device located between the user terminal 50 and the accessed regional system. This device may be a device other than the load balancer 20. For example, this device may be a server computer other than the load balancer 20. The method for determining whether each piece of tenant data is classified as confidential data or non-confidential data can be a known method. For example, classification information indicating whether the data is confidential data or non-confidential data may be associated with the tenant data. In this case, the storage unit 204 determines whether the data is confidential data or non-confidential data based on the classification information associated with the data received from the regional system 30. Alternatively, for example, confidential data or non-confidential data may be distinguished based on the URL of the tenant data. Data originally included in the product may be identified by a URL and treated as non-confidential data.

[0105] For example, the storage unit 204 may determine whether the data received from the regional system 30 is confidential data or non-confidential data based on other information, such as the extension of the data, rather than on the classification information. If the storage unit 204 determines that the data received from the regional system 30 is confidential data, it does not store the data in the data storage unit 200. If the storage unit 204 determines that the data is non-confidential data, it stores the data in the data storage unit 200. Whether the tenant's data is classified as confidential data or non-confidential data may be determined by another computer, such as the regional system 30.

[0106] When non-confidential data stored in the data storage unit 200 is requested again by the user terminal 50, the transmission unit 205 of the third modification transmits the non-confidential data to the user terminal 50 without acquiring the non-confidential data again from the regional system 30. Information indicating the data requested by the user terminal 50 is included in the request from the user terminal 50. The information may be included in the URL, or may be included in the request as data separate from the URL. For example, the information may be the file name of a document file or the like.

[0107] For example, when the reception unit 201 receives a request from the user terminal 50, the transmission unit 205 identifies the data requested by the user terminal 50 based on the request. The transmission unit 205 determines whether the identified data is stored in the data storage unit 200. When it is determined that the identified data is stored in the data storage unit 200, the transmission unit 205 transmits the data stored in the data storage unit 200 to the user terminal 50. When it is determined that the identified data is not stored in the data storage unit 200, the access control unit 203 executes access control in the same manner as in the embodiment. In this case, the regional system 30 transmits the requested data to the user terminal 50 via the load balancer 20.

[0108] The multi-tenant system 1 of the third modification does not store confidential data, which is among the data transmitted from the accessed regional system to the user terminal 50, in the data storage unit 200 of the load balancer 20, but stores non-confidential non-confidential data in the data storage unit 200. When the non-confidential data stored in the data storage unit 200 is requested again by the user terminal 50, the multi-tenant system 1 transmits the non-confidential data to the user terminal 50 without acquiring the non-confidential data again from the regional system 30. The user terminal 50 can quickly receive the non-confidential data. For example, the time required to display the page P is shortened. For example, the same data is not transmitted multiple times over the network N, thereby reducing the communication load on the network N.

[0109] [6-4. Variation 4] For example, in groupware, a user belonging to a tenant may log in from a common login page that is common to the tenants. The common login page has the same URL, including a subdomain. In the example of the URL shown in FIG. 2, the common login page has the same domain "xxx-gate.com" as the URL of the tenant's page P, such as "https: / / www.xxx-gate.com / ". The subdomain "www" of the common login page is common to multiple tenants. The subdomain "www" of the common login page may be common to all tenants, or may be common to only some tenants. In Variation 4, the common login page is managed by login server 60.

[0110] The common login page may be any URL and is not limited to the above example. For example, the domain of the common login page may be a domain different from the tenant URL. For example, users belonging to multiple different tenants may be able to start logging in from the common login page for any of the tenants. The common login page may be a page that is easy for users to remember, and may function as a simple gate that is not involved in communications after login authentication.

[0111] In Variation 4, the user terminal 50 executes login processing between the login server 60 and the user terminal 50 using the URL "https: / / www.xxx-gate.com / " of the common login page. Variation 4 takes as an example a case where the login is executed by the login server 60, but the login may also be executed by a computer other than the login server 60. For example, the management server 10 may execute the login processing. When the management server 10 executes the login processing, the user terminal 50 executes the login processing by communicating with the management server 10 via the load balancer 20. The URL of the common login page may also be the URL of the other computer. For example, a user enters his or her account and password from the common login page to log in to the groupware. The common login page may execute any authentication other than password authentication (for example, electronic certificate authentication, etc.).

[0112] For example, a user logs in to the groupware with an account name such as "user00001@aaa.xxx-gate.com." The account name may be an email address, but in variant example 4, it is not an email address. The part of the account name before the @ is user identification information that enables the management server 10 to identify the user. The part of the account name after the @ includes the subdomain and domain assigned to the tenant to which the user belongs. The @ is a symbol that the management server 10 uses to distinguish between user identification information, subdomains, and domains. The symbol may be a symbol other than @. For example, user identification information, subdomains, and domains may be distinguished by +, %, ¥, or other symbols.

[0113] The login server 60 of the fourth modification example includes a data storage unit 600 and a login execution unit 601. The data storage unit 600 stores data for a common login page and a database required for login (for example, a database storing user IDs and passwords). The login execution unit 601 executes login to a specific tenant based on input information entered on a common login page common to multiple tenants. The input information is information for authentication at the time of login. The process up to the display of the common login page is carried out regardless of whether the user is logged in to a specific tenant. For example, the login execution unit 601 displays the common login page on the user terminal 50. Data required for displaying the common login page (for example, HTML data) is stored in the data storage unit 600. The login execution unit 601 transmits the data to the user terminal 50, thereby displaying the common login page on the user terminal 50.

[0114] For example, if the user is not logged in to the tenant based on the account name and password (an example of input information) entered on the common login page, the login execution unit 601 executes login authentication by itself. If the authentication is successful or if the user is already logged in, redirection to the tenant page occurs. The data storage unit 600 is assumed to store a database in which account names and passwords that are correct for authentication are stored. However, the data storage unit 600 may store a user database for each tenant, and the login execution unit 601 may first identify the tenant by domain, including subdomains, search for a corresponding user from within that database, and attempt authentication if a corresponding user is found. This reduces search costs. The reception unit 201 of the fourth modification example receives a request from a user terminal 50 that has successfully logged in from the common login page. While the fourth modification example differs from the embodiment in that login is executed on the common login page, the processing of the reception unit 201 itself is as described in the embodiment.

[0115] In the example of the account name in Variation 4, since a subdomain is included after @, the login server 60 may redirect the user terminal 50 to the load balancer 20 when the login is completed. During the redirection, the load balancer 20 acquires the subdomain from the user terminal 50 or the login server 60. The processing after the load balancer 20 acquires the subdomain is the same as in the embodiment. At least one of the load balancer 20, the regional system 30, and the login server 60 may store data indicating that the user terminal 50 has completed authentication, preventing the user from logging in again.

[0116] The multi-tenant system 1 of Variation 4 executes login to a specific tenant based on input information entered on a common login page common to multiple tenants. The multi-tenant system 1 accepts a request from a user terminal 50 that has successfully logged in from the common login page. The multi-tenant system 1 can consolidate the entry pages for groupware into one using the common login page.

[0117] [6-5. Variation 5] For example, a user may belong to multiple tenants. In variant example 5, a case will be taken as an example where a user belongs to two tenants: "AAA Corporation's Japan Headquarters" and "AAA Corporation's US Branch." The case will be taken as an example where data for tenant "AAA Corporation's Japan Headquarters" is managed by a Japanese regional system 30A. The case will be taken as an example where data for tenant "AAA Corporation's US Branch" is managed by a US regional system 30B.

[0118] For example, if a user logs in to access data for the tenant "AAA Corporation's Japan Headquarters" and also logs in to access data for the tenant "AAA Corporation's US Branch," the user will be able to access data for both tenants simultaneously. In Variation 5, as in Variation 4, login may be performed on a common login page, or on a login page for each subdomain. A user may belong to three or more tenants. Furthermore, the data for each of the multiple tenants to which a user belongs may be managed in the same region.

[0119] The user terminal 50 of the fifth modification includes a session management unit 503. When a user belongs to more than one of multiple tenants, the session management unit 503 manages each session of the multiple tenants to which the user belongs as a different session. The session management unit 503 manages a session ID key for each tenant. The relationship between the tenant and the session ID key is recorded in the data storage unit 500. For example, the session ID key is managed by a browser cookie. The data storage unit 300 of the regional system 30 also stores the same session ID key as the session ID key stored in the user terminal 50, or information for verifying the key. By storing the session ID key in the cookie of each tenant, different sessions are maintained. The method of establishing the session itself may be a known method.

[0120] For example, session management by the session management unit 503 allows the user terminal 50 to simultaneously display pages of multiple tenants to which a user belongs. Simultaneous display means displaying pages in separate tabs in the same window, or displaying pages in multiple windows. These displays are possible without requiring logout. When a page of a first tenant to which a user belongs is displayed in a first tab of a browser window, the user terminal 50 displays a page of a second tenant to which the user belongs in a second tab of the browser window, without requiring the user to log out of the first tenant account. When a page of a first tenant to which a user belongs is displayed in a first window of the browser, the user terminal 50 displays a page of a second tenant to which the user belongs in a second window of the browser, without requiring the user to log out of the first tenant account.

[0121] For example, when a page showing data managed by the US regional system 30B is displayed on the user terminal 50, the user terminal 50 displays a page showing data managed by the Japanese regional system 30A without the user logging out with the account name of the tenant "US branch of AAA Corporation." The user terminal 50 displays a page showing data managed by the Japanese regional system 30A on the user terminal 50 without performing exclusive control between logins based on the account name of the tenant "Japan head office of AAA Corporation" and logins based on the account name of the tenant "US branch of AAA Corporation" (i.e., while each session is maintained).

[0122] For example, when a page showing data managed by the Japanese regional system 30A is displayed on the user terminal 50, the user terminal 50 displays a page showing data managed by the American regional system 30B without the user logging out with the account name of the tenant "AAA Corporation's Japan Headquarters." The user terminal 50 displays a page showing data managed by the American regional system 30B without exclud- ing logins based on the account name of the tenant "AAA Corporation's Japan Headquarters" and logins based on the account name of the tenant "AAA Corporation's US Branch" (i.e., while each session is maintained).

[0123] When a user belongs to more than one of multiple tenants, the multi-tenant system 1 of the fifth modification manages the sessions of the tenants to which the user belongs as different sessions. The multi-tenant system 1 can improve user convenience. For example, a user can simultaneously view a page of one tenant and a page of another tenant in separate tabs or windows. In conventional technologies, there are systems that can only display the page of an account of one tenant. In such systems, the user must switch accounts each time. The multi-tenant system 1 of the fifth modification can eliminate the need for such switching.

[0124] [6-6. Variation 6] For example, in the embodiment, when a user belonging to a certain tenant enters a URL including a subdomain assigned to the tenant into a browser, the load balancer 20 accepts a request including the URL. The load balancer 20 may accept other requests from a computer. When the load balancer 20 accepts other requests, it may perform access control so that the computer accesses an appropriate access destination.

[0125] In the sixth modification, an example is given of the processing when the groupware "XXX groupware" described in the embodiment cooperates with another groupware "ZZZ groupware." In the example of Fig. 8, the cooperation server 70 connected to the network N is the server computer of the other groupware "ZZZ groupware."

[0126] In the sixth modification, an example is given in which the operating company of the groupware "XXX groupware" is different from the operating company of another groupware "ZZZ groupware." Since the multi-tenant system 1 mainly includes computers managed by the operating company of the groupware "XXX groupware," in the example of FIG. 8, the linked server 70 is assumed to exist outside the multi-tenant system 1.

[0127] The operating company of the groupware "XXX groupware" may be the same as the operating company of another groupware "ZZZ groupware." In other words, the processing described in Modification 6 may be applied to a multi-tenant system 1 in which multiple groupware provided by the same operating company cooperate with each other. In this case, the cooperation server 70 may be included in the multi-tenant system 1.

[0128] For example, a user who belongs to a tenant that has subscribed to both groupware "XXX groupware" and another groupware "ZZZ groupware" can use both of them from his / her own user terminal 50. When the user enters the URL of the other groupware "ZZZ groupware" in the browser of the user terminal 50, the user terminal 50 accesses the linked server 70 and displays the page of the other groupware "ZZZ groupware" on the display unit 55. From that page, the user can use various functions provided by the other groupware "ZZZ groupware."

[0129] The processing of the load balancer 20 in the embodiment is processing for the user terminal 50 to access data managed by the groupware "XXX groupware." Therefore, when the user terminal 50 accesses data managed by another groupware "ZZZ groupware," the processing of the load balancer 20 in the embodiment is not executed. The processing for the user terminal 50 to access data managed by another groupware "ZZZ groupware" may be a known processing.

[0130] For example, a user can display data managed by the groupware "XXX groupware" on the page of another groupware "ZZZ groupware" by using a linking function between the groupware "XXX groupware" and another groupware "ZZZ groupware." This linking function is realized by an API provided on the groupware "XXX groupware" side. In the sixth modification, even when such an API is used, appropriate access control is performed by the load balancer 20.

[0131] 10 is a diagram showing an example of access control in Modification 6. The reception unit 201 in Modification 6 may receive a request from a computer (for example, the user terminal 50 or the cooperation server 70) to an API endpoint common to multiple tenants, the request including tenant identification information indicating one of the multiple tenants. The API endpoint is the final point in the API connection on the groupware "XXX groupware" side.

[0132] As in the embodiment, the computer that sends the request may be any computer. The receiving unit 201 of the sixth modification may receive a request from a computer other than the user terminal 50 and the cooperation server 70. The computer that sends the request may perform predetermined authentication (e.g., OAuth authentication) in advance. In this case, the computer may store information indicating that the predetermined authentication has been performed (e.g., a client ID in OAuth authentication). When making a request, the validity of the information may be confirmed.

[0133] In the example of FIG. 10, a request to an API endpoint is identified by the subdomain "api" and the domain "xxx-gate.com." However, since the load balancer 20 cannot identify the regional system 30 to be accessed (i.e., which tenant's data is being requested to be accessed) based on this information alone, the request in Modification 6 includes tenant identification information. When a request to a common API endpoint is accepted, the identification unit 202 in Modification 6 identifies the regional system to be accessed based on the tenant identification information. Note that a subdomain may be used as the tenant identification information instead of the ID shown in FIG. 10.

[0134] For example, the identification unit 202 of Modification 6 acquires regional system identification information associated with tenant identification information included in the request based on the domain map M. When the domain map M is managed by the management server 10 as in the embodiment, the identification unit 202 requests the management server 10 for regional system identification information associated with the tenant identification information included in the request. The management server 10 refers to the domain map M and transmits the regional system identification information associated with the tenant identification information to the load balancer 20.

[0135] For example, the identifying unit 202 identifies the destination regional system based on the transmitted regional system identification information. Note that when a subdomain is used as the tenant identification information, the identifying unit 202 of the sixth modified example may acquire the address of the destination regional system based on a request including an address acquired by the user terminal 50 from the domain name system 40, as in the embodiment. Furthermore, when the load balancer 20 stores a database similar to the domain map M or the address database DB, the identifying unit 202 may identify the destination regional system without querying an external computer.

[0136] The access control unit 203 of the sixth modification causes the computer that sent the request to access the destination regional system identified by the identification unit 202. The control of the access control unit 203 is generally as described in the embodiment, but if the computer that sent the request is the destination server 70, the access control unit 203 sends data managed by the regional system 30 to the destination server 70. The destination server 70 receives the data and displays the data managed by "XXX groupware" on the page of "ZZZ groupware." The data managed by "XXX groupware" can be displayed on the page of "ZZZ groupware" under the control of the computer that sent the request.

[0137] Although the sixth modification has been described as an example of a case where multiple groupwares are linked to each other, the API flow of the sixth modification may be used in various other situations. For example, when the groupware "XXX groupware" is linked to a data management service or a shared email service that is not groupware, the services may be linked using a similar API flow.

[0138] The multi-tenant system 1 of the sixth modification accepts from a computer a request to an API endpoint common to multiple tenants, the request including tenant identification information indicating one of the multiple tenants. When a request to the common API endpoint is accepted, the multi-tenant system 1 identifies the regional system to be accessed based on the tenant identification information. The multi-tenant system 1 can appropriately execute access control via the API endpoint. For example, this enables multiple groupware to work together.

[0139] [6-7. Other variations] For example, the above modifications may be combined.

[0140] For example, in the embodiment, the user terminal 50 acquires the address of the destination regional system from the domain name system 40 before sending a request to the load balancer 20, but the load balancer 20 may acquire the address of the destination regional system from a domain map within the system. In this case, the user terminal 50 does not need to acquire the address of the destination regional system from the domain name system 40 in advance. Alternatively, for example, the load balancer 20 may acquire the address of the destination regional system by referring to an address database stored therein.

[0141] For example, some of the functions described as being realized by the load balancer 20 may be realized by another computer such as the management server 10. The functions described as being realized by the load balancer 20 may be shared among multiple computers. [Explanation of symbols]

[0142] 1 multi-tenant system, 10 management server, 11, 21, 31, 41, 51, 61, 71 control unit, 12, 22, 32, 42, 52, 62, 72 memory unit, 13, 23, 33, 43, 53, 63, 73 communication unit, 20 load balancer, 30 regional system, 40 domain name system, 50 user terminal, 54 operation unit, 55 display unit, 60 Login server, 70 linked servers, N network, M domain map, DB Address database, P page, 100,200,300,400,500,600 data storage unit, 101 relationship reflection unit, 102 subdomain change unit, 201 reception unit, 202 identification unit, 203 access control unit, 204 storage unit, 205,301,401,501 transmission unit, 302,402,502 reception unit, 503 session management unit, 601 login execution unit.

Claims

[Claim 1] A multi-tenant system in which data of each of a plurality of tenants is managed in a regional system in one of a plurality of regions, and a subdomain is assigned to each of the plurality of tenants, a reception unit that receives a request including the subdomain assigned to any one of the plurality of tenants from a computer; an identification unit that, when the request is accepted, identifies the destination regional system, which is the regional system, and manages the data of the tenant to which the subdomain included in the request is assigned; an access control unit that causes the computer to access the destination regional system; Multi-tenant systems, including:

Images