JP2017004286A - Information processing system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an information processing system which can equivalently use clouds on the Internet and storage in an intranet, and has no influence on use even if a change occurs in an account.SOLUTION: An intranet 10 includes storage 102 in an intranet, a storage proxy 104 for issuing a token associated with authentication information for permitting the use of the storage 102 in the intranet, and an account mapping DB 101 for storing the token associated with the authentication information. A relay server 12 for accessing a cloud A14 and a cloud B16 on the Internet includes a token DB 124 for storing a token in association with an account, and a plug-in 121 for a storage proxy for using the token to access the storage proxy 104.SELECTED DRAWING: Figure 1

Description

  The present invention relates to an information processing system.

  Technologies that enable access from the Internet to an intranet have been proposed.

  Patent Document 1 discloses a first information processing apparatus connected to the Internet, a first management server that manages access to the intranet from the first information processing apparatus, and a second information processing apparatus connected to the intranet. And a second management server for managing access to the Internet from the second information processing apparatus, and performing bidirectional communication between the first management server and the second management server. A global account management server that performs login management on the Internet and an ACL server that performs access management on an intranet communicate with each other.

JP 2012-238150 A

  By simply deciding whether or not each service can be used by ACL (Access Control List), the linkage between multiple services is not taken into consideration. In particular, there is a connection between the public cloud storage service on the Internet and the storage service on the intranet. Cooperation is not planned.

  Further, if the global account and the account in the intranet are directly associated and managed, there is a disadvantage that the association itself becomes invalid when the global account is changed.

  An object of the present invention is to provide an information processing system that can use both the cloud on the Internet and the storage in the intranet, and that does not affect the use even when the account is changed.

  The invention according to claim 1 stores, in the intranet, a storage, a proxy that issues a token associated with authentication information for permitting use of the storage, and the token associated with the authentication information. A first database, a relay server that accesses the cloud on the Internet from the intranet, a second database that stores the token in association with an account, and a processing unit that accesses the proxy using the token Information processing system.

  According to a second aspect of the present invention, when the use of the storage is requested from a user terminal, the relay server reads the token from the second database and transmits the token to the proxy. The information processing system according to claim 1, wherein the storage is accessed using the authentication information associated with the token from one database.

  According to a third aspect of the present invention, the proxy issues an update token when the token is not usable and stores it in the first database in association with the authentication information, and the relay server stores the update token. Storing in the second database in association with the account, and automatically starting a request from the user terminal that was suspended when the token is unavailable and sending the renewal token to the proxy; An information processing system according to claim 2.

  According to the first aspect of the present invention, both the cloud on the Internet and the storage in the intranet can be used. In addition, changes to the account will not affect the use of storage in the intranet.

  According to the second aspect of the present invention, the authentication information for using the storage in the intranet is held in the intranet, and security is ensured.

  According to the third aspect of the present invention, more efficient processing is possible compared to the case where a request is transmitted again from the user terminal.

It is a system configuration figure of an embodiment. It is a processing flowchart (the 1) of an embodiment. It is a processing flowchart (the 2) of an embodiment. It is a processing flowchart (the 3) of an embodiment. It is a processing flowchart (the 4) of an embodiment.

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

<System configuration>
FIG. 1 is a system configuration diagram of an information processing system in the present embodiment. The system includes an intranet 10 and a relay server 12. The relay server 12 accesses a plurality of clouds A14 and cloud B16 on the Internet. The relay server 12 generally relays data by transferring data received from a plurality of tenants to a plurality of clouds. Each of the plurality of clouds uses a different API (Application Programming Interface) for each cloud, and when a plurality of tenants of the plurality of intranets 10 use the services of each cloud, the API of each cloud must be known in advance. Don't be. The relay server 12 provides each tenant with only a unified API by concealing the API of each cloud so that each tenant can use a plurality of cloud services without knowing a different API for each cloud. .

<Intranet>
The intranet 10 in this embodiment includes an account mapping database (DB) 101, an intranet (hereinafter referred to as “intra” as appropriate) storage 102, a client (application) 103, and a storage proxy 104.

  The account mapping DB 101 functions as a first database, and is a database that manages credential information for accessing the intra storage 102, that is, authentication information such as an ID and password, and a token in association with each other.

  The intra storage 102 is a storage provided in the intranet 10 and basically permits access from within the intranet 10, but in this embodiment, permits access via the relay server 12.

  The client 103 is a client in the intranet 10 and is an application that operates on a user terminal. The user starts an application on the user terminal and accesses the relay server 12.

  The storage proxy 104 is a proxy server for accessing the intra storage 102. The storage proxy 104 performs mutual communication with the storage proxy plug-in of the relay server 12 and accesses the intra storage 102 in response to a request from the storage proxy plug-in.

