JP7208807B2 - System, tenant movement method, information processing device and its control method, and program - Google Patents

Description

The present invention relates to a system, a tenant migration method, an information processing device and its control method , and a program.

There are so-called cloud services that provide various IT resources on the Internet on demand. The cloud generally publishes a Web service API (Application Programming Interface), and network devices such as copiers (hereinafter referred to as devices) can use functions provided by the cloud via the API. A standard protocol called OAuth 2.0 has been formulated as a protocol for authentication and authorization in using this API. In OAuth 2.0, a device that receives authentication and authorization is called a client. In order for a device to use the API, the device is registered as a client with the authorization server in advance. A device that is a client needs to hold a client ID for identifying the client issued by the authorization server and a secret (authentication information) for authentication.

On the other hand, in the cloud, it is common for multiple organizations (for example, companies) to share and use the same systems and services. Secured (multi-tenant method). Devices installed in an organization also need to be registered in the authorization server as belonging to the tenant corresponding to that organization if confidential information is included in the data exchanged with the cloud. As a result, the device can use various functions provided by the cloud without information leakage outside the tenant to which the device belongs.

Patent Document 1, for example, is an authority delegation system in which a device is registered in an authorization server in a form belonging to a specific tenant. In the technique of Patent Document 1, device tenant registration is realized by linking and managing device serial IDs and tenant IDs, and delegating user rights in the cloud to create tenant-dedicated clients. As one of the methods for realizing this, a key for registering a device to a specific tenant (hereafter referred to as a device registration key) is used. The user can register the device to the target tenant by obtaining the device registration key from the target tenant and entering it into the device.

JP 2017-107396 A

In the multi-tenant system, there are several types of tenants. For example, in addition to tenants of companies that use the cloud (hereafter referred to as customer tenants), there are tenants on the side of providers who provide the cloud (hereafter referred to as sales tenants). A user (customer) concludes a contract with a provider, and the provider creates a customer tenant. The sales tenant is used to manage customer tenants. Devices should be registered in the customer tenant, but may be temporarily registered in the sales tenant for reasons such as: For example, an installer who physically installs a device at an enterprise may wish to register the device with a customer tenant as part of the installation process, but the customer tenant does not yet exist at that stage. Also, if the installer is not a user of the customer tenant, it is possible that the key for registering the device to the customer tenant has not been obtained. On the other hand, in order for a customer to use a device registered in the sales tenant, it is necessary to move the device from the sales tenant to the customer tenant.

Thus, when a device is moved from one tenant to another tenant, simply rewriting the tenant to which the device belongs by the authorization server violates the principle of tenant separation. In other words, when a device owned by tenant A changes its affiliation to tenant B only by processing on the cloud side, it means that a client is created for tenant B with tenant A's authority. In other words, processing occurs between tenants that should be separated. To avoid this, the device needs to be newly registered with Tenant B, but manually re-registering the device after Tenant B is created is troublesome for the user.

In order to solve the above problems, the present invention has the following configuration. That is, the system includes an information processing device, a service providing server that provides services, and an authorization server that issues authorization information for using the services, wherein the authorization server issues information in response to a request . a first issuing means for issuing a registration key for registering an information processing device with a tenant; a second issuing means for issuing authentication information for identifying the information processing device registered in the tenant; and authorization information for using the service using the authentication information. When receiving a request, responding means for responding with the authorization information according to the verification result of the authentication information; and a holding means for holding the information of the different tenant as the information of the destination tenant, wherein the information processing device uses the registration key to the authorization server for the information processing registration request means for requesting registration of a device with a tenant; acquisition means for acquiring the authentication information issued based on the registration request from the authorization server; acquisition means for acquiring the authorization information as a response to an authorization information acquisition request , wherein the authorization server acquires the authorization information from the information processing device when the information on the tenant of the migration destination is held. further comprising notification means for notifying the information processing device of the information of the tenant at the destination when the acquisition request of the information processing device is received, wherein the registration request means of the information processing device is the Using another registration key for registering the information processing device with the destination tenant, a request for registration of the information processing device with the destination tenant is made.

According to the present invention, the tenant to which the device belongs can be automatically re-registered without violating the principle of tenant separation.

The figure which shows the structural example of the system which concerns on this invention. The figure which shows the example of the hardware constitutions concerning this invention. 4 is a functional block diagram of a device and an authorization server according to the first embodiment; FIG. FIG. 11 is a sequence diagram showing the flow of tenant migration processing for a device according to the first embodiment; 4 is a flowchart showing processing when an authorization server receives a token acquisition request according to the first embodiment; Sequence diagram showing tenant migration processing of a device according to the second embodiment 10 is a flowchart showing destination tenant information registration processing according to the third embodiment. FIG. 11 is a functional block diagram of a device according to the fourth embodiment; FIG. 12 is a sequence diagram showing device movement processing according to the fourth embodiment; FIG. 7 is a diagram showing an example of a screen for designating a destination tenant according to the first embodiment; FIG. 14 is a diagram showing an example of a screen for instructing tenant movement according to the fourth embodiment;

