Service management system, token issuing server and its program

Abstract

To prevent performance of a relay device from deteriorating.SOLUTION: A token issuing server comprises an access key storage unit, a token acquisition unit, and a token issuing unit. The access key storage unit stores an access key issued by a relay device. The token acquisition unit acquires an authentication token from the relay device using the access key stored by the access key storage unit. The token issuing unit issues the authentication token acquired by the token acquisition unit to a client in response to a token request from the client. The relay device comprises a token generation unit, a token authentication unit, and a service processing unit. The token generation unit generates an authentication token. The token authentication unit authenticates the authentication token included in a service request from the client. The service processing unit commands a service providing server to execute the service requested by the client after the authentication token is successfully authenticated by the token authentication unit.SELECTED DRAWING: Figure 7

Description

[Technical Field]

[0001] An embodiment of the present invention relates to a service management system, a token issuing server, and a program therefor. [Background technology]

[0002] There is a communication system that uses an API gateway as a relay device that relays communications between clients and service provider servers that provide various services in response to requests from the clients. In this type of communication system, as the number of clients increases, the load on the API gateway increases, and there is a concern that its performance as a relay device will deteriorate. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 5516688 Summary of the Invention [Problem to be solved by the invention]

[0004] The problem that the embodiments of the present invention aim to solve is to provide a service management system and a coupon issuing server associated with the system that can prevent a decline in the performance of a relay device that relays communications between a client and a service providing server. [Means for solving the problem]

[0005] In one embodiment, the service management system includes a service providing server that provides a service consisting of one or more microservices, a relay device that relays communication with clients that use the service, and a token issuing server that communicates with the relay device and the clients. The token issuing server includes an access key storage unit, a token acquisition unit, and a token issuing unit. The access key storage unit stores an access key issued by the relay device. The token acquisition unit acquires an authentication token from the relay device using the access key stored in the access key storage unit. In response to a token request from a client, the token issuing unit issues the authentication token acquired by the token acquisition unit to the client. The relay device includes a token generation unit, a token authentication unit, and a service processing unit. The token generation unit generates an authentication token. The token authentication unit authenticates the authentication token included in a service request from a client. When the token authentication unit authenticates the authentication token, the service processing unit commands the service providing server to execute the service requested by the client. [Brief explanation of the drawings]

[0006] [Figure 1] FIG. 1 is a schematic diagram showing a schematic configuration of a communication system according to an embodiment. [Figure 2] FIG. 2 is a schematic diagram illustrating the functional configuration of the service providing server. [Figure 3] FIG. 3 is a block diagram showing the main functional configuration of the API gateway. [Figure 4] FIG. 4 is a block diagram showing the main functional configuration of the token issuing server. [Figure 5] FIG. 5 is a block diagram showing the circuit configuration of the token issuing server. [Figure 6] FIG. 6 is a flowchart showing the main steps of information processing executed by the processor of the token issuing server in accordance with a control program. [Figure 7] FIG. 7 is a sequence diagram of main data signals exchanged between the token issuing server, API gateway, service providing server, and client in relation to the information processing shown in FIG. DETAILED DESCRIPTION OF THE INVENTION

[0007] An embodiment will be described below with reference to the drawings. In this embodiment, a communication system is exemplified in which an API gateway is applied as a relay device that relays communication between a client and a service providing server.

[0008] [Communication system description] FIG. 1 is a schematic diagram showing the overall configuration of such a communication system 100. The communication system 100 includes a service providing server 30 and multiple clients 40. The communication system 100 is constructed by connecting the API gateway 10, the token issuing server 20, the service providing server 30, and each client 40 to a communication network 50. The communication network 50 is typically the Internet. The communication network may also be an intranet or the like configured using Internet technology. The communication network 50 may also be a mixture of the Internet or an intranet and a LAN (Local Area Network). The LAN may be a wired LAN or a wireless LAN.

[0009] The service providing server 30 is a computer that provides various services in response to requests from the client 40. The service providing server 30 is typically realized by cloud computing technology.

[0010] The client 40 is a computer that can use the services provided by the service providing server 30. For example, a general-purpose electronic device such as a personal computer, a tablet terminal, or a smartphone can be the client 40. When the service providing server 30 provides various services related to a POS (Point Of Sales) application, for example, the client 40 connected with devices such as a scanner, a display, a keyboard, and a card reader becomes a computer that functions as a POS terminal.