<Relay server>
On the other hand, the relay server 12 in this embodiment includes a storage proxy plug-in 121, a plug-in database (DB) 122, an account database (DB) 123, a token database (DB) 124, a plug-in A 125, and a plug-in B 126.

  The storage proxy plug-in 121 functions as a processing unit, and is a plug-in for performing mutual communication with the storage proxy 104 in order to access the intra storage 102. A plug-in is a program added to expand functions.

  The plug-in DB 122 is a database that manages plug-ins for accessing a plurality of clouds and the storage proxy 104. The plug-in 121 for storage proxy, plug-in A125, plug-in B126, and other plug-ins are registered in this database.

  The account database (DB) 123 is a database that manages accounts of a plurality of tenants (users).

  The token database (DB) 124 functions as a second database, and is a database that manages tenant accounts and tokens issued from each cloud in association with each other. The token includes a token issued from the cloud A14, a token issued from the cloud B16, and a token issued from the storage proxy 104.

  The plug-in A125 is a plug-in for accessing the cloud A14 of the plurality of clouds.

  The plug-in B126 is a plug-in for accessing the cloud B16 of the plurality of clouds.

  The relay server 12 includes a CPU, a memory, a storage device, and an input / output interface as a hardware configuration. The CPU implements various processes by reading and executing the processing program stored in the program memory. The main processing is to relay access to the cloud A14 and cloud B16 on the Internet and access to the intra storage 102 in the intranet 10 in response to a request from a user terminal in the intranet. The storage proxy plug-in 121 as the processing means is realized by the CPU reading and executing the storage plug-in program. Although the plug-in DB 122, the account DB 123, and the token DB 124 are realized by a storage device, they are not necessarily the same storage device, and may be realized separately by a plurality of storage devices.

  The storage proxy 104 in the intranet 10 includes a CPU, a memory, a storage device, and an input / output interface as a hardware configuration. The CPU implements various processes by reading and executing the processing program stored in the program memory. The main processing is to issue a token in response to a request from the relay server 12, update the token, and perform user authentication to the intra storage 102 using the token. The account mapping DB 101 and the intra storage 102 are realized by the same or different storage devices.

<Basic processing>
The basic processing of the system in this embodiment is as follows. The administrator of the intranet 10 accesses the storage proxy 104 from within the intranet 10 and registers the storage proxy 104 in the relay server 12.

  The relay server 12 registers information necessary for accessing the storage proxy 104 in the plug-in DB 122 in association with the intranet (tenant) 10. As a result of this registration, when a user belonging to the intranet 10 logs in to the relay server 12, a list of available plug-ins including the registered plug-ins can be acquired, and both the cloud A 14 and the cloud B 16 and the intra intra storage 102 are stored. Can be used.

  In the present embodiment, the storage in the cloud A14, the storage in the cloud B16, and the intra-intra storage 102 can be equivalently used via the relay server 12, and the intra-internal storage 102 is registered in the same manner as registering a document in the storage in the cloud A14. The document can be registered in the intra storage 102 in the same manner as the document is acquired from the storage of the cloud A14. As a matter of course, a user belonging to the intranet 10 can directly access the intra storage 102, but in this embodiment, the intra storage 102 is also connected to the intra storage 102 via the relay server 12 for using the cloud service on the Internet. Accessible.

  Further, the storage proxy 104 issues a token to be used for accessing the intra storage 102 from the relay server 12 for each user, and associates the authentication information for accessing the intra storage 102 with the token to account mapping DB 101. Register with. A token is a special signal or data that means a transmission right that circulates on the network. The user who has acquired the token transmits this token to the relay server 12, and the relay server 12 associates the account with the token and registers them in the token DB 124 in the same manner as in the other cloud A14 and cloud B16. When the user uses the intra storage 102, the relay server 12 acquires the token associated with the intra storage 102 to be accessed from the token DB 124, and the storage proxy plug-in 121 acquires the token. The token is sent to the storage proxy 104. The storage proxy 104 acquires authentication information that matches the received token from the account mapping DB 101, and accesses the intra-storage 102 using the acquired authentication information.

  In the present embodiment, the user also uses the storage proxy plug-in 121 for accessing the intra storage 102 in addition to the plug-in A 125 and plug-in B 126 for accessing the cloud A 14 and the cloud B 16 that are public clouds. Therefore, it is possible to use a storage service on the Internet and an intra-storage service.

  Further, in the present embodiment, the credential information (authentication information) is held in the intranet 10 and is not held in the relay server 12, so that security is also ensured.

  Further, the tenant account of the relay server 12 and the token are associated and registered in the token DB 124, and the user authentication information (user account) and the token are associated and registered in the account mapping DB 101, and the tenant of the relay server 12 is registered. Since the account in the intra and the account in the intra are indirectly associated using a token, even if the tenant account of the relay server 12 is changed, the account is not affected. That is, even if the tenant's account is changed, it is possible to acquire the correct authentication information and access the access destination by specifying the access destination token of the tenant. As long as the token is valid, this embodiment can be said to be a system that can access the intra storage 102 in the same manner as the cloud A14 and the cloud B16 on the Internet regardless of the tenant's account.

  In other words, when an abnormality occurs in the token, for example, when the expiration date is set for the token and the expiration date has expired, or the authentication information (ID and password) of the intra storage 102 itself has been changed. In this case, it means that access to the intra storage 102 is blocked. In this case, in order to use the intra storage 102, it is necessary to reissue or renew the token.

