JP5773910B2 - Access control apparatus, access control method and program - Google Patents

Description

  The present invention relates to an access control device, an access control method, and a program. The present invention particularly relates to a multi-tenant compatible access control apparatus, method, and program.

  With the spread of cloud services, service forms of “multi-tenant” type applications in which a single application is shared by a plurality of companies (tenants) are becoming widespread.

  “Multi-tenant” refers to a form in which hardware and software can be shared by multiple companies. The key to providing cloud services is how to provide services at low prices. When providing the same service to multiple companies, it is possible to reduce software and hardware resources by applying “multi-tenant technology” that provides the same application to multiple companies. Provision becomes possible.

  When migrating from single-tenant type to multi-tenant type applications, multiple tenants share computer resources (PC (personal computer) server, hard disk, APP (application) server software, DBMS (database management system), etc.)) There is a need to. At this time, it is necessary to identify the tenant on the application or database side and realize data access for each tenant. When renovating an existing single tenant type application, it is necessary to modify the structure of the application or database, so that the renovation cost may generally be enormous. Therefore, there is a need for a framework that can be multi-tenant while diverting existing applications as much as possible.

  In the prior art, when data is read from a multi-tenant compatible database using an existing application, information for identifying a tenant such as a tenant ID (identifier), owner ID, and organization name is acquired from the session information, and the acquired information Based on the table, the table corresponding to the tenant is specified, or the data to be read is narrowed down to the data related to the tenant (see, for example, Patent Documents 1 to 3).

JP 2010-26653 A JP 2011-60174 A JP 2011-113103 A

In a multi-tenant application, a database separation model is defined as follows according to the data separation level.
(1) Table sharing type: Information of a plurality of tenants is mixed in one table.
(2) Schema separation type: A dedicated schema is prepared for each tenant.
(3) Instance separation type: A dedicated database instance is generated for each tenant.

  In the conventional technology, only the table sharing model or the schema separation model is targeted, and the model is switched according to various needs of users such as “I want to increase the degree of aggregation” or “I want to use my own schema”. There was a problem that it was impossible to realize a simple method.

  An object of the present invention is, for example, to switch the type of database in accordance with the needs of a tenant when controlling access from an existing application to a multi-tenant compatible database.

An access control apparatus according to one aspect of the present invention provides:
An access control device for controlling access to at least two types of multi-tenant-compatible databases that store individual data of each of the plurality of tenants from an application shared by a plurality of tenants to which at least one user belongs. And
For each tenant, a multi-tenant management database that pre-stores a tenant identifier that uniquely identifies a tenant and the type of database to be accessed by a storage device;
When input to the application, the input of parameters that the application outputs when accessing the at least two types of databases is accepted from a user belonging to one of the tenants by the input device, and the tenant of the tenant to which the user belongs An identifier is read from the multi-tenant management database, embedded in the parameter, and a user interface connection unit that inputs the parameter to the application;
When the parameter input by the user interface connection unit is output from the application, the tenant identifier embedded in the parameter is extracted, and the tenant database type corresponding to the extracted tenant identifier is extracted from the multi-tenant management database. And a database connection unit that causes the application to access individual data of the tenant stored in the read type database among the at least two types of databases.

  In one aspect of the present invention, the user interface connection unit of the access control device embeds the tenant identifier of the tenant to which the user belongs in a parameter, and inputs the parameter to the application. When the parameter input by the user interface connection unit is output from the application, the database connection unit of the access control device extracts the tenant identifier embedded in the parameter and sets it as the access target of the tenant corresponding to the extracted tenant identifier. The application is made to access the individual data of the tenant stored in the determined type of database. Therefore, according to one aspect of the present invention, when controlling access from an existing application to a multi-tenant compatible database, the type of database can be switched in accordance with the tenant's needs and the like.

FIG. 2 is a block diagram showing a configuration of an access control apparatus according to the first embodiment. 2 is a diagram illustrating an example of a hardware configuration of an access control apparatus according to Embodiment 1. FIG. The figure which shows the example of a structure of the tenant management table of the multi-tenant management database which concerns on Embodiment 1, a tenant information joint setting table, and a database connection setting table. FIG. 3 is a diagram showing a configuration example of a table sharing database according to the first embodiment. FIG. 3 is a diagram illustrating a configuration example of a schema separation type database according to the first embodiment. FIG. 3 is a diagram illustrating a configuration example of an instance separation type database according to the first embodiment. FIG. 3 is a sequence diagram showing an operation of the access control apparatus according to the first embodiment. FIG. 3 is a sequence diagram showing an operation of the access control apparatus according to the first embodiment. FIG. 3 is a sequence diagram showing an operation of the access control apparatus according to the first embodiment. FIG. 3 is a sequence diagram showing an operation of the access control apparatus according to the first embodiment. FIG. 3 is a sequence diagram showing an operation of the access control apparatus according to the first embodiment. FIG. 10 is a sequence diagram showing an operation of the access control apparatus according to the second embodiment. FIG. 4 is a block diagram showing a configuration of an access control apparatus according to a third embodiment. The figure which shows the structural example of the database connection setting table of the multi-tenant management database concerning Embodiment 3. FIG. FIG. 10 is a sequence diagram showing an operation of the access control apparatus according to the third embodiment. FIG. 10 is a diagram illustrating an operation example of a data check unit according to the third embodiment.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