[0011] The API gateway 10 functions as a relay device that relays communication between the service providing server 30 and the client 40. The token issuing server 20 communicates with the API gateway 10, which is a relay device, and each client 40 via a communication network 50. The API gateway 10 and the token issuing server 20, which are connected by the communication network 50, constitute a service management system 60.

[0012] [Service provider server description] 2 is a schematic diagram showing the functional configuration of the service providing server 30. The service providing server 30 includes a bundle layer 31, a microservice layer 32, and a database layer 33. The bundle layer 31 is a collection of bundles. A bundle is prepared for each type of service that may be requested by the client 40. A bundle is an architecture that links two or more microservices to provide a service requested by the client 40. A bundle may also be an architecture that provides a service requested by the client 40 with one microservice.

[0013] The microservice layer 32 is a collection of microservices. A microservice is an application that runs one service as one process. A microservice processes one service by referencing one or more databases. A microservice may also process one service without referencing a database.

[0014] The database layer 33 is a collection of databases. A database is a collection of data that is referenced when a microservice is running. Databases exist for different types of data. Note that one database may be shared and referenced by different microservices.

[0015] As an example, if the service providing server 30 provides various services related to a POS (Point Of Sales) application, the bundles constructed in the bundle layer 31 are assumed to be bundle A for a product registration request, bundle B for a transaction settlement request, etc.

[0016] Bundle A provides a service to client 40 in response to a product registration request by linking, for example, microservice Aa, which analyzes barcodes by referring to a database of barcode conversion parameters; microservice Ab, which references a product master database using the product code obtained by barcode analysis to obtain product data such as product name and unit price; and microservice Ac, which registers product sales data in a transaction file database based on the obtained product data.

[0017] Bundle B provides services to client 40 in response to transaction settlement requests by linking with microserver Ba, which retrieves transaction data for which settlement has been requested from a transaction file database, and microserver Bb, which performs accounting processing based on the transaction data and registers sales data in the sales file database.

[0018] [API Gateway Description] 3 is a block diagram showing the main functional configuration of the API gateway 10. The API gateway 10 mainly has functions as a first server communication unit 11, a second server communication unit 12, a client communication unit 13, an access key generation unit 14, a token generation unit 15, a token authentication unit 16, and a service processing unit 17.

[0019] The first server communication unit 11 performs data communication with the token issuing server 20 via the communication network 50. The second server communication unit 12 performs data communication with the service providing server 30 via the communication network 50. The client communication unit 13 performs data communication with the client 40 via the communication network 50.

[0020] The access key generation unit 14 generates an access key, which is an authentication key for accessing the API gateway 10. The access key may also be referred to as a consumer key, etc. In this embodiment, the access key is used by the token issuing server 20, which will be described later as an example, to access the API gateway 10. The token generation unit 15 generates an authentication token that is valid for a limited time, such as 10 minutes, 20 minutes, or 30 minutes. The token authentication unit 16 authenticates the authentication token attached to a service request from the client 40. The service processing unit 17 outputs a service request for which the authentication token has been authenticated to the service providing server 30, and executes processing to output a result response to the service request to the client 40 that made the service request.

[0021] [Token issuing server description] 4 is a block diagram showing the main functional configuration of the token issuing server 20. The token issuing server 20 mainly has functions as a gateway communication unit 21, a client communication unit 22, an access key storage unit 23, a token storage unit 24, a client information storage unit 25, an access key acquisition unit 26, a token acquisition unit 27, a client authentication unit 28, and a token issuing unit 29.

[0022] The gateway communication unit 21 performs data communication with the API gateway 10 via the communication network 50. The gateway communication unit 21 functions as a first communication unit. The client communication unit 22 performs data communication with the client 40 via the communication network 50. The client communication unit 22 functions as a second communication unit.

[0023] The access key storage unit 23 stores an access key. The token storage unit 24 stores an authentication token. The client information storage unit 25 stores a unique ID and a password set for each client 40 in association with each other.

[0024] The access key acquisition unit 26 acquires the access key generated in the API gateway 10 and writes it to the access key storage unit 23. The token acquisition unit 27 acquires the authentication token generated in the API gateway 10 and writes it to the token storage unit 24. The client authentication unit 28 authenticates the client 40 by comparing the ID and password received from the client 40 with the information stored in the client information storage unit 25. The client authentication unit 28 issues an authentication token to be stored in the token storage unit 24 to the client 40 that has been authenticated.