Hereinafter, embodiments will be described in detail with reference to the accompanying drawings. In addition, the following embodiments do not limit the invention according to the scope of claims. Although multiple features are described in the embodiments, not all of these multiple features are essential to the invention, and multiple features may be combined arbitrarily. Furthermore, in the accompanying drawings, the same or similar configurations are denoted by the same reference numerals, and redundant description is omitted.

<First embodiment>
[System configuration]
FIG. 1 is a diagram showing an example of a system configuration according to this embodiment. A WAN (Wide Area Network) 100 is configured by the Internet or the like. That is, in this embodiment, a WWW (World Wide Web) system is constructed. A LAN (Local Area Network) 110 connects each component. It should be noted that the connection methods and wired/wireless connections of various networks including the WAN 100 and LAN 110 are not limited, and various communication methods may be combined for realization.

A device 101, a terminal 102, an authorization server 103, and a resource server 104 are communicably connected via a LAN 110 and a WAN 100, respectively. In the system according to this embodiment, the authorization server 103 and resource server 104 are located on the WAN 100 side, and the device 101 and terminal 102 located on the LAN 110 side are connectable to various servers via the WAN 100 .

The authorization server 103 performs authorization processing for realizing OAuth2.0. The resource server 104 functions as a service providing server that provides various services via the network (LAN 110, WAN 100).

The terminal 102 is a PC (Personal Computer), a mobile terminal, or the like, and is a device operated by a user. Although not shown, the terminal 102 includes, for example, a web browser and a dedicated application for accessing the cloud (authorization server 103 and resource server 104).

Examples of the device 101 include a copier and a mobile terminal such as a smart phone, but are not particularly limited. The device 101 is registered with the authorization server 103 via the network (LAN 110, WAN 100), and uses services provided by the resource server 104 based on the registration. As an example of using the service, the device 101 uploads data to the resource server 104, and the like. The device 101 also includes various modules such as a web browser.

Also, the authorization server 103 and resource server 104 may be configured to connect to a database server (not shown) via a network and store data used by each server module in the database server. Furthermore, the authorization server 103 and resource server 104 may be configured on the same server (computer). Moreover, each server is not limited to a single computer, and may be a system composed of a plurality of computers.

(Hardware configuration)
FIG. 2 is a diagram showing an example hardware configuration of the device 101, terminal 102, authorization server 103, and resource server 104 according to this embodiment. A hardware configuration of a general information processing apparatus can be applied to each server, device 101, and terminal 102 of this embodiment. Furthermore, for each server, a virtual hardware configuration of an information processing device provided as IaaS (Infrastructure as a Service) can also be applied.

In FIG. 2, a CPU (Central Processing Unit) 201 executes programs such as an OS (Operating System) and applications stored in a program ROM of a ROM (Read Only Memory) 203, and is connected to a system bus 204. Control each block. The CPU 201 also executes a program loaded from an external memory 211 such as a hard disk (HD) to a RAM (Random Access Memory) 202 to control each block. Processing of each sequence to be described later can be realized by execution of a program by the CPU 201 .

A RAM 202 functions as a main memory, a work area, and the like for the CPU 201 . A keyboard controller 205 controls inputs from a keyboard 209 and a pointing device (not shown). Display controller 206 controls the display of display 210 . An external memory controller 207 controls data access to an external memory 211 such as a hard disk (HD) that stores various data. A network controller 2008 executes communication control processing with other devices connected via the WAN 100 and LAN 110 .

In this embodiment, the device 101, terminal 102, authorization server 103, and resource server 104 all have the configuration of the information processing apparatus 200 shown in FIG. However, the configuration is not limited to that shown in FIG. 2, and the display 210 may not be provided or other functions may be provided. Especially when assuming virtual information processing provided as IaaS, the keyboard controller 205, the display controller 206, etc. are not provided, and the keyboard 209 provided in the terminal connected via the network controller 208 and the display 210 configured to be operated. In all of the explanations below, unless otherwise specified, the CPU 201 is the hardware subject of execution in each server, terminal, and device, and the software subject is the application program installed in the external memory 211. .

(Functional configuration)
FIG. 3 is a diagram showing a configuration example of the functional blocks of the device 101 and the authorization server 103, particularly according to this embodiment. Each functional unit shown in FIG. 3 is implemented by the CPU 201 of each device executing a control program. Accordingly, each device may be capable of providing functions other than those shown in FIG.

FIG. 3A shows an example of the functional configuration of the device 101 according to this embodiment. A registration key input reception unit 301 receives input of a device registration key for registering the device 101 with the authorization server 103 . The device registration key may be input by hard key or touch panel operation on the device 101, or may be performed by reading OCR (Optical Character Recognition) or a two-dimensional barcode using an input I/F. Alternatively, the input screen provided by the device 101 may be accessed from a web browser (not shown) provided in the terminal 102, and the device registration key may be entered.

The tenant registration unit 302 requests the authorization server 103 to register the device 101 . At this time, the tenant registration unit 302 transmits the device registration key, device serial ID, and certificate possessed by the device 101 to the authorization server 103 . The certificates held here are, for example, X. 509-format client certificate and its private key, with which the device 101 can prove which vendor's device it is. The certificate is stored in a certificate store (not shown) on device 101 . A JWT (JSON Web Token) may be used to transmit information, in which case the device registration key, device serial ID, etc. are described in the JWT and signed with a certificate. Although omitted hereafter, JWT can be used in any communication between the device 101 and the authorization server 103 .