Embodiment 1 FIG.
FIG. 1 is a block diagram showing a configuration of access control apparatus 100 according to the present embodiment.

  In FIG. 1, the access control apparatus 100 includes a multi-tenant database 400 (multi-tenant) that centrally manages information on a plurality of tenants from an existing application 500 (non-tenant-compatible application) used in a single tenant. Control access to supported databases).

  The existing application 500 is an example of an application shared by a plurality of tenants. It is assumed that at least one user belongs to each tenant. In the present embodiment, the existing application 500 provides various services (for example, web services) by communicating with the client system 101 used by users of the tenant A, tenant B, tenant C, and tenant D. The client system 101 is installed for each tenant. The number of tenants is not limited to four, and may be two, three, or five or more. In this embodiment, the existing application 500 further provides a maintenance management service by communicating with the client system 102 used by the system administrator.

  The multi-tenant database 400 is an example of at least two types of databases that store individual data of a plurality of tenants. In the present embodiment, the multi-tenant database 400 is configured by combining three types of databases: a table sharing database 410, a schema separation database 420, and an instance separation database 430. That is, the multi-tenant database 400 is three types of databases having different configurations for multi-tenancy. The multi-tenant database 400 may be configured with only two types of databases among the table sharing type database 410, the schema separation type database 420, and the instance separation type database 430, or other types of databases may be used. It may be composed of four or more types of databases.

  The access control apparatus 100 manages information necessary for operating a multi-tenant application platform 200 for making the existing application 500 multi-tenant and a multi-tenant application (a combination of the multi-tenant application platform 200 and the existing application 500). A multi-tenant management database 300.

  The multi-tenant application platform 200 includes a UI (user interface) connection unit 210, a multi-tenant control unit 220, a connection holding unit 230, and a DB (database) connection unit 240.

  The UI connection unit 210 receives a service request from the client system 101, and performs processing for embedding the tenant ID of the tenant in which the client system 101 is installed in an existing parameter. The tenant ID is a tenant identifier that uniquely identifies a tenant. The existing parameter is a parameter output when the existing application 500 accesses the multi-tenant database 400 when input to the existing application 500.

  The multi-tenant control unit 220 manages tenants such as tenant registration / deletion.

  The connection holding unit 230 manages a connection when accessing the multi-tenant database 400 from the multi-tenant application.

  The DB connection unit 240 controls access from the multi-tenant application to the multi-tenant database 400. The DB connection unit 240 includes a tenant separation unit 241, a model switching unit 242, a table sharing type connection unit 243, a schema separation type connection unit 244, and an instance separation type connection unit 245. The tenant separation unit 241 acquires the tenant ID from the existing parameters. The model switching unit 242 switches the database to be accessed for each tenant. The table sharing type connection unit 243 realizes access to the table sharing type database 410. The schema separation type connection unit 244 realizes access to the schema separation type database 420. The instance separation type connection unit 245 realizes access to the instance separation type database 430.

  The multi-tenant management database 300 includes a tenant management table 310, a tenant information combination setting table 320, and a database connection setting table 330. The tenant management table 310 manages information on tenants that use the multi-tenant application. The tenant information combination setting table 320 manages rules for transferring the tenant ID to the existing application 500. The database connection setting table 330 manages connection information to the database for each tenant.

  Although not shown in FIG. 1, the access control device 100 includes hardware such as a processing device, a storage device, an input device, and an output device. Hardware is used by each unit of the access control apparatus 100. For example, the processing device is used to perform calculation, processing, reading, writing, and the like of data and information in each unit of the access control device 100. The storage device is used to store the data and information. The input device is used for inputting the data and information, and the output device is used for outputting the data and information.

  FIG. 2 is a diagram illustrating an example of a hardware configuration of the access control apparatus 100.

  In FIG. 2, an access control apparatus 100 is a computer, and includes an LCD 901 (Liquid / Crystal / Display), a keyboard 902 (K / B), a mouse 903, an FDD 904 (Flexible / Disk / Drive), and a CDD 905 (Compact / Disc / Drive). ) And a hardware device such as a printer 906. These hardware devices are connected by cables and signal lines. Instead of the LCD 901, a CRT (Cathode / Ray / Tube) or other display device may be used. Instead of the mouse 903, a touch panel, a touch pad, a trackball, a pen tablet, or other pointing devices may be used.

  The access control apparatus 100 includes a CPU 911 (Central Processing Unit) that executes a program. The CPU 911 is an example of a processing device. The CPU 911 includes a ROM 913 (Read / Only / Memory), a RAM 914 (Random / Access / Memory), a communication board 915, an LCD 901, a keyboard 902, a mouse 903, an FDD 904, a CDD 905, a printer 906, and an HDD 920 (Hard / Disk) via a bus 912. Connected with Drive) to control these hardware devices. Instead of the HDD 920, a flash memory, an optical disk device, a memory card reader / writer, or other recording medium may be used.

  The RAM 914 is an example of a volatile memory. The ROM 913, the FDD 904, the CDD 905, and the HDD 920 are examples of nonvolatile memories. These are examples of the storage device. The communication board 915, the keyboard 902, the mouse 903, the FDD 904, and the CDD 905 are examples of input devices. The communication board 915, the LCD 901, and the printer 906 are examples of output devices.

  The communication board 915 is connected to a LAN (Local / Area / Network) or the like. The communication board 915 is not limited to a LAN, but is an IP-VPN (Internet, Protocol, Private, Network), a wide area LAN, an ATM (Asynchronous / Transfer / Mode) network, a WAN (Wide / Area / Network), or the Internet. It does not matter if it is connected to. LAN, WAN, and the Internet are examples of networks.

  The HDD 920 stores an operating system 921 (OS), a window system 922, a program group 923, and a file group 924. The programs in the program group 923 are executed by the CPU 911, the operating system 921, and the window system 922. The program group 923 includes programs that execute the functions described as “˜units” in the description of the present embodiment. The program is read and executed by the CPU 911. The file group 924 includes data, information, and signal values described as “˜data”, “˜information”, “˜ID (identifier)”, “˜flag”, and “˜result” in the description of this embodiment. And variable values and parameters are included as items of “˜file”, “˜database”, and “˜table”. The “˜file”, “˜database”, and “˜table” are stored in a recording medium such as the RAM 914 or the HDD 920. Data, information, signal values, variable values, and parameters stored in a recording medium such as the RAM 914 and the HDD 920 are read out to the main memory and the cache memory by the CPU 911 via a read / write circuit, and extracted, searched, referenced, compared, and calculated. It is used for processing (operation) of the CPU 911 such as calculation, control, output, printing, and display. During the processing of the CPU 911 such as extraction, search, reference, comparison, calculation, calculation, control, output, printing, and display, data, information, signal values, variable values, and parameters are temporarily stored in the main memory, cache memory, and buffer memory. Remembered.

  The arrows in the block diagrams and flowcharts used in the description of this embodiment mainly indicate input / output of data and signals. Data and signals are recorded in memory such as RAM 914, FDD904 flexible disk (FD), CDD905 compact disk (CD), HDD920 magnetic disk, optical disk, DVD (Digital Versatile Disc), or other recording media Is done. Data and signals are transmitted by a bus 912, a signal line, a cable, or other transmission media.

  In the description of the present embodiment, what is described as “to part” may be “to circuit”, “to device”, “to device”, and “to step”, “to process”, “to”. ~ Procedure "," ~ process ". That is, what is described as “˜unit” may be realized by firmware stored in the ROM 913. Alternatively, what is described as “˜unit” may be realized only by software, or only by hardware such as an element, a device, a board, and wiring. Alternatively, what is described as “to part” may be realized by a combination of software and hardware, or a combination of software, hardware and firmware. Firmware and software are stored as programs in a recording medium such as a flexible disk, a compact disk, a magnetic disk, an optical disk, and a DVD. The program is read by the CPU 911 and executed by the CPU 911. That is, the program causes the computer to function as “to part” described in the description of the present embodiment. Or a program makes a computer perform the procedure and method of "-part" described by description of this Embodiment.

  FIG. 3 is a diagram illustrating a configuration example of the tenant management table 310, the tenant information combination setting table 320, and the database connection setting table 330 of the multi-tenant management database 300.

  In FIG. 3, the tenant management table 310 includes columns of tenant ID and tenant name. For example, the tenant management table 310 stores the tenant name “tenant A” in association with the tenant ID “A”.

  The tenant information combination setting table 320 includes a combination source parameter, a combination destination parameter, and a separator column. The combination destination parameter indicates an existing parameter that is a target for embedding the tenant ID by the UI connection unit 210. The combination source parameter and the separator indicate the format of the existing parameter after the tenant ID is embedded. In this example, the tenant information combination setting table 320 stores a combination source parameter “user ID, tenant ID”, a combination destination parameter “user ID”, and a separator “-”. The user ID is a user identifier that uniquely identifies the user. For example, when the user of the tenant A tries to input the user ID “USER01” to the existing application 500, the user ID is converted to “A--USER01” by the UI connection unit 210 and then input to the existing application 500. Become. Note that, as a combination destination parameter, not only the user ID but also other existing parameters such as a user name, a service reception number, and an organization ID described later may be used. Regarding the coupling source parameter and the separator, the above-described ones are merely examples, and various changes can be made.

  The database connection setting table 330 includes columns of tenant ID, connection destination DB model, pool ID, and DB check information. The connection destination DB model indicates the type of database determined as the access target of the tenant. The pool ID indicates a connection identifier for uniquely identifying a database connection pool (connection with a database). When the connection destination DB model is the table sharing database 410, a common connection pool is assigned to each tenant. When the connection destination DB model is the schema separation type database 420 or the instance separation type database 430, a separate connection pool is assigned to each tenant. The DB check information indicates conditions set for data stored in a specific table. This condition is set only when the connection destination DB model is the table sharing database 410. The DB check information is not used in the present embodiment. The database connection setting table 330 is associated with the tenant ID “A”, for example, the connection destination DB model “table shared type” (showing the table shared type database 410), and pool ID “poolCommon” (showing a common connection pool). ) Is stored.

  As described above, in the present embodiment, the multi-tenant management database 300 stores at least a tenant ID and a database type (indicated by a connection destination DB model and a pool ID) in advance by a storage device for each tenant.

  FIG. 4 is a diagram illustrating a configuration example of the table sharing database 410.

  In FIG. 4, the table sharing database 410 is an example of a first type database that performs multi-tenant correspondence by storing individual data of a plurality of tenants in a common table including a column of tenant IDs. The table sharing database 410 includes a personal information table (user list), an organization information table (organization list), an assignment information table (assignment list), and an authentication information table (password list) as tables common to the tenants.

  The personal information table (user list) includes columns of tenant ID, user ID, and user name. In this example, the user ID uniquely identifies the user among all tenants (as in a single tenant application), but it is sufficient that the user can be uniquely identified only within the tenant to which the user belongs. For example, the personal information table (user list) stores a user ID “USER01” and a user name “user 1” in association with the tenant ID “A”.

  The organization information table (organization list) includes columns of tenant ID, organization ID, and organization name. The organization ID is an organization identifier that uniquely identifies a tenant's organization (department or the like). The organization information table (organization list) stores, for example, the organization ID “ORG1” and the organization name “organization 1” in association with the tenant ID “A”.

  The assignment information table (assignment list) includes columns of tenant ID, assignment ID, user ID, and organization ID. The assignment ID is an assignment identifier that uniquely identifies the association (that is, assignment) between the user and the organization. The assignment information table (assignment list) stores, for example, an assignment ID “1”, a user ID “USER01”, and an organization ID “ORG1” in association with the tenant ID “A”.

  The authentication information table (password list) includes tenant ID, user ID, and password columns. The authentication information table (password list) stores, for example, a user ID “USER01” and a password “xxxxxxxx” in association with the tenant ID “A”.

  FIG. 5 is a diagram illustrating a configuration example of the schema separation type database 420.

  In FIG. 5, the schema separation type database 420 is an example of a second type database that performs multi-tenant correspondence by storing individual tenant data in individual tables for each tenant. The schema separation type database 420 includes a personal information table (tenant A_user list, tenant B_user list), an organization information table (tenant A_organization list, tenant B_organization list), and an assignment information table (tenant) as individual tables for each tenant. A_assignment list, tenant B_assignment list). Although not shown, the schema separation type database 420 also has an authentication information table (tenant A_password list, tenant B_password list).

  Personal information table (tenant A_user list, tenant B_user list), organization information table (tenant A_organization list, tenant B_organization list), assignment information table (tenant A_assignment list, tenant B_assignment list), authentication information table (tenant) Each table of (A_password list, tenant B_password list) includes a tenant name (may be a tenant ID) in the table name instead of including a tenant ID column. The columns included in each table are the same as those in the table sharing database 410 shown in FIG.

  FIG. 6 is a diagram illustrating a configuration example of the instance separation type database 430.

  In FIG. 6, the instance separation type database 430 is an example of a third type database that performs multi-tenant correspondence because there is an individual database instance that stores individual data of each tenant for each tenant. The tenant A instance and the tenant B instance of the instance separation type database 430 have a personal information table (user list), an organization information table (organization list), and an assignment information table (assignment list), respectively. Although not shown, each of the tenant A instance and the tenant B instance also has an authentication information table (password list).

  Each table of personal information table (user list), organization information table (organization list), assignment information table (assignment list), and authentication information table (password list) includes a column of tenant ID, or a tenant name in the table name. Instead of including, database instance is divided for each tenant. The columns included in each table are the same as those in the table sharing database 410 shown in FIG.

  Hereinafter, the operation of the access control apparatus 100 when a service request is transmitted from the client system 101 of the tenant A (the access control method according to the present embodiment, the present embodiment will be described with reference to FIGS. 7 to 9). The processing procedure of the program will be described.

  FIG. 7 is a sequence diagram showing a flow of combining and separating tenant IDs with respect to existing parameters in order to use the existing application 500 without making the existing application 500 aware of the tenant ID.

  In S <b> 101, the client system 101 of the tenant A issues a login request to the UI connection unit 210. At this time, the client system 101 transmits a tenant ID, a user ID, and a password to the UI connection unit 210. The UI connection unit 210 receives the tenant ID, user ID, and password by the input device.

  In S102, the UI connection unit 210 sends the tenant ID to the multi-tenant control unit 220 in order to obtain information on whether the received tenant ID is correct and how the tenant ID is embedded in the existing parameter (combination rule). An ID confirmation notification and a tenant information combination information acquisition request are issued.

  In S103, the multi-tenant control unit 220 inquires of the multi-tenant management database 300 whether the tenant ID received from the UI connection unit 210 is included in the tenant management table 310. Also inquires about the combination rule of the tenant information combination setting table 320.

  In S104, the multi-tenant management database 300 searches the tenant management table 310 and the tenant information combination setting table 320 in response to the inquiry from the multi-tenant control unit 220, and returns the result.

  In S <b> 105, the multi-tenant control unit 220 returns a search result to the UI connection unit 210.

  In S <b> 106, the UI connection unit 210 embeds a tenant ID in the existing parameter by the processing device based on the combination rule acquired via the multi-tenant control unit 220. In this example, as illustrated in FIG. 3, it is assumed that a combination source parameter “user ID, tenant ID”, a combination destination parameter “user ID”, and a separator “-” are set as a combination rule. Therefore, when the tenant ID is “A” and the user ID is “USER01”, the existing parameter user ID is “A--USER01”. After embedding the tenant ID, the UI connection unit 210 transmits a request to the existing application 500 with the user ID set to “A--USER01”.

  In S107, the existing application 500 performs the same processing as in the case of a single tenant. Specifically, the existing application 500 issues a query (first query) to the multi-tenant database 400.

  In S <b> 108, the existing application 500 issues a database connection request to the tenant separation unit 241 of the DB connection unit 240. The database connection request includes a user ID as a parameter.

  In S109, the tenant separation unit 241 sends a tenant information combination information acquisition request to the multi-tenant control unit 220 in order to acquire information for extracting the tenant ID from the parameters of the database connection request received from the existing application 500. put out.

  In S110, the multi-tenant control unit 220 inquires of the multi-tenant management database 300 about a combination rule based on the tenant information combination information acquisition request received from the tenant separation unit 241.

  In S111, the multi-tenant management database 300 searches the tenant information combination setting table 320 in response to the inquiry from the multi-tenant control unit 220, and returns the result.

  In S112, the multi-tenant control unit 220 returns a search result to the tenant separation unit 241.

  In S113, the tenant separation unit 241 acquires the tenant ID from the existing parameters by the processing device based on the combination rule. In this example, the tenant ID is acquired from the user ID.

  In S114, the tenant separation unit 241 passes the database connection request received from the existing application 500 to the model switching unit 242 of the DB connection unit 240 with the tenant ID assigned. The model switching unit 242 receives a database connection request.

  As described above, in the present embodiment, the UI connection unit 210 receives an input of an existing parameter from a user belonging to one of a plurality of tenants using an input device. The UI connection unit 210 reads the tenant ID of the tenant to which the user belongs from the multi-tenant management database 300 and embeds the tenant ID in the existing parameter input by the user by the processing device. Then, the UI connection unit 210 inputs the existing parameter in which the tenant ID is embedded into the existing application 500. In this example, the UI connection unit 210 receives an input of the user ID of the user as an existing parameter from the user, and connects the tenant ID of the tenant to which the user belongs to the user ID input by the user. Thus, the tenant ID is embedded in the existing parameter.

  Further, in this embodiment, when the existing parameter input by the UI connection unit 210 is output from the existing application 500, the DB connection unit 240 uses the processing device to input the tenant ID embedded in the output existing parameter. Take out.

  FIG. 8 is a sequence diagram showing a flow of access to the table sharing database 410.

  In S201, the model switching unit 242 acquires the tenant ID from the received database connection request and notifies the multi-tenant control unit 220 of the acquired tenant ID in order to acquire information on how to access the database.

  In S202, the multi-tenant control unit 220 inquires of the multi-tenant management database 300 how the tenant with the notified tenant ID accesses the database.

  In S203, the multi-tenant management database 300 searches the database connection setting table 330 in response to the inquiry from the multi-tenant control unit 220, and returns the result. This result includes the pool ID.

  In S204, the multi-tenant control unit 220 requests the connection holding unit 230 to acquire a connection pool based on the pool ID acquired from the multi-tenant management database 300. At this time, the multi-tenant control unit 220 transmits the pool ID to the connection holding unit 230.

  In S205, the connection holding unit 230 returns the connection pool of the received pool ID.

  In S206, the multi-tenant control unit 220 returns the connection pool of the database used by the tenant with the tenant ID received from the model switching unit 242 to the model switching unit 242.

  In S207, the model switching unit 242 switches the connection destination based on the connection pool (connection destination information) received from the multi-tenant control unit 220. In this example, as shown in FIG. 3, it is assumed that the table sharing database 410 is set as the connection destination DB model of the tenant A. Therefore, the model switching unit 242 connects to the table sharing type connection unit 243.

  In S208, the table sharing type connection unit 243 connects to the table sharing type database 410 of the multi-tenant database 400 using the connection pool acquired from the connection holding unit 230, and issues a search request. Specifically, the table sharing type connection unit 243 adds the tenant ID of the table to be accessed and the tenant ID acquired by the model switching unit 242 to the query issued by the existing application 500 (for example, the SQL SELECT statement). Is added as a condition (for example, a WHERE clause), and the query is issued to the table sharing database 410.

  In S209, the table sharing type database 410 returns the search result (specifically, the result of the query) to the table sharing type connection unit 243.

  In S210, the table sharing type connection unit 243 returns the search result returned from the table sharing type database 410 to the model switching unit 242. The model switching unit 242 receives the search result.

  As described above, in this embodiment, the DB connection unit 240 extracts the tenant ID embedded in the existing parameter output from the existing application 500, and then the type of the tenant database corresponding to the extracted tenant ID. Are read from the multi-tenant management database 300. Then, the DB connection unit 240 causes the existing application 500 to access individual data of the tenant stored in the read type database among the three types of databases constituting the multi-tenant database 400.

  FIG. 9 is a sequence diagram showing a flow of processing for returning the search result of the multi-tenant database 400 to the client system 101.

  In S301, the model switching unit 242 passes the received search result of the multi-tenant database 400 to the tenant separation unit 241.

  In S <b> 302, the tenant separation unit 241 passes the search result of the multi-tenant database 400 acquired from the model switching unit 242 to the existing application 500.

  In S303, the existing application 500 performs the same processing as in the case of a single tenant based on the received search result of the multi-tenant database 400. Specifically, the existing application 500 executes a predetermined process (for example, a process for a web service) based on a query result for the multi-tenant database 400.

  In S <b> 304, the existing application 500 returns the execution result of the processing to the UI connection unit 210.

  In step S <b> 305, the UI connection unit 210 returns the processing execution result to the client system 101 of the tenant A.

  With the operation described above, the service is provided from the multi-tenant application to the user of the tenant A. When a service request is transmitted from the client system 101 of the tenant B, the service is provided from the multi-tenant application to the user of the tenant B by the same operation.

  Hereinafter, the operation of the access control apparatus 100 when a service request is transmitted from the client system 101 of the tenant C (the access control method according to the present embodiment, the program according to the present embodiment, and the like) will be described with reference to FIG. Processing procedure) will be described.

  In order to use the existing application 500 without making the existing application 500 aware of the tenant ID, the flow of combining and separating the tenant ID with respect to the existing parameter is the same as that shown in FIG.

  FIG. 10 is a sequence diagram showing a flow of access to the schema separation type database 420.

  The processing of S401 to S406 is the same as the processing of S201 to S206 shown in FIG.

  In S407, the model switching unit 242 switches the connection destination based on the connection pool (connection destination information) received from the multi-tenant control unit 220. In this example, as shown in FIG. 3, it is assumed that a schema separation type database 420 is set as a connection destination DB model of the tenant C. Therefore, the model switching unit 242 is connected to the schema separation type connection unit 244.

  In step S <b> 408, the schema separation type connection unit 244 connects to the schema separation type database 420 of the multi-tenant database 400 using the connection pool acquired from the connection holding unit 230 and issues a search request. Specifically, the schema separation type connection unit 244 displays the tenant acquired by the model switching unit 242 in the table name of the table specified as the access target in the query (for example, the SQL SELECT statement) issued by the existing application 500. After adding (concatenating) a tenant name (may be the tenant ID itself) corresponding to the ID in a predetermined format, the query is issued to the schema separation type database 420.

  In S209, the schema separation type database 420 returns the search result (specifically, the result of the query) to the schema separation type connection unit 244.

  In S 210, the schema separation type connection unit 244 returns the search result returned from the schema separation type database 420 to the model switching unit 242. The model switching unit 242 receives the search result.

  The flow of processing for returning the search result of the multi-tenant database 400 to the client system 101 is the same as that shown in FIG.

  Hereinafter, the operation of the access control apparatus 100 when a service request is transmitted from the client system 101 of the tenant D (the access control method according to the present embodiment, the program according to the present embodiment, and the like) will be described with reference to FIG. Processing procedure) will be described.

  In order to use the existing application 500 without making the existing application 500 aware of the tenant ID, the flow of combining and separating the tenant ID with respect to the existing parameter is the same as that shown in FIG.

  FIG. 11 is a sequence diagram showing a flow of access to the instance separation type database 430.

  The processing of S501 to S506 is the same as the processing of S201 to S206 shown in FIG.

  In S507, the model switching unit 242 switches the connection destination based on the connection pool (connection destination information) received from the multi-tenant control unit 220. In this example, as illustrated in FIG. 3, it is assumed that the instance separation type database 430 is set as the connection destination DB model of the tenant D. Therefore, the model switching unit 242 is connected to the instance separation type connection unit 245.

  In S508, the instance separation type connection unit 245 connects to the instance separation type database 430 of the multi-tenant database 400 using the connection pool acquired from the connection holding unit 230, and issues a search request. Specifically, the instance separation type connection unit 245 issues a query (for example, a SQL SELECT statement) issued by the existing application 500 to the instance for the tenant A in the instance separation type database 430.

  In S509, the instance separation type database 430 returns the search result (specifically, the result of the query) to the instance separation type connection unit 245.

  In S510, the instance separation type connection unit 245 returns the search result returned from the instance separation type database 430 to the model switching unit 242. The model switching unit 242 receives the search result.

  The flow of processing for returning the search result of the multi-tenant database 400 to the client system 101 is the same as that shown in FIG.

  As described above, in the present embodiment, in order to make a multi-tenant in a state where the existing application 500 is diverted as much as possible, tenant IDs (identifiers that are uniquely allocated for each tenant) in the interface part before and after the existing application 500 are used. ) Is embedded / removed.

  The existing application 500 that does not support multi-tenant cannot handle the tenant ID. Therefore, the tenant ID is combined with the parameter (for example, user ID) used in the existing application 500. For example, a user whose tenant ID is “A” and whose user ID is “USER01” in the combination rule set as a combination source parameter “user ID, tenant ID”, combination destination parameter “user ID”, separator “-” In this case, the user ID of the existing parameter is “A--USER01”. At this time, the combination rule is not fixed, but can be set flexibly. For example, when the number of characters of the user ID of the existing application 500 is limited, the parameter of the user name can be set as the combination destination. It becomes. Further, even when there are a plurality of existing applications 500 to be multi-tenanted and the parameters used by the existing applications 500 are different, it is possible to cope by setting a rule for each existing application 500.

  The access control apparatus 100 according to the present embodiment includes software for realizing a multi-tenant application and hardware for storing and executing the software, and includes a UI connection unit 210, a DB connection unit 240, and a tenant information combination setting table 320. Prepare. The UI connection unit 210 embeds the tenant ID of the tenant to which the user belongs in the parameter used in the existing application 500 based on the tenant information combination setting. The DB connection unit 240 extracts the tenant ID necessary for accessing the database from the parameters based on the tenant information combination setting. The tenant information combination setting table 320 manages parameters for embedding a tenant ID and conditions for embedding as tenant information combination settings.

  In the prior art, when data is read from the database using the existing application 500, the tenant ID or the like is acquired from the session information. Therefore, there is a possibility that the association between the data and the tenant ID through the existing application 500 may not be successful. If the session ID cannot be acquired between the existing application 500 and the database, the tenant ID cannot be acquired. On the other hand, in this embodiment, even if the session information (session ID) is not passed from the UI connection unit 210 to the DB connection unit 240, the existing application 500 does not need to be aware of the tenant ID, and the DB connection The tenant ID can be acquired by the unit 240.

  In this embodiment, a multi-tenant database 400 in which a table sharing type, a schema separation type, and an instance separation type are mixed is used as a database model.

  Database models having information on multiple tenants are classified into a table sharing type, a schema separation type, and an instance separation type depending on the structure of the database table and the structure of the instance. When converting an existing application 500 into a multi-tenant, the format of the database used by each of the multiple tenants is likely to differ depending on the tenant. If there is one model that can be handled, it will take time to migrate the database. . Also, it is not possible to realize a method of switching models according to various needs of users such as “I want to increase the degree of aggregation” and “I want to use a unique schema”. In contrast, in this embodiment, the database connection setting table 330 manages what database model is used for each tenant, and switches the model when connecting to the multi-tenant database 400. When switching models, prepare a connection pool that holds connections to databases that can be used for each tenant in advance. When connecting to the multi-tenant database 400, select the connection assigned to the tenant to switch the model. It becomes possible.