[0025] 5 is a block diagram showing the circuit configuration of the token issuing server 20. The token issuing server 20 includes a processor 201, a main memory 202, an auxiliary storage device 203, a timer 204, a communication interface 205, etc. In the token issuing server 20, the processor 201, the main memory 202, the auxiliary storage device 203, the timer 204, and the communication interface 205 are connected via a system bus 206. The system bus 206 includes an address bus, a data bus, etc. In the token issuing server 20, the processor 201, the main memory 202, the auxiliary storage device 203, the timer 204, and the communication interface 205 are connected via the system bus 206 to form a computer.

[0026] The processor 201 corresponds to the central part of the computer. The processor 201 controls each part to realize various functions of the token issuing server 20 in accordance with an operating system or an application program. The processor 201 includes an internal cache memory 207. The processor 201 is, for example, a CPU (Central Processing Unit).

[0027] The main memory 202 corresponds to the main storage portion of the computer. The main memory 202 includes a nonvolatile memory area and a volatile memory area. The main memory 202 stores an operating system or application programs in the nonvolatile memory area. The main memory 202 stores data required for the processor 201 to execute processes for controlling each unit in the volatile memory area. The main memory 202 also uses the volatile memory area as a work area where data is rewritten by the processor 201 as appropriate. The nonvolatile memory area is, for example, ROM (Read Only Memory). The volatile memory area is, for example, RAM (Random Access Memory).

[0028] The auxiliary storage device 203 corresponds to the auxiliary storage portion of the computer. As the auxiliary storage device 203, well-known storage devices such as an EEPROM (Electric Erasable Programmable Read-Only Memory), an HDD (Hard Disc Drive), or an SSD (Solid State Drive) may be used singly or in combination. The auxiliary storage device 203 stores data used by the processor 201 when performing various processes, data generated by the processes in the processor 201, etc. The auxiliary storage device 203 may also store application programs.

[0029] The main memory 202 and the auxiliary storage device 203 are storage devices built into the token issuing server 20. The auxiliary storage device 203 may be a storage device external to the token issuing server 20.

[0030] The application programs stored in the main memory 202 or the auxiliary storage device 203 include a control program, which will be described later. There are no particular limitations on the method for installing the control program in the main memory 202 or the auxiliary storage device 203. The control program can be installed in the main memory 202 or the auxiliary storage device 203 by recording it on a removable recording medium or by distributing it via communication over a network. The recording medium can be in any form, such as a CD-ROM or memory card, as long as it can store the program and is readable by the device.

[0031] The timer 204 measures a time set by the processor 201. The timer 204 outputs a time-out signal to the processor 201 when the time it measures reaches the set time.

[0032] The communication interface 205 connects to the communication network 50. The token issuing server 20 performs data communication with the API gateway 10 and each client 40 connected to the communication network 50 via the communication interface 205. In other words, the communication interface 205 is hardware that realizes the functions of the gateway communication unit 21 and the client communication unit 22.

[0033] The token issuing server 20 uses part of the storage area of ​​the main memory 202 or the auxiliary storage device 203 as an area for the access key storage unit 23 and the client information storage unit 25. In other words, the main memory 202 or the auxiliary storage device 203 is hardware that realizes the functions of the access key storage unit 23 and the client information storage unit 25.

[0034] The token issuing server 20 uses a part of the storage area of ​​the cache memory 207 as an area serving as the token storage unit 24. In other words, the cache memory 207 is hardware that realizes the function of the token storage unit 24.

[0035] The token issuing server 20 realizes the functions of an access key acquiring unit 26, a token acquiring unit 27, a client authenticating unit 28, and a token issuing unit 29 by the processor 201 executing predetermined information processing in accordance with a control program. In other words, the processor 201 is hardware for realizing the functions of the token acquiring unit 27, the client authenticating unit 28, and the token issuing unit 29.

[0036] [Service Management System Description] Fig. 6 is a flowchart showing the main steps of information processing executed by the processor 201 of the token issuing server 20 in accordance with a control program. Fig. 7 is a sequence diagram of data signals exchanged between the token issuing server 20, API gateway 10, service providing server 30, and client 40 in relation to this information processing. The main operations of the service management system will be explained below using each diagram. Note that the information processing steps shown in the flowcharts are not limited to those shown. They can be modified as appropriate as long as similar operational effects are obtained.