A secret holding unit 303 holds a client ID and a secret that are returned after the device 101 is registered with the authorization server 103 . A client ID is identification information issued to uniquely identify the device 101 . The secret is authentication information associated with the client ID (identification information) and used to authenticate the client (here, the device 101).

The token requesting unit 304 transmits the client ID and secret to request an authorization token from the authorization server 103 . The authorization token is authorization information for using services provided by the resource server 101 and is required when the device 101 uses the API of the resource server 104 .

A registration key requesting unit 305 requests a device registration key from the authorization server 103 . A device 101 may request a device registration key if it has already been registered with a tenant and is about to move from there to another tenant. In this embodiment, a client ID and a secret are specified when requesting a device registration key.

FIG. 3B shows an example of the functional configuration of the authorization server 103 according to this embodiment. Upon receiving an authorization token acquisition request from the device 101, the token issuing unit 311 performs client authentication. Specifically, it verifies whether or not the received set of client ID and secret is registered in the authorization server 103, and determines whether or not the request is accepted based on the verification result. If the client ID/secret pair is registered in the client management table managed by the authorization server 103, the client authentication for the requester succeeds. If the client authentication succeeds, the token issuing unit 311 issues an authorization token to the requester. Specifically, the token issuing unit 311 issues an authorization token ID, associates it with information for using the authorization token, and manages it in a token management table. Each table shown below is held and managed by the HD 211 or the like, with the CPU 201 functioning as a management unit.

Table 1 shows an example of a token management table according to this embodiment. The token management table manages token types, client IDs, and the like in association with authorization token IDs. A user UUID indicates a user who delegates authority to the device 101 . A UUID (Universal Unique Identifier) is a unique ID (identification information) that does not overlap. A scope defines the range of resources to which a user delegates authority. In the example shown in Table 1, the scope is "tenant-dedicated client", and the authority of the user with the user ID "10000001" is transferred to the device 101 (client associated with a specific tenant). means.

In addition, the token issuing unit 311 determines whether the tenant's destination information is set in association with the client ID. Details of this process will be described later.

Upon receiving a tenant registration request from the device 101 together with a device registration key including tenant ID information, a device serial ID, and a certificate possessed by the device 101, the client generation unit 312 performs client authentication using the certificate. Then, the client generation unit 312 generates a client when client authentication is successful. Specifically, the client generation unit 312 issues a client ID and a secret, and manages them by associating them with the device serial ID and the tenant ID.

The destination tenant information registration unit 313 receives the destination tenant ID of the device 101 and manages it by linking it to the client ID.

The data handled by each of the above processing units is saved in the client management table. Table 2 shows an example of a client management table according to this embodiment. The client ID is an ID (identification information) generated by the client generation unit 312 and is unique in the system according to this embodiment. The secret is generated by the client generation unit 312 and used in combination with the client ID when authenticating the client. The tenant ID is the ID (identification information) of the tenant to which the client (ie device 101) belongs. A device serial ID is an ID (identification information) for uniquely identifying the device 101 . The destination tenant ID is blank until it is specified.

Using the token management table (Table 1) and the client management table (Table 2), the authorization server 103 associates the device 101 with the tenant and manages authorization tokens.

Upon receiving the tenant ID, the registration key generation unit 314 generates a device registration key for registering the device to the tenant indicated by this tenant ID. There are two actors (request entities) that request generation of a device registration key. One is a user via the resource server 104 . In this case, the registration key generation unit 314 generates a device registration key with the authority of the user who logged into the tenant. The other is the device 101. In this case, the registration key generation unit 314 receives the certificate possessed by the device 101 and generates a device registration key when the client authentication by the certificate is successful.

Table 3 shows an example of a device registration key management table according to this embodiment. A device registration key is, for example, a 16-digit integer and is associated with a tenant ID. The expiration date is the expiration date during which the device registration key can be used.

[Screen example]
FIG. 10 is an example of a screen displayed on a web browser (not shown) or the like of the terminal 102 when specifying a destination tenant to the destination tenant information registration unit 313 of the authorization server 103 according to this embodiment. FIG. 10A shows a configuration example of a device list screen 1000. On the device list screen 1000, a user designates a specific tenant (“AAA tenant” in this example), and the devices registered in that tenant are displayed. A list is displayed. It is also assumed that "101AA" is assigned as the tenant ID of "AAA tenant". The user presses the registration destination tenant change button 1001 of the device whose tenant is to be moved. In this example, it is assumed that a device with serial number "D00000001" is selected.

When the registration tenant change button 1001 is pressed, a registration tenant change screen 1010 shown in FIG. 10B is displayed. A serial number 1011 indicates the serial number of the device selected on the device list screen 1000 . The destination tenant ID 1012 can be entered in a text box, and the user specifies the tenant ID of the destination tenant. At this time, the destination tenant information registration unit 313 may retrieve and display the tenant name from the input tenant ID. When the user presses the change button 1013 , a registration instruction is issued to the destination tenant information registration unit 313 .