Embodiment 2. FIG.
In the present embodiment, differences from the first embodiment will be mainly described.

  The configuration of access control apparatus 100 according to the present embodiment is the same as that of the first embodiment shown in FIG.

  Hereinafter, with reference to FIG. 12, the operation of the access control apparatus 100 when adding a tenant that uses a multi-tenant application (the access control method according to the present embodiment, the processing procedure of the program according to the present embodiment) explain.

  FIG. 12 is a sequence diagram showing a flow of processing for newly adding a tenant from the client system 102 of the system administrator.

  In step S <b> 601, the system administrator's client system 102 issues a tenant registration request to the multi-tenant control unit 220. At this time, the multi-tenant control unit 220 is notified of the tenant name and the database model used by the tenant.

  In S602, the multi-tenant control unit 220 requests the multi-tenant management database 300 to register a tenant name in the tenant management table 310 and issue a tenant ID.

  In S603, the multi-tenant management database 300 registers the tenant and returns the issued tenant ID.

  In S604, the multi-tenant control unit 220 requests the connection holding unit 230 to issue the added tenant connection pool.

  In S605, the connection holding unit 230 generates a connection pool for a new tenant and returns a pool ID. However, when the database model used by the tenant is the table shared database 410, the connection holding unit 230 does not generate a new connection pool, but returns a pool ID corresponding to the common connection pool of the table shared database 410. .

  In step S <b> 606, the multi-tenant control unit 220 requests the multi-tenant management database 300 to update the database connection setting table 330 to add the tenant ID, connection destination DB model, and pool ID of the new tenant.

  In S607, the multi-tenant management database 300 updates the database connection setting table 330 and returns the result.

  In S608, the multi-tenant control unit 220 requests the multi-tenant database 400 to add a data area for a new tenant.

  In S609, the multi-tenant database 400 adds a new tenant data area and notifies the multi-tenant control unit 220 of success or failure.

  In S610, the multi-tenant control unit 220 notifies the client system 102 of the system administrator of the success or failure of registration.

  With the above operation, it becomes possible to immediately release the use of the application to a new tenant who wants to use the multi-tenant application.

  As described above, in this embodiment, when a tenant who has not used a multi-tenant application desires to use a multi-tenant service, the tenant can be added without renovation of the existing application 500. Is possible. Therefore, in this embodiment, when a system administrator of a multi-tenant application registers a tenant with a management application, the multi-tenant control unit 220 automatically performs settings necessary for the new tenant to use. Specifically, a data area for a new tenant is secured in the multi-tenant database 400 and a connection setting for database access is prepared.