[0037] In ACT1, the processor 201 of the token issuing server 20 checks whether an access key is stored in the access key storage unit 23. If an access key is not stored, the processor 201 proceeds to ACT2. In ACT2, the processor 201 requests an access key from the API gateway 10 using the function of the access key acquisition unit 26. Specifically, the processor 201 transmits a command signal requesting an access key from the gateway communication unit 21 to the API gateway 10.

[0038] Upon receiving this command signal, the API gateway 10 transmits a response signal including the access key generated in the access key generating unit 14 to the token issuing server 20 via the first server communication unit 11.

[0039] The processor 201 of the token issuing server 20 that transmitted the command signal waits for a response signal in ACT3. When the response signal is received via the gateway communication unit 21, the processor 201 proceeds to ACT4. In ACT4, the processor 201 overwrites the access key included in the response signal in the access key storage unit 23 by using the function of the access key acquisition unit 26, and stores the access key. Thereafter, the processor 201 proceeds to ACT5.

[0040] The processor 201 checks whether it is time to acquire an authentication token as ACT5. If an authentication token is not stored in the token storage unit 24, the processor 201 determines that it is time to acquire an authentication token. If an authentication token is stored in the token storage unit 24, the processor 201 determines that it is time to acquire an authentication token when the validity period of the authentication token has elapsed. The validity period is measured by the timer 204.

[0041] If it is not time to obtain an authentication token, the processor 201 proceeds to ACT 6. In ACT 6, the processor 201 checks whether or not there is a request from the client 40 to obtain an authentication token.

[0042] The client 40 needs to obtain an authentication token before using a service provided by the service providing server 30. When the client 40 needs to obtain an authentication token, the client 40 transmits a command signal Sc (see FIG. 7) to the token issuing server 20 requesting an authentication token.

[0043] If there is no request to obtain an authentication token from any of the clients 40, the processor 201 returns to ACT1. In ACT1, the processor 201 checks whether an access key is stored in the access key storage unit 23. At this point, the access key is stored in the access key storage unit 23. Therefore, the processor 201 proceeds to ACT7. In ACT7, the processor 201 checks whether the access key generated in the API gateway 10 has been changed.

[0044] The API gateway 10 holds an access key generated by the access key generation unit 14. However, for some reason, the held access key may be lost. If the access key is lost, the API gateway 10 generates a new access key by the access key generation unit 14. Because the access key generation unit 14 generates the access key randomly, the newly generated access key will not match the lost access key. In other words, the access key is changed.

[0045] If the access key has not been changed, the processor 201 of the token issuing server 20 proceeds to ACT 5. That is, the processor 201 checks whether it is time to obtain an authentication token. If it is not time to obtain an authentication token, the processor 201 checks whether there is a request from the client 40 to obtain an authentication token.

[0046] In this way, while the access key stored in the access key memory unit 23 is not changed, the processor 201 waits in ACT5 and ACT6 for the timing to obtain an authentication token or for receiving a request to obtain an authentication token from the client 40.

[0047] In ACT5, when it is time to acquire an authentication token, the processor 201 proceeds to ACT8. In ACT8, the processor 201 accesses the API gateway 10 using the access key stored in the access key storage unit 23. Then, in ACT9, the processor 201 requests a token from the API gateway 10 using the function of the token acquisition unit 27. Specifically, the processor 201 transmits a command signal Sa (see FIG. 7) requesting a token from the gateway communication unit 21 to the API gateway 10.

[0048] Upon receiving this command signal Sa, the API gateway 10 transmits a response signal Sb (see FIG. 7) including the authentication token generated in the token generation unit 15 to the token issuing server 20 via the first server communication unit 11.

[0049] The processor 201 that requested the token waits for a response signal Sb in ACT10. When the processor 201 receives the response signal Sb via the gateway communication unit 21, the processor 201 proceeds to ACT11. In ACT11, the processor 201 overwrites the authentication token included in the response signal Sb in the token storage unit 24 using the function of the token acquisition unit 27 and stores it. Thereafter, the processor 201 returns to ACT1. Then, if the access key has not been changed, the processor 201 waits for the timing to acquire an authentication token to arrive or for receiving a request to acquire an authentication token from the client 40. In this waiting state, when the timing to acquire an authentication token arrives again, the processor 201 executes the processes of ACT8 to ACT11 in the same manner as described above.