[Tenant move process]
FIG. 4 is a sequence diagram showing the flow of processing for tenant migration of the device 101 according to this embodiment. The processing shown in FIG. 4 is implemented by the CPU 201 of each device reading and executing a program stored in a storage unit such as the ROM 203 .

In FIG. 4, it is assumed that the resource server 104 operates a device management service for managing setting information and operation information of the device 101, for example. Tenant transfer processing is roughly divided into three steps. First, the device 101 is registered with tenant A (tenant before movement). Next, tenant B is set as the tenant to which the device registered in tenant A is moved. Finally, the device 101 that accessed Tenant A is newly registered (moved) to Tenant B.

First, the flow of registering the device 101 with the tenant A will be described. S401 to S409 in FIG. 4 correspond to this step.

In step S<b>401 , the terminal 102 requests the resource server 104 for a device registration key in order to register the device 101 with tenant A based on an instruction from the user of tenant A. FIG.

At S<b>402 , resource server 104 requests a device registration key from authorization server 102 based on the request from terminal 102 . At this time, the resource server 104 requests the device registration key with the authority of the user logged into the resource server 104 .

In S403, the registration key generation unit 314 of the authorization server 102 performs authority verification based on the request from the resource server 104, and generates a device registration key for registering with tenant A when the authority verification is successful. , is registered in the device registration key management table (Table 3). It should be noted that, if the authorization verification fails, that fact may be returned to the resource server 104 . In this case, the resource server 104 will also notify the terminal 102 that the authorization verification has failed.

In S404, authorization server 103 returns the generated device registration key to resource server 104 in response to the request.

In S<b>405 , resource server 104 returns the device registration key received from authorization server 103 to terminal 100 . At this time, for example, the received device registration key may be displayed on a web browser (not shown) of the terminal 102 .

In S406, the terminal 102 inputs the device registration key to the device 101 based on the instruction of the tenant A user. For example, terminal 102 may access device 101 and enter a device registration key via a screen provided by device 101 . Alternatively, the configuration may be such that the user directly inputs to the device 101 using the input device of the device 101 .

In S407, the tenant registration unit 302 of the device 101 transmits the input device registration key, its own device serial number, and the information of its own certificate to the authorization server 103, and requests device registration.

In S<b>408 , client generation unit 312 of authorization server 103 authenticates device 101 using the certificate received from device 101 . Also, when the authentication succeeds, the client generation unit 312 extracts the tenant ID (that is, the tenant ID of tenant A) from the received device registration key, generates and stores the client ID and secret. Note that if the authentication fails, that fact may be returned to the device 101 .

In S<b>409 , authorization server 103 returns the generated client ID and secret to device 101 . Secret holding unit 303 of device 101 holds the client ID and secret received from authorization server 103 . At this point, the device 101 has been registered with Tenant A. Although not shown, it is assumed that the resource server 104 can obtain a list of client IDs corresponding to each device by inquiring the authorization server 103 .

Next, a flow of setting for moving a device registered in tenant A to tenant B will be described. S411 to S413 in FIG. 4 correspond to this step.

In step S<b>411 , the terminal 102 instructs the resource server 104 to move the tenant to which the device 101 belongs to the tenant B based on the instruction of the user of the tenant A. It is assumed that the instruction method here is performed using the screen shown in FIG.

In S412, the resource server 104 designates the client ID of the device 101 and instructs the authorization server 103 to move the tenant. As described above, the resource server 104 can acquire a list of client IDs corresponding to devices, and the client IDs specified here are performed by indicating the client IDs corresponding to the serial numbers of the devices 101 .

In S413, the destination tenant information registration unit 313 of the authorization server 103 associates the destination tenant ID with the client ID (that is, the tenant ID of tenant B) as the destination tenant ID of the client management table (Table 2). to register. At this point, preparations for tenant migration are complete.

Finally, the flow of new registration of the device 101 to the tenant B will be described. S421 to S433 in FIG. 4 correspond to this step.

In S421, the token requesting unit 304 of the device 101 transmits the client ID and secret to the authorization server 103 to request an authorization token so that the device 101 can use the API of the resource server 103. FIG.

In S422, the token issuing unit 311 of the authorization server 103 refers to the client management table (Table 2) to verify whether the set of the client ID and secret received from the device 101 is registered in the authorization server 103. do. Furthermore, the token issuing unit 311 confirms whether there is destination tenant information associated with the client ID. At this time, the presence or absence of confirmation processing may be determined according to the type of tenant to which the tenant currently belongs. This processing will be described later with reference to FIG.

If the client authentication is successful and the destination tenant information exists, the token issuing unit 311 returns the destination tenant ID (that is, the ID of tenant B) to the device 101 in S423. At this time, an HTTP status code "403", for example, may be returned as a response, but the present invention is not limited to this. Note that if the client authentication fails, that fact may be returned to the device 101 .

In S<b>424 , the token requesting unit 304 of the device 101 calls the registration key requesting unit 305 when the tenant ID of the migration destination is returned from the authorization server 103 . The registration key requesting unit 305 requests the device registration key from the authorization server 103 by assigning the migration destination tenant ID and the certificate possessed by the device 101 .