Embodiment 3 FIG.
In the present embodiment, differences from the first embodiment will be mainly described.

  FIG. 13 is a block diagram showing a configuration of access control apparatus 100 according to the present embodiment.

  In FIG. 13, the access control apparatus 100 includes a data check unit 246 for confirming the consistency of the result received from the table sharing type database 410 in the table sharing type connection unit 243 of the DB connection unit 240. Other configurations are the same as those of the first embodiment shown in FIG.

  FIG. 14 is a diagram illustrating a configuration example of the database connection setting table 330 of the multi-tenant management database 300.

  In FIG. 14, the database connection setting table 330 includes columns of tenant ID, connection destination DB model, pool ID, and DB check information, as in the first embodiment shown in FIG. As described above, the DB check information indicates a condition set for data stored in a specific table. This condition is set only when the connection destination DB model is the table sharing database 410. In this example, the database connection setting table 330 stores check conditions for the data of the tenant A as DB check information in association with the tenant ID “A”. Further, the database connection setting table 330 stores check conditions for the data of the tenant B as DB check information in association with the tenant ID “B”.

  As described above, in the present embodiment, the multi-tenant management database 300 stores conditions set for data stored in a table common to each tenant for each tenant whose access target is the table sharing database 410. Pre-stored by the device.

  Hereinafter, the operation of the access control device 100 when a service request is transmitted from the client system 101 of the tenant A (the access control method according to the present embodiment, the program according to the present embodiment, and the like) will be described with reference to FIG. Processing procedure) will be described.

  In order to use the existing application 500 without making the existing application 500 aware of the tenant ID, the flow of combining and separating the tenant ID with respect to the existing parameter is the same as that of the first embodiment shown in FIG.

  FIG. 15 is a sequence diagram showing a flow of access to the table sharing database 410.

  The processing of S701 to S709 is the same as the processing of S201 to S209 shown in FIG.

  In step S <b> 710, the table sharing type connection unit 243 uses the data check unit 246 to check whether the search results from the table sharing type database 410 are mixed.

  In step S <b> 711, the data check unit 246 uses the processing device to check whether there is any other tenant information for the search result from the table sharing database 410 based on the DB check information in the database connection setting table 330. When the data check unit 246 detects that other tenant information is mixed, the data check unit 246 deletes the information or notifies an error.

  The process of S712 is the same as the process of S210 illustrated in FIG. If the data check unit 246 notifies an error in S711, the error is notified to the model switching unit 242 as a search result.

  The flow of processing for returning the search result of the multi-tenant database 400 to the client system 101 is the same as that shown in FIG.

  With the operation described above, the service is provided from the multi-tenant application to the user of the tenant A. When a service request is transmitted from the client system 101 of the tenant B, the service is provided from the multi-tenant application to the user of the tenant B by the same operation.

  FIG. 16 is a diagram illustrating an operation example of the data check unit 246 in S711.

  In FIG. 16, the data check unit 246 issues a query (second query) including a condition set by the DB check information corresponding to the tenant ID extracted from the existing parameter to the table sharing database 410. The data check unit 246 compares the result of the issued query (second query) with the result of the query (first query) issued by the existing application 500 via the table sharing type connection unit 243 in S708. . Then, the data check unit 246 determines, based on the comparison result, whether the result of the query (first query) issued by the existing application 500 via the table sharing type connection unit 243 in S708 is correct or not. .

  Here, as a first example, in the database connection setting table 330, it is set as a check condition that tenant IDs of all the tables to be accessed by the query are “A” based on the DB check information of the tenant A. To do. Then, the existing application 500 designates the personal information table (user list), organization information table (organization list), and assignment information table (assignment list) as access targets, and extracts the tenant ID, user name, and organization name. Assume that one query is issued. In this case, in S708, the table sharing type connection unit 243 adds a personal information table (user list), an organization information table (organization list), a first query issued by the existing application 500 (for example, an SQL SELECT statement), After adding as a condition (for example, WHERE clause) that the tenant ID of the assignment information table (assignment list) is “A”, the first query is issued to the table sharing database 410. In step S <b> 711, the data check unit 246 determines that the tenant ID of the personal information table (user list), organization information table (organization list), and allocation information table (allocation list) is “A” based on the DB check information in the database connection setting table 330. As a condition, and in the same way as the first query, the personal information table (user list), organization information table (organization list), and assignment information table (assignment list) are designated as access targets, and the tenant ID, A second query for extracting a user name and an organization name is issued to the table sharing type database 410 (in this first example, the second query is the same as the first query issued by the table sharing type connection unit 243). Query). The data check unit 246 compares the result of the second query with the result of the first query. Since the result of the second query matches the result of the first query, the data check unit 246 determines that the result of the first query is correct.

  As a second example, in the database connection setting table 330, it is assumed that the user ID is “USER01” or “USER02” is set as a check condition by the DB check information of the tenant A. Assume that the existing application 500 issues the same first query as in the first example. In this case, in S708, the table sharing type connection unit 243 adds the same condition as in the first example to the first query issued by the existing application 500 (for example, the SQL SELECT statement), and then adds the first condition. A query is issued to the table sharing database 410. In S711, based on the DB check information in the database connection setting table 330, the data check unit 246 indicates that the user ID of the personal information table (user list) and the assignment information table (assignment list) is “USER01” or “USER02”. As a first query, a personal information table (user list), an organization information table (organization list), and an assignment information table (assignment list) are designated as access targets, and the tenant ID, user name, organization A second query for extracting a name is issued to the table sharing database 410. The data check unit 246 compares the result of the second query with the result of the first query. Since the result of the second query matches the result of the first query, the data check unit 246 determines that the result of the first query is correct.

  As described above, in the present embodiment, when accessing the table sharing database 410, a check function for reliably acquiring only the information of the target tenant without mixing other tenant information in the search result Is realized.

  When the database of the multi-tenant application is a table sharing type model, since information on a plurality of tenants is mixed on the database table, it is necessary to prevent another tenant from being mixed by the WHERE clause in the search SQL. However, when the search SQL becomes complicated, there may be a case where tenant information cannot be separated simply by adding tenant conditions to the WHERE clause. For example, in the case of using SQL in which a plurality of tables are joined by a JOIN clause at the time of search, information on other tenants may be mixed in. On the other hand, in this embodiment, it is possible to prevent another tenant's information from being included by performing a search again using the SQL described in the WHERE clause for the search result of the database. become.

  As mentioned above, although embodiment of this invention was described, you may implement in combination of 2 or more among these embodiment. Alternatively, one of these embodiments may be partially implemented. Alternatively, two or more of these embodiments may be partially combined. In addition, this invention is not limited to these embodiment, A various change is possible as needed.

  100 access control device, 101, 102 client system, 200 multi-tenant application platform, 210 UI connection unit, 220 multi-tenant control unit, 230 connection holding unit, 240 DB connection unit, 241 tenant separation unit, 242 model switching unit, 243 table Shared connection unit, 244 Schema separation type connection unit, 245 Instance separation type connection unit, 246 Data check unit, 300 Multi-tenant management database, 310 Tenant management table, 320 Tenant information combination setting table, 330 Database connection setting table, 400 multi Tenant type database, 410 Table shared type database, 420 Schema separated type database, 430 Instance separated type database, 500 Existing application 901 LCD, 902 keyboard, 903 mouse, 904 FDD, 905 CDD, 906 printer, 911 CPU, 912 bus, 913 ROM, 914 RAM, 915 communication board, 920 HDD, 921 operating system, 922 window system, 923 program group 924 file group.