[0050] 7, a command signal Sa requesting a token is periodically sent from the token issuing server 20 to the API gateway 10. In response to this command signal Sa, the API gateway 10 returns a response signal Sb including the current authentication token to the token issuing server 20. In this way, the token issuing server 20 always stores the latest authentication token created in the API gateway 10.

[0051] When the processor 201 receives a command signal Sc (see FIG. 7) requesting an authentication token via the client communication unit 22 in ACT6, the process proceeds to ACT12. In ACT12, the processor 201 authenticates the client 40 that is the sender of the command signal Sc using the function of the client authentication unit 28. Specifically, the command signal Sc includes an ID and a password that are set for each client 40. The processor 201 checks whether or not the combination of the ID and password is stored in the client information storage unit 25. If the client information storage unit 25 stores information that matches the combination of the ID and password included in the command signal Sc, the client 40 is authenticated. In ACT13, the processor 201 checks whether or not authentication of the client 40 is successful. If authentication of the client 40 is not successful, the processor 201 invalidates the command signal Sc and returns to ACT1.

[0052] If the authentication of the client 40 is successful, the processor 201 proceeds to ACT14. In ACT14, the processor 201 reads the authentication token stored in the token storage unit 24 using the function of the token issuing unit 29. Then, in ACT15, the processor 201 controls the function of the token issuing unit 29 to transmit the authentication token to the client 40 that sent the command signal Sc. This control causes the client communication unit 22 to transmit a response signal Sd (see FIG. 7) including the authentication token to the corresponding client 40. After controlling the transmission of the authentication token, the processor 201 returns to ACT1. If the access key has not been changed, the processor 201 waits for the timing to acquire an authentication token or for a request to acquire an authentication token to be received from the client 40. In this standby state, when a request to acquire an authentication token is received again from any of the clients 40, the processor 201 executes the processes of ACT12 to ACT15 in the same manner as described above.

[0053] Through the above operations, the client 40 that transmitted the command signal Sc requesting an authentication token receives a response signal Sd including the current authentication token from the token issuing server 20. Then, upon receiving the response signal Sd, the client 40 transmits a command signal Se (see FIG. 7) requesting a desired service to the API gateway 10. The command signal Se includes the authentication token acquired from the token issuing server 20.

[0054] When the API gateway 10 receives a command signal Se via the client communication unit 13, it authenticates the authentication token included in the command signal Se using the function of the token authentication unit 16. If the authentication token matches the authentication token generated by the token generation unit 15 and stored, the API gateway 10 determines that authentication is successful. If the authentication token included in the command signal Se does not match the stored authentication token, the authentication is not successful.

[0055] If the authentication token is authenticated, the API gateway 10, using the function of the service processing unit 17, transfers the command signal Se received from the client 40 to the service providing server 30. The service providing server 30 executes the service requested by the command signal Se and transmits a response signal Sf (see FIG. 7 ) indicating the execution result of the service to the API gateway 10. Using the function of the service processing unit 17, the API gateway 10 transmits the response signal Sf indicating the execution result of the service to the requesting client 40. In this way, the client 40 can use the service provided by the service providing server 30.

[0056] [Effect description] As described above in detail, the service management system 60 includes not only the API gateway 10 that functions as a relay device that relays communication between the client 40 and the service providing server 30, but also the token issuing server 20.

[0057] The token issuing server 20 acquires an access key generated in the API gateway 10 and stores it in the access key storage unit 23. The token issuing server 20 then periodically accesses the API gateway 10 using the access key stored in the access key storage unit 23, acquires an authentication token generated in the API gateway 10 and updated as needed, and stores it in the token storage unit 24.

[0058] The token issuing server 20 also accepts a command requesting acquisition of an authentication token from each client 40. The token issuing server 20 then issues the authentication token stored in the token storage unit 24 to the client 40 that has made the acquisition request. The client 40 that has received the issued authentication token uses the authentication token to access the API gateway 10 and request a service. At this time, the authentication token issued by the token issuing server 20 is the latest one, so authentication of the authentication token is established in the API gateway 10. A service request is then made to the service providing server 30 via the API gateway 10, and the execution result of the service is notified to the client 40.