In S425, the registration key generation unit 314 of the authorization server 103 performs client authentication based on the certificate received from the device 101, and determines whether the device 101 is a product of an assumed vendor and whether a device registration key can be issued. determine whether If it is determined that the issuance is permitted, the registration key generation unit 314 generates a device registration key for registering the device 101 with the tenant B, and registers it in the device registration key management table (Table 3).

In S426, registration key generation unit 314 returns the generated device registration key to device 101 as a response to the request.

In S427, the tenant registration unit 302 of the device 101 transmits the device registration key, device serial number, and certificate information acquired in S426 to the authorization server 103, and requests device registration.

In S428, client generation unit 312 of authorization server 103 authenticates device 101 using the certificate received from device 101 in S427. Also, when the authentication succeeds, the client generation unit 312 extracts the tenant ID (that is, the ID of tenant B) from the device registration key received in S427, generates and stores the client ID and secret. Note that if the authentication fails, that fact may be returned to the device 101 .

In S429, authorization server 103 returns to device 101 the client ID and secret generated in S428.

At S430, secret holding unit 303 of device 101 saves the client ID and secret received from authorization server 103 at S429.

In S431, the token requesting unit 304 of the device 101 transmits the new client ID and secret acquired in S430 to the authorization server 103 to request an authorization token.

In S432, the token issuing unit 311 of the authorization server 103 refers to the client management table (Table 2) to verify whether the received set of client ID and secret is registered in the authorization server 103. FIG. Furthermore, the token issuing unit 311 confirms whether there is destination tenant information associated with the client ID.

If the client authentication succeeds and the migration destination tenant information does not exist, the token issuing unit 311 returns an authorization token to the device 101 in S433. Thereafter, although not shown in FIG. 4, the device 101 sends the authorization token received in S433 to the resource server 104. FIG. In addition, resource server 104 sends an authorization token to authorization server 103 . Then, the authorization server 103 verifies the authorization token, and by confirming its validity, the device 101 can use the API of the resource server 104 . When exchanging tokens using JWT as described above, the resource server 104 verifies the authorization token by itself without sending the authorization token to the authorization server 103 .

It should be noted that, at the time of S422, if the client authentication is successful and the migration destination tenant information does not exist, the authorization token for tenant A is returned to the device 101. FIG. Using this authorization token, the device 101 can then use the API on the resource in Tenant A. In this case, the tenant will not be moved.

By executing the flow described above, the device 101 registered in tenant A can be newly registered (moved) to tenant B. FIG.

(Confirmation processing of destination tenant information)
FIG. 5 is a flowchart showing the flow of processing when the authorization server 103 receives a token acquisition request from the device 101. As shown in FIG. This processing flow is performed in the step of S422 in FIG.

In S501, the token issuing unit 311 of the authorization server 103 receives a token acquisition request from the device 101 and receives the client ID and secret. This corresponds to S421 in FIG.

In S502, the token issuing unit 311 performs client authentication by referring to the client management table (Table 2) using the received client ID as a key. If client authentication fails here, this processing flow may end. In this case, the device 101 is notified that client authentication has failed.

In S503, the token issuing unit 311 obtains the tenant ID to which the device 101 belongs by referring to the client management table (Table 2) using the client ID as a key.

In S504, the token issuing unit 311 determines whether the type of tenant to which the tenant 101 belongs is a specific type. Examples of specific types include sales tenants and customer tenants. For example, if there is a possibility of tenant movement only when the device 101 is registered as a sales tenant, by determining a specific type as a sales tenant, movement information for tenants of other types is unnecessary. Confirmation can be omitted. The types of tenants will be described later. If it is determined to be the specific type (YES at S504), the process proceeds to S505, and if it is determined not to be the specific type (NO at S504), the process proceeds to S507.

In S505, the token issuing unit 311 refers to the client management table (Table 2) to confirm the presence or absence of tenant transfer information. If the tenant move information exists (YES at S505), the process proceeds to S506, and if the tenant move information does not exist (NO at S505), the process proceeds to S507.

In S506, the token issuing unit 311 returns the destination tenant ID to the device 101 as a response to the token acquisition request. This corresponds to S423 in FIG. Then, this processing flow ends.

In S507, the token issuing unit 311 issues an authorization token and returns the authorization token to the device 101 as a response to the token acquisition request. This corresponds to issuing authorization token without moving the tenant. Then, this processing flow ends.

The tenant types described above are managed in the tenant management table in the authorization server 103 . Table 4 shows an example of a tenant management table according to this embodiment. Tenant ID, tenant name, tenant type, and creation date and time are associated and managed. Here, "sales tenant" and "customer tenant" are shown as examples of tenant types, but other types may be used. Also, a configuration in which each type of tenant is managed in a separate table may be adopted.

As described above, as in this embodiment, the device 101 that receives the tenant move instruction from the authorization server 103 requests new registration to the tenant of the move destination. It is possible to move tenants without causing