<Detailed processing>
Next, the processing of the system in the present embodiment will be described in order, divided into storage proxy 104 registration, account mapping, use of intra storage 102 (normal), and use of intra storage 102 (abnormal).

<Register storage proxy>
FIG. 2 is a flowchart of processing for registering the storage proxy 104 in the relay server 12. Intra-user, intra-administrator, relay server 12, storage proxy plug-in (SP plug-in) 121, and storage proxy (SP) 104 It is processing of.

  First, the intra administrator registers a tenant with the relay server 12 using a terminal in the intra, and creates a user in the tenant.

  Next, the intra administrator accesses the SP 104 from within the intra using a terminal in the intra, and performs an operation of registering the SP 104 in the relay server 12. At this time, the SP 104 redirects (transfers) to the relay server 12, and the relay server 12 confirms that the intra administrator logs in to the relay server 12 to be a tenant administrator of the relay server 12.

  The intra administrator designates information necessary for accessing the SP 104 after logging in to the relay server 12, and the relay server 12 confirms that the SP 104 can access the SP 104 with the information, and then designates the designated access information with the tenant ID. And registered in the plug-in DB 122. With the above processing, the SP plug-in 121 is registered in the relay server 12, and the SP server can be accessed from the relay server 12 using the SP plug-in 121.

  Next, the user in the intra, that is, the user created in the tenant by the intra administrator logs in to the relay server 12 using the terminal in the intra. The relay server 12 returns a list of available plug-ins registered in the plug-in DB 122 to the user. This plug-in list includes an SP plug-in 121 for using the intra storage 102 in addition to the plug-in A 125 for using the cloud A 14 and the plug-in B 126 for using the cloud B 16.

  As described above, the registration of the SP 104 with the relay server 12 is an intra administrator, that is, a tenant administrator, and is executed from within the tenant's intra, so that the SP 104 is illegally registered and used by an unauthorized tenant. There is no.

<Account mapping>
FIG. 3 is a flowchart of the account mapping process, which is a process of the intra-user, the relay server 12, the SP plug-in 121, the SP 104, and the intra-storage 102. This process is a process after the registration process of SP 104 shown in FIG. 2 is completed.

  First, when an intra user logs in to the relay server 12 using a terminal in the intra and makes a cloud service list acquisition request, the relay server 12 acquires a plug-in list usable by the tenant from the plug-in DB 122. And reply to the intra-user.

  Next, the intra user selects the SP plug-in 121 from the plug-in list and makes a token acquisition request to the relay server 12 to use the intra storage 102.

  The SP plug-in 121 of the relay server 12 redirects (transfers) the token acquisition request to the SP 104.

  Next, the intra-user accesses the SP 104 and performs authentication for accessing the intra-storage 102. In other words, the intra user requests the SP 104 for permission to use, and the SP 104 authenticates the intra storage 102. Since the authentication information is transmitted from the intra-user to the intra-storage 102 via the SP 104, the authentication information does not pass through the relay server 12. However, intra-users cannot access the SP 104 unless they use the SP plug-in 121, and cannot perform account mapping unless they can access the SP 104.

  If the authentication is successful, the SP 104 issues a token that can use the intra storage 102, and registers the issued token and authentication information in association with each other in the account mapping DB 101. The issued token is returned to the intra-user. The token may have an expiration date, and processing when the token expires will be described later.

  The intra-user who acquired the token transmits the token to the relay server 12, and the relay server 12 associates the tenant (user) account with the token and registers them in the token DB 124 in the same manner as other cloud services. The token is given an attribute that makes the intra storage 102 available. If the access destination included in the request from the user terminal is the intra storage 102, the relay server 12 can read the corresponding token from the token DB 124.

  Through the above processing, the token that can use the intra storage 102 associated with the account is registered in the token DB 124 of the relay server 12, and the token associated with the authentication information is registered in the account mapping DB 101 of the intranet 10. . Therefore, the tenant account of the relay server 12 and the authentication information (account) of the user in the intranet 10 are indirectly associated via a token that can use the intra storage 102 issued in the SP 104.

  Here, focusing on the tenant account, the SP plug-in 121 is registered in the plug-in DB 122 of the relay server 12 in association with the tenant account, and the intra-intra site is associated with the tenant account in the token DB 124 of the relay server 12. A token that can use the storage 102 is registered. When the tenant account is changed, the plug-in DB account and the token DB account are changed according to the change, so that the user can correctly use the SP plug-in 121 and the token even in the account after the change.