Claims (7)

An access control device for controlling access to at least two types of multi-tenant-compatible databases that store individual data of each of the plurality of tenants from an application shared by a plurality of tenants to which at least one user belongs. And
For each tenant, a multi-tenant management database that pre-stores a tenant identifier that uniquely identifies a tenant and the type of database to be accessed by a storage device;
When input to the application, the input of parameters that the application outputs when accessing the at least two types of databases is accepted from a user belonging to one of the tenants by the input device, and the tenant of the tenant to which the user belongs An identifier is read from the multi-tenant management database, embedded in the parameter, and a user interface connection unit that inputs the parameter to the application;
When the parameter input by the user interface connection unit is output from the application, the tenant identifier embedded in the parameter is extracted, and the tenant database type corresponding to the extracted tenant identifier is extracted from the multi-tenant management database. An access control apparatus comprising: a database connection unit that reads and causes the application to access individual data of the tenant stored in the read type database among the at least two types of databases.   The access control apparatus according to claim 1, wherein the at least two types of databases include a plurality of types of databases having different configurations for multi-tenancy.   The plurality of types of databases include a first type database that performs multi-tenant correspondence by storing individual data of each of the plurality of tenants in a common table including a column of tenant identifiers, Multi-tenant support is provided by the existence of a second type of database that supports multi-tenant by storing individual data in separate tables and a separate database instance that stores individual tenant data for each tenant. 3. The access control apparatus according to claim 2, wherein the access control apparatus is a third type database. The application is an application that accesses the plurality of types of databases by issuing a first query to the plurality of types of databases,
The multi-tenant management database stores in advance conditions set for data stored in the common table for each tenant whose access target is the first type database,
When the database type read from the multi-tenant management database is the first type database, the database connection unit reads the tenant condition corresponding to the tenant identifier extracted from the parameter from the multi-tenant management database, Issuing a second query including the condition to the first type database, comparing the result of the first query issued by the application with the result of the second query, and comparing the result 4. The access control apparatus according to claim 3, wherein whether or not the result of the first query is correct is determined by a processing apparatus based on the determination result.   The user interface connection unit receives an input of a user identifier uniquely identifying the user as a parameter from a user belonging to any of the plurality of tenants, and the tenant identifier of the tenant to which the user belongs is managed in the multi-tenant management 5. The access control apparatus according to claim 1, wherein the tenant identifier is embedded in the parameter by reading from the database and connecting to the user identifier. An access control method for controlling access to at least two types of multi-tenant-compatible databases storing individual data of each of the plurality of tenants from an application shared by a plurality of tenants to which at least one user belongs. And
For each tenant, when a computer including a multi-tenant management database that pre-stores a tenant identifier that uniquely identifies a tenant and a type of database to be accessed by a storage device is input to the application, the application Input of parameters to be output when accessing two types of databases is received by an input device from a user belonging to one of the plurality of tenants, the tenant identifier of the tenant to which the user belongs is read from the multi-tenant management database, and the parameter And enter the parameters into the application,
When the input parameter is output from the application, the computer extracts the tenant identifier embedded in the parameter, reads out the tenant database type corresponding to the extracted tenant identifier from the multi-tenant management database, An access control method that causes the application to access individual data of the tenant stored in a read type database among at least two types of databases. A program for controlling access to at least two types of multitenant-compatible databases that store individual data of each of the plurality of tenants from an application shared by a plurality of tenants to which at least one user belongs,
For each tenant, a computer having a multi-tenant management database that pre-stores a tenant identifier for uniquely identifying a tenant and a type of database to be accessed by a storage device,
When input to the application, the input of parameters that the application outputs when accessing the at least two types of databases is accepted from a user belonging to one of the tenants by the input device, and the tenant of the tenant to which the user belongs An identifier is read from the multi-tenant management database, embedded in the parameter, and a user interface connection unit that inputs the parameter to the application;
When the parameter input by the user interface connection unit is output from the application, the tenant identifier embedded in the parameter is extracted, and the tenant database type corresponding to the extracted tenant identifier is extracted from the multi-tenant management database. A program for reading and functioning as a database connection unit that causes the application to access individual data of the tenant stored in the read type database among the at least two types of databases.

Images