<Second embodiment>
A second embodiment according to the present invention will be described with reference to FIG. In the first embodiment, after the device 101 moves to a tenant, the client remains in the tenant of the move source (tenant A in the above example). In the present embodiment, a method for deleting or invalidating a client in the migration source tenant will be described. Note that the description of the configuration that overlaps with the first embodiment will be omitted.

[Tenant move process]
FIG. 6 is a sequence diagram showing the flow of movement of the device 101 from tenant A to tenant B according to this embodiment. Description of the same processing as the sequence of FIG. 4 described in the first embodiment is omitted. The difference from FIG. 4 is that steps S601 to S603 are added. A new client is created in tenant B by the authorization server 103 (S428), and after the device 101 receives and stores the client ID and secret (S429 to S403), the processes of S601 to S603 are performed.

In S601, the tenant registration unit 302 of the device 101 designates the tenant A and requests to delete the device. At this time, the client ID of tenant A to be deleted and the corresponding secret are transmitted as a device deletion request.

In S602, the client generation unit 312 of the authorization server 103 performs client authentication using the client ID and secret of tenant A received from the device 101 in S601. When the authentication succeeds, the client generation unit 312 deletes the client information of the designated client ID from the client management table (Table 2). Note that a configuration may be employed in which a flag is set in the client management table to invalidate the client rather than delete the client, thereby making the client reusable.

In S603, the client generation unit 312 returns deletion completion to the device 101 as a response to the request. Furthermore, the secret holding unit 303 of the device 101 deletes the client ID and secret of the tenant A that it holds. After that, the process proceeds to S431.

As described above, according to this embodiment, in addition to the effects of the first embodiment, it is possible to delete or invalidate the client information in the tenant of the migration source.

In this embodiment, if the migration to the destination tenant (tenant B in the above example) fails due to an authentication error, etc., the client information in the migration source tenant will not be deleted or invalidated. .

<Third Embodiment>
A third embodiment according to the present invention will be described with reference to FIG. Note that the description of the configuration that overlaps with the first embodiment will be omitted. In this embodiment, when the destination tenant information is set in the authorization server 103, it is determined whether or not it is possible to move to the specified tenant. Taking the example of a sales tenant and a customer tenant, a sales relationship is established between the sales tenant when the sales tenant contracts with the customer tenant to provide services. Tenants can be moved only when this sales relationship is established.

Sales relationships between tenants are managed in a sales relationship management table. Table 5 shows an example of a sales relationship management table according to this embodiment. In the example of Table 5, the sales tenant with tenant ID "101AA" has a sales relationship with customer tenants with tenant IDs "1001AA" and "1002AA". A service is a service (license) permitted (provided) by a sales tenant to a customer tenant.

In addition, there may be multiple sales tenants, and it may be possible to determine whether the tenant can be moved based on the relationship between the sales tenants. For example, a sales form in which a sales company directly manages customer tenants is called "direct sales." Note that even in the case of direct sales, a sales company can have multiple hierarchies. On the other hand, a sales form in which a sales company provides cloud services through a sales agent and the sales agent manages customer tenants is called "indirect sales." At this time, it is conceivable to permit device tenant migration only between tenants having a sales form of direct sales.

Table 6 shows an example of a sales form management table between sales tenants including customer tenants according to this embodiment. In the example of Table 6, there are sales tenants with tenant IDs "102AA" and "111AA" as tenants managed by the sales tenant with tenant ID "101AA". The tenant type is managed in the tenant management table (Table 4), and is linked using the tenant ID as a key. For example, the sales form between tenants with tenant IDs "101AA" and "102AA" is "direct sales", and the sales form between tenants with tenant IDs "101AA" and "111AA" is "indirect sales". In addition, as tenants managed by the sales tenant with tenant ID "102AA", there are a sales tenant with tenant ID "103AA" and a customer tenant with tenant ID "1001AA". Both of these are "direct sales" in the form of sales. Also, there is a customer tenant with a tenant ID of "1101AA" as a tenant managed by the sales tenant with a tenant ID of "111AA". This form of sales between tenants is also “direct sales”.

Assume that a device is registered in a sales tenant with a tenant ID of "101AA" and that the device can be moved only to a tenant with a "direct sales" relationship. In this case, tenants that can be moved from the sales tenant with tenant ID "101AA" are tenants with tenant IDs "102AA", "102AA", "103AA", and "1001AA". In this case, it is possible to move to a lower tenant according to the hierarchical structure. Note that it is not possible to move to tenants with tenant IDs "111AA" and "1101AA".

(Destination registration process)
FIG. 7 is a flowchart showing the flow of destination registration processing according to this embodiment. This processing flow is executed when the authorization server 103 receives a registration request for the destination tenant information, and is executed, for example, in step S413 of FIG.

In S701, the migration destination tenant information registration unit 313 of the authorization server 103 receives the migration target client and the migration destination tenant information from the resource server 104 or the like.

In S702, the move destination tenant information registration 313 determines whether or not the received move destination tenant can be moved from the tenant of the client to be moved (the tenant in which the device 101 is currently registered). Determination as to whether or not it is possible to move is made using Table 5, Table 6, etc., as described above. If it is determined to be movable (YES at S702), the process proceeds to S703, and if it is determined not to be movable (NO at S702), the process proceeds to S704.