[0059] As described above, in this embodiment, the token issuing server 20 stores the access key generated in the API gateway 10. Incidentally, in a conventional communication system that does not include the token issuing server 20, each client 40 stores the access key. The client 40 has no way of checking whether the access key has been changed. Furthermore, due to security issues, it may be difficult for an external server or other external entity to identify the client 40 or even to change the access key of an identified client 40. For this reason, the access key stored in the client 40 cannot be easily modified. Therefore, even if the access key held by the API gateway 10 is lost for some reason and is regenerated, the client 40 will not know the new access key. As a result, the client 40 attempts to access the API gateway 10 using the old access key, and the access is denied.

[0060] In contrast, in this embodiment, the client 40 does not need an access key to access the API gateway 10. The client 40 can obtain the latest authentication token from the token issuing server 20 without using an access key. Therefore, the client 40 will not be denied access to the API gateway 10 because the access key held by the API gateway 10 has been rewritten.

[0061] On the other hand, in this embodiment, the token issuing server 20 periodically accesses the API gateway 10 using an access key, and obtains and stores the latest authentication token from the API gateway 10. Each client 40 then accesses the token issuing server 20, not the API gateway 10, to obtain the latest authentication token. In this way, by providing the token issuing server 20, access from each client 40 is distributed between the token issuing server 20 and the API gateway 10. As a result, even if the number of clients 40 increases significantly, concerns about an increase in the load on the API gateway 10 and a decrease in its performance as a relay device are avoided. In other words, a service management system 60 equipped with the token issuing server 20 can appropriately handle an increase in the number of clients 40.

[0062] Furthermore, in this embodiment, an ID and a password are set for each client 40, and the token issuing server 20 stores information about the ID and password. When a client 40 requests an authentication token, the token issuing server 20 determines the validity of the client 40 using the ID and password notified by the client 40. Therefore, there is no inconvenience of issuing an authentication token to an abnormal client 40 whose validity has not been recognized, and the reliability of the system is not impaired.

[0063] [Variations] In the above embodiment, a part of the storage area of ​​the cache memory 207 is used as the area for the token storage unit 24. In this regard, a part of the storage area of ​​the main memory 202 or the auxiliary storage device 203 may be used as the area for the token storage unit 24.

[0064] In the above embodiment, an ID and a password are exemplified as information for authenticating the validity of the client 40. However, the information for authenticating the validity is not limited to an ID and a password. For example, the token issuing server 20 may authenticate the validity based on only the ID of the client 40.

[0065] Although several embodiments of the present invention have been described, these embodiments are presented as examples and are not intended to limit the scope of the invention. These novel embodiments can be embodied in various other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their modifications are included within the scope of the invention and the scope of the inventions and their equivalents as defined in the claims. The inventions described in the original claims of this application are set forth below. [1] A service management system including: a relay device that relays communication between a service providing server that provides a service consisting of one or more microservices and a client that uses the service; and a token issuing server that communicates with the relay device and the client, wherein the token issuing server includes an access key storage unit that stores an access key issued by the relay device, a token acquisition unit that acquires an authentication token from the relay device using the access key stored in the access key storage unit, and a token issuing unit that issues the authentication token acquired by the token acquisition unit to the client in response to a token request from the client, and the relay device includes a token generation unit that generates the authentication token, a token authentication unit that authenticates the authentication token included in a service request from the client, and a service processing unit that, when authentication of the authentication token is successful in the token authentication unit, commands the service providing server to execute the service requested by the client. [2] A token issuing server comprising: a first communication unit that communicates with a relay device that relays communication between a service providing server that provides a service consisting of one or more microservices and a client that uses the service; a second communication unit that communicates with the client; an access key storage unit that stores an access key issued by the relay device; a token acquisition unit that acquires an authentication token from the relay device using the access key stored in the access key storage unit; and a token issuing unit that issues the authentication token acquired by the token acquisition unit to the client in response to a token request from the client. [3] A token issuing server as described in appendix [2], further comprising a token memory unit that stores the authentication token acquired by the token acquisition unit, wherein the token acquisition unit periodically acquires the authentication token from the relay device and updates the data in the token memory unit. [4] A token issuing server as described in appendix [2] or [3], further comprising a client authentication unit that authenticates the client that is requesting the service, and the token issuing unit issues the authentication token when authentication of the client is successful in the client authentication unit. [5] A token issuing server according to any one of appendices [2] to [4], further comprising an access key acquisition unit that acquires the access key from the relay device, and the access key storage unit stores the access key acquired by the access key acquisition unit. [6] A program for enabling a computer having a first communication unit that communicates with a relay device that relays communication between a service providing server that provides a service consisting of one or more microservices and a client that uses the service, and a second communication unit that communicates with the client, to implement the following functions: storing an access key issued by the relay device in a memory unit; obtaining an authentication token from the relay device using the access key stored in the memory unit; and issuing the obtained authentication token to the client in response to a token request from the client. [Explanation of symbols]