<Use of intra-storage>
FIG. 4 is a processing flowchart when the intra storage 102 is used (for example, acquisition of a document stored in the intra storage 102), and the user (may be inside or outside the intra). , Processing of the relay server 12, the SP plug-in 121, the SP 104, and the intra storage 102.

  First, when a user logs in to the relay server 12 using a terminal and makes a cloud service list acquisition request, the relay server 12 acquires a plug-in list that can be used by the tenant from the plug-in DB 122, and Send back.

  The user selects the SP plug-in 121 from the plug-in list and makes a document acquisition request.

  The relay server 12 reads an access destination, that is, a token that can use the intra storage 102 from the token DB 124, and the SP plug-in 121 transmits this token to the SP 104 when accessing the SP 104.

  The SP 104 reads authentication information that matches the received token from the account mapping DB 101 and logs in to the intra storage 102 using the read authentication information. If the login is successful, the process according to the request from the user, that is, the document acquisition request is executed, and the requested document is transmitted to the user.

<Token update process>
FIG. 5 is a processing flowchart in the case of using intra storage (for example, registering a document in intra storage 102), in the event of an abnormality such as a token expired or a password has been changed. It is processing. In this case, it is necessary to update the token to make the intra storage 102 available.

  First, the intra user makes a document registration request to the relay server 12.

  The relay server 12 reads the token corresponding to the access destination, that is, the intra storage 102, from the token DB 124, and the SP plug-in 121 passes the token to the SP 104.

  The SP 104 reads the authentication information that matches the token from the account mapping DB 101. At this time, if there is no authentication information that matches the token because the token has expired or the password has been changed, the SP 104 notifies the SP. Return to plug-in 121. The SP plug-in 121, that is, the relay server 12, suspends document registration until the token is updated, and returns a token update request to the intra-user.

  The intra-user receives the token update request from the relay server 12, accesses the SP 104, and makes a token update request. When the user is outside the intra, the SP 104 cannot be accessed, so the token cannot be updated until the user returns to the intra.

  Upon receiving an update request from an intra-user, the SP 104 updates the intra-storage 102 by reissuing a usable token, and re-registers the updated token and authentication information in the account mapping DB 101 in association with each other. A new expiration date is set for the updated token, and new authentication information including the changed password is associated with the updated token.

  When the SP 104 updates the token, the SP 104 returns a message to that effect to the relay server 12 and the intra-user, and the intra-user requests the relay server 12 to update the token. The relay server 12 associates the token updated at SP 104 with the account and re-registers it in the token DB 124. The relay server 12 automatically re-registers the updated token in the token DB 124 and then automatically resumes the pending document registration request, and the SP plug-in 121 passes the updated token to the SP 104 to request document registration. To do. The SP 104 reads authentication information suitable for the received token from the account mapping DB 101, and accesses the intra storage 102 using the read authentication information to perform document registration.

  As described above, even if it is necessary to update the token or change the password in the intra, the request for document registration to the relay server 12 is suspended, and the suspended request is automatically resumed upon completion of the token update. Thus, efficient processing is possible.

  10 intranet (intra), 12 relay server, 14 cloud A, 16 cloud B, 101 account mapping database (DB), 102 intra storage, 103 client (application), 104 storage proxy (SP), 121 plug-in for storage proxy (SP plug-in), 122 plug-in database (DB), 123 account database (DB), 124 token database (DB), 125 plug-in A, 126 plug-in B.

Claims (3)

Within the intranet,
Storage,
A proxy that issues a token associated with authentication information for permitting use of the storage;
A first database that stores the token associated with the authentication information;
Is provided,
To the relay server that accesses the cloud on the Internet from the intranet,
A second database for storing the token in association with an account;
An information processing system provided with processing means for accessing the proxy using the token. The relay server reads the token from the second database and sends it to the proxy when the user terminal requests use of the storage,
The proxy accesses the storage using the authentication information associated with the token from the first database;
The information processing system according to claim 1. The proxy issues an update token when the token is unavailable and stores it in the first database in association with the authentication information;
The relay server stores the update token in the second database in association with the account, and automatically initiates a request from the user terminal that has been suspended when the token is not available. Send a refresh token to the proxy;
The information processing system according to claim 2.

Images