In S703, the destination tenant information registration unit 313 registers the destination tenant ID in the client management table. Then, this processing flow ends.

In S704, the destination tenant information registration unit 313 returns an error to the device 101, stating that the requested tenant ID cannot be registered. In this case, the configuration may be such that the designation of the destination tenant is accepted again. Then, this processing flow ends.

As described above, according to the present embodiment, in addition to the effects of the first embodiment, it is possible to determine whether or not to move to a tenant requested as a destination based on the sales relationship, and to notify the device 101 of the possibility or denial. Become.

In the above example, whether or not it is possible to move is determined based on the sales relationship, but the present invention is not limited to this. It may be possible to determine whether or not to move based on other relationships between tenants.

<Fourth embodiment>
A fourth embodiment according to the present invention will be described with reference to FIGS. 8, 9 and 11. FIG. In the above embodiment, the tenant of the device to be used is automatically changed after the destination tenant is registered without the user of the device being aware of it. However, in this case, there is a possibility that the tenant will move at a timing unintended by the customer, and use of the cloud will start. Therefore, in the present embodiment, tenant migration is not started just by completing the registration of the destination tenant at the sales tenant, and a form in which the device user (administrator) actively instructs tenant migration will be described. Note that the description of the configuration that overlaps with the first embodiment will be omitted.

It should be noted that if the device administrator can instruct the tenant including the tenant ID of the destination tenant, the registration of the destination tenant information in the authorization server 103 is not technically essential, but in this embodiment, the device administrator In order not to move the tenant only with instructions, we will explain the configuration that requires pre-registration of the destination tenant information.

(screen structure)
FIG. 11 is an example of a UI (User Interface) screen displayed on the display 210 such as a touch panel of the device 101 according to this embodiment. The UI screen 1100 is displayed, for example, when the administrator of the device 101 wants to check the tenant registration status of the device 101 . On the UI screen 1100, a tenant transfer button 1101 is arranged next to the tenant ID displayed. The administrator of the device 101 presses the move tenant button 1101 to give an instruction to move the tenant. It should be noted that, when the move tenant button 1101 is pressed, it is assumed that the tenant information of the move destination has already been registered. Therefore, if the tenant information of the move destination is not registered, the tenant move button 1101 may not be displayed, or may be controlled so that it cannot be pressed. Also, the tenant information of the move destination and the move source may be displayed on the UI screen 1100 .

[Function configuration]
FIG. 8 is a block diagram showing an example of the functional configuration of the device 101 according to this embodiment. In addition to the configuration shown in FIG. 3A of the first embodiment, a tenant movement instruction unit 801 is provided. The tenant move instruction unit 801 instructs the authorization server 103 to move the tenant in response to the user pressing the tenant move button 1101 shown in the UI screen 1100 of FIG. Specifically, the tenant transfer instruction unit 801 transmits the client ID and secret of the device 101 to the authorization server 103 and instructs the transfer of the tenant.

[Tenant move process]
FIG. 9 is a sequence diagram showing the flow of movement of the device 101 from tenant A to tenant B according to this embodiment. Description of the same processing as the sequence of FIG. 4 described in the first embodiment is omitted. The difference from FIG. 4 is that the process of S901 is performed instead of S421. As described above, in this embodiment, in S411 to S413, pre-registration of destination tenant information is performed.

The tenant move instruction unit 801 of the device 101 instructs the authorization server 103 to move the tenant in S901 as a result of the user pressing the tenant move button 1101 on the UI screen 1100 on the device 101 . This process may be internally the same as the process of requesting an authorization token from the authorization server 103, similar to S421 in FIG. If the destination tenant information is not set on the authorization server 103 side, the authorization server 103 returns an authorization token. In this case, using this authorization token, the device 101 will be able to use APIs in resources in tenant A, and tenant migration will not occur.

As described above, according to this embodiment, the tenant can be moved at the timing intended by the administrator of the device 101 .

<Other embodiments>
The present invention supplies a program that implements one or more functions of the above-described embodiments to a system or device via a network or a storage medium, and processes that one or more processors in the computer of the system or device read and execute the program. But it is feasible. It can also be implemented by a circuit (for example, ASIC) that implements one or more functions.

The invention is not limited to the embodiments described above, and various modifications and variations are possible without departing from the spirit and scope of the invention. Accordingly, the claims are appended to make public the scope of the invention.

101... device, 102... terminal, 103... authorization server, 104... resource server

Claims (12)