[0066] 10...API gateway, 11...first server communication unit, 12...second server communication unit, 13...client communication unit, 14...access key generation unit, 15...token generation unit, 16...token authentication unit, 17...service processing unit, 20...token issuing server, 21...gateway communication unit, 22...client communication unit, 23...access key memory unit, 24...token memory unit, 25...client information memory unit, 26...access key acquisition unit, 27...token acquisition unit, 28...client authentication unit, 29...token issuing unit, 30...service providing server, 40...client, 50...communication network, 100...communication system, 201...processor, 202...main memory, 203...auxiliary storage device, 204...timer, 205...communication interface.

Claims

1. a relay device that relays communication between a service providing server that provides a service composed of one or more microservices and a client that uses the service; a token issuing server that communicates with the relay device and the client; Including, The token issuing server an access key storage unit that stores an access key issued by the relay device; a token acquisition unit that acquires an authentication token from the relay device using the access key stored in the access key storage unit; a token issuing unit that issues the authentication token acquired by the token acquiring unit to the client in response to a token request from the client; Equipped with The relay device a token generation unit that generates the authentication token; a token authentication unit that authenticates the authentication token included in the service request from the client; a service processing unit that instructs the service providing server to execute a service requested by the client when the authentication of the authentication token is successful in the token authentication unit; A service management system comprising:

2. a first communication unit that communicates with a relay device that relays communication between a service providing server that provides a service configured from one or more microservices and a client that uses the service; a second communication unit that communicates with the client; an access key storage unit that stores an access key issued by the relay device; a token storage unit that stores an authentication token; a token acquisition unit that periodically acquires the authentication token from the relay device by using the access key stored in the access key storage unit and updates data in the token storage unit; a token issuing unit that issues the authentication token stored in the token storage unit to the client in response to a token request from the client; A token issuing server comprising:

3. A first communication unit that communicates with a relay device that relays communication between a service providing server that provides a service consisting of one or more microservices and a client that uses the service; a second communication unit that communicates with the client; an access key storage unit that stores an access key issued by the relay device; a token acquisition unit that acquires an authentication token from the relay device using the access key stored in the access key storage unit; a token issuing unit that issues the authentication token acquired by the token acquiring unit to the client in response to a token request from the client; a client authentication unit that authenticates the client that is a service request source; Equipped with The token issuing unit is a token issuing server that issues the authentication token when the client is authenticated by the client authentication unit.

4. A first communication unit that communicates with a relay device that relays communication between a service providing server that provides a service consisting of one or more microservices and a client that uses the service; a second communication unit that communicates with the client; an access key storage unit that stores an access key issued by the relay device; a token storage unit that stores an authentication token; a token acquisition unit that periodically acquires the authentication token from the relay device by using the access key stored in the access key storage unit and updates data in the token storage unit; a token issuing unit that issues the authentication token stored in the token storage unit to the client in response to a token request from the client; a client authentication unit that authenticates the client that is a service request source; Equipped with The token issuing unit is a token issuing server that issues the authentication token when the client is authenticated by the client authentication unit.

5. an access key acquisition unit that acquires the access key from the relay device; Further comprising: The token issuing server according to claim 2 , wherein the access key storage unit stores the access key acquired by the access key acquisition unit.

6. A computer including a first communication unit that communicates with a relay device that relays communication between a service providing server that provides a service composed of one or more microservices and a client that uses the service, and a second communication unit that communicates with the client, a function of storing an access key issued by the relay device in a storage unit; a function of acquiring an authentication token from the relay device using the access key stored in the storage unit; and a function of issuing the acquired authentication token to the client in response to a token request from the client; A program to achieve this.

Images