A system that includes an information processing device, a service providing server that provides a service, and an authorization server that issues authorization information for using the service,
The authorization server is
a first issuing means for issuing a registration key for registering an information processing device with a tenant in response to a request;
registration means for registering information on the information processing device with the tenant when a registration request for the information processing device is received using the registration key;
a second issuing means for issuing authentication information for identifying the information processing device registered with the tenant;
response means for responding with the authorization information according to a verification result of the authentication information when a request for authorization information for using the service is received using the authentication information;
a receiving means for receiving a request to move the information of the information processing device registered with the tenant to a different tenant;
and holding means for holding the information of the different tenant as the information of the destination tenant,
The information processing device is
registration request means for requesting the authorization server to register the information processing device as a tenant using the registration key;
acquisition means for acquiring the authentication information issued based on the registration request from the authorization server;
acquisition means for acquiring the authorization information as a response to an authorization information acquisition request to the authorization server using the authentication information;
When the authorization server holds the information of the tenant of the migration destination, when receiving the acquisition request of the authorization information from the information processing device, the authorization server notifies the information of the tenant of the migration destination to the information processing device. further has a notification means to
The registration request means of the information processing device uses another registration key for registering the information processing device issued by the authorization server with the tenant of the destination of the movement of the information processing device. make a registration request to
A system characterized by: When the authorization server receives the authorization information acquisition request from the information processing device and determines that the tenant whose information on the information processing device is registered is a tenant of a specific type, the authorization server 2. The system according to claim 1, wherein confirmation processing of information of a tenant at a destination is performed. 4. The authorization server, when it is determined that the information of the information processing device is not registered in the tenant of the specific type, the authorization information is returned without performing the confirmation process. 2. The system according to 2. 4. The apparatus according to any one of claims 1 to 3, wherein the information processing device requests the authorization server to acquire the authorization information using the authentication information when using the service. System as described. 4. The information processing apparatus according to any one of claims 1 to 3, wherein said information processing apparatus requests said authorization server to acquire said authorization information using said authentication information, in response to receiving an instruction from a user. or the system according to item 1. The information processing device further comprises means for requesting the authorization server to delete information registered in association with the source tenant upon completion of the migration to the destination tenant. 6. A system according to any one of claims 1 to 5, characterized in that: The authorization server further has management means for managing information of tenants to whom the information of the information processing device can be transferred,
When the authorization server determines that the information of the information processing device can be transferred to the different tenant, the holding means holds the information of the different tenant as the information of the destination tenant. 7. A system according to any one of claims 1-6. 8. The system of claim 7, wherein the authorization server notifies an error if it determines that migration to the different tenant is not possible. A method of moving a tenant in a system including an information processing device, a service providing server that provides a service, and an authorization server that issues authorization information for using the service,
a first issuing step in which the authorization server issues a registration key for registering an information processing device with a tenant in response to a request;
a registration request step in which the information processing device requests the authorization server to register the information processing device as a tenant using the registration key;
a registration step of registering information of the information processing device with the tenant when the authorization server receives the registration request from the information processing device;
a second issuing step in which the authorization server issues authentication information for identifying the information processing device registered with the tenant;
a first acquisition step in which the information processing device acquires the authentication information from the authorization server;
a response step of, when the authorization server receives a request for authorization information for using the service using the authentication information, responding with the authorization information according to a verification result of the authentication information;
a second acquisition step in which the information processing device acquires the authorization information as a response to an authorization information acquisition request to the authorization server using the authentication information;
a receiving step in which the authorization server receives a request to move the information of the information processing device registered in the tenant to a different tenant;
a holding step in which the authorization server holds the information of the different tenant as the information of the destination tenant,
When the authorization server holds the information of the tenant of the migration destination, when the acquisition request of the authorization information is received from the information processing device, the information of the tenant of the migration destination is notified to the information processing device. further having a notification step to
In the registration request step, using another registration key for registering the information processing device with the destination tenant issued by the authorization server, the information processing device is requested to be registered with the destination tenant. A method of moving a tenant, characterized in that An authorization server that issues authorization information for an information processing device corresponding to information registered in a tenant to use a service, and the information processing device that can communicate via a network,
request means for requesting authorization information from the authorization server using the authentication information issued by the authorization server;
receiving means for receiving notification of destination tenant information from the authorization server based on the request;
Using a registration key issued by the authorization server for registering the information processing device in the destination tenant, requests the authorization server to register the information processing device in the destination tenant. a registration request means;
The information processing device, wherein the authorization server registers the information of the information processing device with the tenant of the migration destination based on the registration request. An authorization server that issues authorization information for using a service by an information processing device corresponding to information registered in a tenant, and a control method for the information processing device that can communicate via a network,
a requesting step in which the request means of the information processing device requests authorization information from the authorization server using the authentication information issued by the authorization server;
a receiving step in which the receiving means of the information processing device receives notification of the destination tenant information from the authorization server based on the request;
The registration request means of the information processing device uses a registration key issued by the authorization server for registering the information processing device with the tenant of the migration destination to the authorization server. a registration request step of requesting registration to the destination tenant,
A control method for an information processing device, wherein the authorization server registers the information of the information processing device in the tenant of the migration destination based on the registration request. An authorization server that issues authorization information for the computer corresponding to the information registered in the tenant to use the service, and the computer that can communicate via the network,
request means for requesting authorization information from the authorization server using the authentication information issued by the authorization server;
Receiving means for receiving notification of destination tenant information from the authorization server based on the request;
As a registration request means for requesting the authorization server to register the computer in the destination tenant using a registration key issued by the authorization server for registering the computer in the destination tenant A program for functioning,
A program, wherein in the authorization server, the information of the computer is registered in the destination tenant based on the registration request.

Images