Service management system, token issuance server and storage medium

Abstract

The present invention discloses a service management system, a token issuing server and a storage medium, which can prevent the performance of a relay device from being degraded. 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 the access key issued by the relay device. The token acquisition unit uses the access key stored in the access key storage unit to obtain an authentication token from the relay device. The token issuing unit issues the authentication token obtained by the token acquisition unit to the client based on a token request from 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 contained in the service request from the client. When the authentication of the authentication token is established in the token authentication unit, the service processing unit issues an instruction to the service providing server to execute the service requested from the client.

Description

[0001] This application claims priority from Japanese patent application No. JP2021-203285, filed on December 15, 2021, and citing the contents of the aforementioned application, the disclosure of which is hereby incorporated by reference in its entirety. Technical Field

[0002] Embodiments of the present invention relate to a service management system, a token issuing server and a storage medium. Background Art

[0003] A communication system using an API gateway is a relay device that mediates communication between clients and service providers that provide various services based on requests from the clients. In such a communication system, as the number of clients increases, the load on the API gateway increases, which raises concerns about performance degradation as a relay device. Summary of the Invention

[0004] In view of the above problems, the technical problem to be solved by the present invention is to provide a service management system and a token issuing server involved in the system that can prevent the performance degradation of a relay device that relays communication between a client and a service providing server.

[0005] To address the above-mentioned issues, a service management system in an embodiment of the present invention includes a relay device and a token issuing server. The relay device relays communication between a service providing server and a client utilizing the service. The service providing server provides a service consisting of one or more microservices, and the token issuing server communicates with the relay device and the client. 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 access keys issued by the relay device. The token acquisition unit uses the access keys stored in the access key storage unit to obtain an authentication token from the relay device. The token issuing unit issues the authentication token obtained by the token acquisition unit to the client in response to a token request from 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 the service request from the client. When the token authentication unit successfully authenticates the authentication token, the service processing unit issues an instruction to the service providing server to execute the service requested by the client.

[0006] According to the above-described service management system, it is possible to provide a service management system capable of preventing degradation in the performance of a relay device that relays communication between a client and a service providing server.

[0007] In the above-mentioned service management system, the token issuing server also includes: a token storage unit, which stores the authentication token obtained by the token acquisition unit, wherein the token acquisition unit periodically obtains the authentication token from the relay device and updates the data of the token storage unit, and the token generation unit of the relay device periodically generates the authentication token.

[0008] According to the above-described service management system, it is possible to promptly respond to a request for an authentication token from a client.

[0009] In the above-mentioned service management system, the token issuing server also includes: an access key acquisition unit, which obtains the access key from the relay device, wherein the access key storage unit stores the access key obtained by the access key acquisition unit, and the relay device also includes: an access key sending unit, which sends the access key to the token issuing server.

[0010] According to the above-mentioned service management system, the access key can be acquired from the relay device and stored.

[0011] In the above-mentioned service management system, the token issuing server also includes: a change confirmation unit, which confirms whether the access key of the relay device has been changed, wherein when the change confirmation unit confirms that the access key has been changed, the access key acquisition unit obtains a new access key, and the relay device also includes: a disappearance detection unit, which detects the disappearance of the access key, wherein when the disappearance detection unit detects that the access key has disappeared, the access key generation unit generates a new access key, and the access key sending unit sends the new access key.

[0012] According to the above-described service management system, when the access key of the relay device is changed, the changed access key can be acquired.

[0013] Another aspect of the present invention provides a token issuing server, comprising: a first communication unit, communicating with a relay device, the relay device relaying communication between a service providing server that provides a service consisting of one or more microservices and a client that utilizes the service; a second communication unit, communicating with the client; an access key storage unit, storing an access key issued by the relay device; a token acquisition unit, using the access key stored in the access key storage unit to obtain an authentication token from the relay device; and a token issuing unit, issuing the authentication token obtained by the token acquisition unit to the client in response to a token request from the client.

[0014] According to the above-described token issuing server, it is possible to provide a token issuing server capable of preventing degradation in the performance of a relay device that relays communication between a client and a service providing server.

[0015] The token issuing server further includes a token storage 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 data in the token storage unit.

[0016] According to the above-described token issuing server, it is possible to promptly respond to a request for an authentication token from a client.

[0017] The token issuing server further includes a client authentication unit for authenticating the client that is a service request source, wherein the token issuing unit issues the authentication token when the client authentication unit successfully authenticates the client.

[0018] According to the above-described token issuing server, it is possible to prevent an authentication token from being issued to an abnormal client.

[0019] The token issuing server further includes an access key acquisition unit that acquires the access key from the relay device, wherein the access key storage unit stores the access key acquired by the access key acquisition unit.

[0020] According to the above-mentioned token issuing server, it is possible to obtain and store the access key from the relay device.

[0021] The token issuing server further includes a change confirmation unit for confirming whether the access key of the relay device has been changed, and when the change confirmation unit confirms that the access key has been changed, the access key acquisition unit acquires the changed access key.

[0022] According to the above-described token issuing server, when the access key of the relay device has been changed, the changed access key can be acquired.

[0023] A storage medium according to another aspect of the present invention stores a program for enabling a computer including a first communication unit and a second communication unit to implement the following functions, wherein the first communication unit 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 utilizes the service, and the second communication unit communicates with the client, and the functions include: a function of storing an access key issued by the relay device in a storage unit; a function of obtaining an authentication token from the relay device using the access key stored in the storage unit; and a function of issuing the obtained authentication token to the client based on a token request from the client.

[0024] According to the above-described storage medium, it is possible to provide a computer with a function capable of preventing a degradation in the performance of a relay device that relays communication between a client and a service providing server. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 is a schematic diagram showing a general configuration of a communication system according to an embodiment;

[0026] Figure 2 It is a schematic diagram showing the functional configuration of a service providing server;

[0027] Figure 3 It is a block diagram showing the main functional components of the API gateway;

[0028] Figure 4 It is a block diagram showing the main functional components of the token issuance server;

[0029] Figure 5 is a block diagram showing the circuit configuration of a token issuance server;

[0030] Figure 6 is a flowchart showing the main sequence of information processing performed by the processor of the token issuing server in accordance with the control program; and

[0031] Figure 7 is with Figure 6 The information processing shown is related to the timing diagram of the main data signals exchanged between the token issuing server, API gateway, service provider server and client.

[0032] Description of Reference Numerals

[0033] 10 API Gateway 11 First Server Communication Unit 12 Second Server Communication Unit

[0034] 13 Client communication unit 14 Access key generation unit 15 Token generation unit

[0035] 16 Token Authentication Unit 17 Service Processing Unit 20 Token Issuing Server

[0036] 21 Gateway communication unit 22 Client communication unit 23 Access key storage unit

[0037] 24 Token storage unit 25 Client information storage unit 26 Access key acquisition unit

[0038] 27 Token acquisition unit 28 Client authentication unit 29 Token issuance unit

[0039] 30 Service provider server 40 Client 50 Communication network

[0040] 100 Communication system 201 Processor 202 Main memory

[0041] 203 auxiliary storage device 204 clock 205 communication interface DETAILED DESCRIPTION

[0042] Hereinafter, an embodiment will be described using the drawings.

[0043] Furthermore, this embodiment exemplifies a communication system in which an API gateway is applied as a relay device for relaying communication between a client and a service providing server.

[0044] [Description of the communication system]

[0045] Figure 1 It is a schematic diagram showing the general structure of the relevant communication system 100. The communication system 100 includes a service providing server 30 and multiple clients 40. The communication system 100 connects the API gateway 10, the token issuing server 20, the service providing server 30 and each client 40 to a communication network 50 to form a system. The communication network 50 is typically the Internet. The communication network 50 can also be an intranet constructed by applying Internet technology. In addition, the communication network 50 can also be a mixture of the Internet or an intranet and a LAN (Local Area Network). The LAN can be either a wired LAN or a wireless LAN. In particular, the API gateway 10 and the token issuing server 20 that constitute the service management system 60 can also be directly connected through a LAN of a dedicated line different from the communication network 50. By doing so, the security of the information of the service management system is improved.

[0046] 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 implemented using cloud computing technology.

[0047] The client 40 is a computer capable of utilizing services provided by the service providing server 30. For example, a general-purpose electronic device such as a computer, tablet terminal, or smartphone can serve as a client. For example, when the service providing server 30 provides various services related to POS (Point of Sales) applications, the client 40, connected to devices such as a scanner, display, keyboard, and card reader, functions as a POS terminal.

[0048] The API gateway 10 functions as a relay device for communication between the service provider server 30 and the client 40. The token issuing server 20 communicates with the API gateway 10, acting as a relay device, and each client 40 via a communication network 50. Here, the API gateway 10 and the token issuing server 20, connected by the communication network 50, constitute a service management system 60. That is, the service management system 60 is typically provided by the same system provider and is managed as a whole. Therefore, the information security of the token issuing server 20 and the API gateway 10 is high.

[0049] [Description of the service provider server]

[0050] Figure 2 3 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.

[0051] The binding layer 31 is a collection of bindings. A binding is prepared for each type of service that can be requested from the client 40. A binding is an architecture that enables two or more microservices to collaborate and provide services requested from the client 40. Alternatively, a binding can be an architecture that provides a service requested from the client 40 with a single microservice.

[0052] The microservice layer 32 is a collection of microservices. A microservice is an application that operates as a process. Microservices reference one or more databases to process a service. Microservices can also process a service without referencing a database.

[0053] The database layer 33 is a collection of databases. A database is a collection of data referenced by microservices when they operate. Databases exist by data type. Furthermore, different microservices can share and reference a single database.

[0054] As an example, when the service providing server 30 provides various services related to a POS (Point Of Sales) application, the bindings constructed by the binding layer 31 are assumed to be binding A for a product registration request and binding B for a transaction settlement request.

[0055] Binding A, for example, enables microservice Aa to parse barcodes with reference to a database of barcode conversion parameters, microservice Ab to obtain product data such as product name and unit price by referring to a database of product master files using the product code obtained through barcode parsing, and microservice Ac to register product sales data in a database of transaction files based on the obtained product data, and provides services for product registration requests to client 40.

[0056] Binding B enables microservice Ba, which obtains transaction data with settlement requests from the transaction file database, and microservice Bb, which performs settlement processing based on the transaction data and registers sales data in the sales file database, to collaborate and provide services for transaction settlement requests to client 40.

[0057] [Description of API Gateway]

[0058] Figure 3 This is a block diagram showing the main functional configuration of the API gateway 10. The API gateway 10 mainly 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.

[0059] The first server communication unit 11 communicates data with the token issuing server 20 via the communication network 50. Alternatively, as described above, the first server communication unit 11 may be directly connected to the token issuing server 20 via a dedicated LAN line. The second server communication unit 12 communicates data with the service providing server 30 via the communication network 50. The client communication unit 13 communicates data with the client 40 via the communication network 50.

[0060] The access key generation unit 14 generates an access key as an authentication key for accessing the API gateway 10. The access key is saved in order to send the generated access key to the token issuing server 20. The access key is sometimes also called a consumer key, etc. In this embodiment, as an example, the access key is used in order for the token issuing server 20 described later to request an authentication token from the API gateway 10. The token generation unit 15 generates an authentication token that is valid only for a limited time such as 10 minutes, 20 minutes, 30 minutes, etc. The token authentication unit 16 authenticates the authentication token attached to the service request from the client 40. The service processing unit 17 outputs the service request for which the authentication of the authentication token has been established to the service providing server 30, and performs a process of outputting a result response to the service request to the client 40 of the service request source.

[0061] [Token Issuing Server Description]

[0062] Figure 4 This is a block diagram showing the main functional configuration of the token issuing server 20. The token issuing server 20 mainly 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.

[0063] The gateway communication unit 21 communicates data with the API gateway 10 via the communication network 50. Alternatively, as described above, the gateway communication unit 21 may be directly connected to the API gateway 10 via a dedicated LAN line. The gateway communication unit 21 functions as a first communication unit. The client communication unit 22 communicates data with the client 40 via the communication network 50. The client communication unit 22 functions as a second communication unit.

[0064] The access key storage unit 23 stores access keys. The token storage unit 24 stores authentication tokens. The client information storage unit 25 stores unique IDs and passwords set for each client 40 in association with each other.

[0065] Access key acquisition unit 26 acquires the access key generated by API gateway 10 and writes it to access key storage unit 23. Token acquisition unit 27 acquires the authentication token generated by API gateway 10 and writes it to token storage unit 24. Client authentication unit 28 compares the ID and password received from client 40 with the information stored in client information storage unit 25 to authenticate client 40. Client authentication unit 28 issues the authentication token stored in token storage unit 24 to the authenticated client 40.

[0066] Figure 5 This 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 clock (timer) 204, and a communication interface 205. The token issuing server 20 is connected to the processor 201, the main memory 202, the auxiliary storage device 203, the clock 204, and the communication interface 205 via a system bus 206. The system bus 206 includes an address bus, a data bus, and other components. The token issuing server 20 is configured as a computer by connecting the processor 201 to the main memory 202, the auxiliary storage device 203, the clock 204, and the communication interface 205 via the system bus 206.

[0067] The processor 201 corresponds to the core of the computer. The processor 201 controls various components that implement various functions of the token issuing server 20 according to the operating system or application programs. The processor 201 includes a cache memory 207. The processor 201 is, for example, a CPU (Central Processing Unit).

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

[0069] The auxiliary storage device 203 corresponds to the auxiliary storage portion of the aforementioned computer. For example, a known storage device such as an EEPROM (Electric Erasable Programmable Read-Only Memory), an HDD (Hard Disc Drive), or an SSD (Solid State Drive) can be used as the auxiliary storage device 203, either alone or in combination. The auxiliary storage device 203 stores data used by the processor 201 during various processes, as well as data generated by the processes performed by the processor 201. The auxiliary storage device 203 may also store application programs.

[0070] 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 also be a storage device externally attached to the token issuing server 20.

[0071] The application programs stored in the main memory 202 or the auxiliary storage device 203 include the control program described below. The method for installing the control program in the main memory 202 or the auxiliary storage device 203 is not particularly limited. The control program can be stored on a removable storage medium, or distributed via communication over a network and installed in the main memory 202 or the auxiliary storage device 203. The storage medium is not limited in form as long as it can store programs and can be read by the device, such as a CD-ROM or memory card.

[0072] The clock 204 measures the time set by the processor 201. When the measured time reaches the set time, the clock 204 outputs a timeout signal to the processor 201.

[0073] The communication interface 205 is connected 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. That is, the communication interface 205 is hardware that realizes the functions of the gateway communication unit 21 and the client communication unit 22.

[0074] The token issuing server 20 forms a portion 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.

[0075] The token issuing server 20 forms a part of the storage area of ​​the cache memory 207 as an area serving as the token storage unit 24. That is, the cache memory 207 is hardware that realizes the function of the token storage unit 24.

[0076] The token issuing server 20 implements the functions of the access key acquisition unit 26, the token acquisition unit 27, the client authentication unit 28, and the token issuing unit 29 by having the processor 201 execute predetermined information processing according to a control program. Specifically, the processor 201 is hardware for implementing the functions of the token acquisition unit 27, the client authentication unit 28, and the token issuing unit 29.

[0077] [Description of the service management system]

[0078] Figure 6 This is a flowchart showing the main sequence of information processing performed by the processor 201 of the token issuing server 20 according to the control program. Figure 7 This is a timing diagram of the data signals exchanged between the token issuing server 20, API gateway 10, service provider server 30, and client 40 related to this information processing. The following diagrams illustrate the main operations of the service management system. The order of information processing shown in the flowchart is not limited to this. Any appropriate modifications can be made as long as the same functional effects are achieved.

[0079] As ACT 1, processor 201 of token issuing server 20 checks whether an access key is stored in access key storage unit 23. If no access key is stored, processor 201 proceeds to ACT 2. As ACT 2, processor 201 requests an access key from API gateway 10 using the function of access key acquisition unit 26. Specifically, processor 201 transmits a command signal requesting an access key from gateway communication unit 21 to API gateway 10.

[0080] The API gateway 10, having received the command signal, transmits a response signal including the access key generated by the access key generation unit 14 to the token issuing server 20 (access key transmission unit) via the first server communication unit 11. The access key generation unit 14 generates and stores the access key in advance.

[0081] As Act 3, the processor 201 of the token issuing server 20, having transmitted the command signal, waits for a response signal. Upon receiving the response signal via the gateway communication unit 21, the processor 201 proceeds to Act 4. As Act 4, the processor 201, using the function of the access key acquisition unit 26, overwrites the access key included in the response signal into the access key storage unit 23 and stores the access key. The processor 201 then proceeds to Act 5.

[0082] As ACT 5, the processor 201 determines whether it is time to obtain an authentication token. The processor 201 determines that it is time to obtain an authentication token if the token storage unit 24 does not store an authentication token. If the processor 201 determines that the token storage unit 24 stores an authentication token, the processor 201 determines that it is time to obtain an authentication token if the expiration time of the authentication token has elapsed. The expiration time is measured by the clock 204.

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

[0084] When the client 40 is to use the service provided by the service providing server 30, it is necessary to obtain an authentication token before that. The client 40 that needs to obtain an authentication token sends a command signal Sc (see Sc) requesting an authentication token to the token issuing server 20. Figure 7 ).

[0085] In the absence of a request to obtain an authentication token from any client 40, the processor 201 returns to ACT1. As ACT1, the processor 201 confirms whether an access key is stored in the access key storage unit 23. At this point in time, an access key is stored in the access key storage unit 23. Therefore, the processor 201 proceeds to ACT7. As ACT7, the processor 201 confirms whether the access key generated in the API gateway 10 has been changed (change confirmation unit). Specifically, it is determined whether information indicating that the access key has been changed is received from the API gateway 10.

[0086] The API gateway 10 stores the access key generated by the access key generation unit 14. However, sometimes, for some reason, the stored access key disappears. When the access key disappears, the API gateway 10 detects the disappearance of the access key (disappearance detection unit) and generates and stores a new access key in 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 disappeared access key. In other words, the access key has been changed.

[0087] When it is confirmed that the access key has been changed, as ACT 2, the access key acquisition unit 26 requests the API gateway 10 for the access key. The API gateway 10 transmits the new access key to the token issuing server 20 (access key transmission unit).

[0088] 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.

[0089] Thus, while the access key stored in the access key storage unit 23 is not changed, the processor 201 waits for an opportunity to obtain an authentication token in ACT 5 or ACT 6 or for a request to obtain an authentication token from the client 40 .

[0090] When it is time to obtain the authentication token in ACT5, the processor 201 proceeds to ACT8. As ACT8, the processor 201 uses the access key stored in the access key storage unit 23 to access the API gateway 10. Thereafter, as ACT9, the processor 201 requests a token from the API gateway 10 according to the function of the token acquisition unit 27. Specifically, the processor 201 sends a command signal Sa (see ACT9) requesting a token from the gateway communication unit 21 to the API gateway 10. Figure 7 ).

[0091] The API gateway 10 receives the command signal Sa and sends a response signal Sb (see Figure 7 ) is sent to the token issuing server 20 via the first server communication unit 11.

[0092] As ACT 10, the processor 201 that requested the token waits for receipt of the response signal Sb. When the response signal Sb is received via the gateway communication unit 21, the processor 201 proceeds to ACT 11. As ACT 11, the processor 201 overwrites the authentication token contained in the response signal Sb on the token storage unit 24 and stores it according to the function of the token acquisition unit 27. Thereafter, the processor 201 returns to ACT 1. Then, if the access key has not been changed, the processor 201 waits for receipt of the timing to acquire the authentication token or for receipt of a request to acquire the authentication token from the client 40. In this waiting state, when the timing to acquire the authentication token again becomes, the processor 201 executes the processes of ACT 8 to ACT 11 in the same manner as described above.

[0093] According to the above actions, Figure 7 As shown, the token issuing server 20 periodically sends a command signal Sa requesting a token to the API gateway 10. Then, in response to the command signal Sa, the API gateway 10 returns a response signal Sb containing the current authentication token to the token issuing server 20. In this way, the token issuing server 20 continuously stores the latest authentication tokens generated by the API gateway 10.

[0094] When the processor 201 receives the command signal Sc (see ACT 6) requesting the authentication token via the client communication unit 22, Figure 7 ), the process proceeds to ACT 12. As ACT 12, the processor 201 authenticates the client 40 that sent the command signal Sc using the functionality of the client authentication unit 28. Specifically, the command signal Sc includes an ID and password set for each client 40. The processor 201 checks whether the ID and password combination is stored in the client information storage unit 25. If the client information storage unit 25 stores information that matches the ID and password combination included in the command signal Sc, authentication of the client 40 is established.

[0095] As ACT 13, the processor 201 confirms whether the authentication of the client 40 is successful. If the authentication of the client 40 is not successful, the processor 201 negates the command signal Sc and returns to ACT 1.

[0096] When the authentication of the client 40 is established, the processor 201 proceeds to ACT 14. As ACT 14, the processor 201 reads the authentication token stored in the token storage unit 24 according to the function of the token issuing unit 29. Thereafter, as ACT 15, the processor 201 controls the client 40, which is the source of the command signal Sc, according to the function of the token issuing unit 29. Through this control, the response signal Sd (see FIG. 14 ) containing the authentication token is sent from the client communication unit 22 to the corresponding client 40. Figure 7 After controlling the transmission of the authentication token, the processor 201 returns to ACT 1. Thereafter, if the access key has not been changed, the processor 201 waits for an opportunity to obtain an authentication token or for a request to obtain an authentication token from the client 40. While in this waiting state, if a request to obtain an authentication token is received again from any client 40, the processor 201 executes the processes of ACTs 12 to 15 as described above.

[0097] According to the above operation, the client 40 that has sent the command signal Sc requesting the authentication token receives the response signal Sd including the authentication token at the current time from the token issuing server 20. Thereafter, the client 40 that has received the response signal Sd sends the command signal Se (refer to Figure 7 ) is sent to the API gateway 10. The command signal Se includes the authentication token obtained from the token issuing server 20.

[0098] When the API gateway 10 receives the 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. The API gateway 10 determines that authentication is successful if the authentication token matches the authentication token generated and stored by the token generation unit 15. If the authentication token included in the command signal Se does not match the stored authentication token, authentication is unsuccessful.

[0099] When the authentication token is authenticated, the API gateway 10 forwards the command signal Se received from the client 40 to the service providing server 30 according to the function of the service processing unit 17. The service providing server 30 executes the service requested by the command signal Se and sends a response signal Sf (see Figure 7 ) is sent to the API gateway 10. The API gateway 10 sends a response signal Sf indicating the execution result of the service to the client 40 of the request source according to the function of the service processing unit 17. In this way, the client 40 can use the service provided by the service providing server 30.

[0100] [Explanation of the effect]

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

[0102] The token issuing server 20 obtains the access key generated in the API gateway 10 and stores it in the access key storage unit 23. Thereafter, the token issuing server 20 uses the access key stored in the access key storage unit 23 to periodically access the API gateway 10, obtain the authentication token generated in the API gateway 10 and updated at any time, and store it in the token storage unit 24.

[0103] Furthermore, the token issuing server 20 receives a request command from each client 40 to obtain an authentication token. Subsequently, the token issuing server 20 issues the authentication token stored in the token storage unit 24 to the client 40 that requested the token. The client 40 that received the authentication token uses the authentication token to access the API gateway 10 and request a service. At this point, because the authentication token issued by the token issuing server 20 is the latest one, authentication of the authentication token is established at the API gateway 10. In this way, a service request is made to the service providing server 30 via the API gateway 10, and the result of the service execution is notified to the client 40.

[0104] Thus, in this embodiment, the token issuing server 20 stores the access key generated by the API gateway 10. In addition, in a communication system of the prior art in which the token issuing server 20 is not provided, each client 40 stores the access key. The client 40 does not have the technology to confirm whether the access key has been changed in the API gateway 10. In addition, due to security issues, it is sometimes difficult to specify the client 40 from an external server, etc., and then change the access key of the specified client 40. In this embodiment, the token issuing server 20 stores the access key generated by the API gateway 10. Because the API gateway 10 and the token issuing server 20 constitute the service management system 60, the security is high. In addition, in the case where the access key is changed through the API gateway 10, it is also easy to change the access key stored in the token issuing server 20.

[0105] Conventional communication systems cannot easily modify the access key stored by client 40. Therefore, even if the access key stored by API gateway 10 disappears or is modified for some reason, client 40 cannot learn the new access key. Consequently, client 40 may be denied access to API gateway 10 using the old access key.

[0106] 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 does not have to be denied access to the API gateway due to the access key of the API gateway 10 being overwritten.

[0107] On the other hand, in this embodiment, the token issuing server 20 uses the access key to periodically access the API gateway 10, obtain the latest authentication token from the API gateway 10 and save it. After that, each client 40 does not access the API gateway 10 but accesses the token issuing server 20, and obtains the latest authentication token. In this way, by setting up the token issuing server 20, the access from each client 40 is dispersed between the token issuing server 20 and the API gateway 10. As a result, even if the number of clients 40 increases significantly, it is possible to avoid concerns about an increase in the load on the API gateway 10 and a decrease in performance as a relay device. In other words, as long as the service management system 60 includes a token issuing server 20, it can appropriately cope with the increase in the number of clients 40.

[0108] Furthermore, in this embodiment, an ID and password are assigned to each client 40, and the token issuing server 20 stores this ID and password information. Subsequently, when a client 40 requests an authentication token, the token issuing server 20 uses the ID and password notified from the client 40 to determine the validity of the client 40. Therefore, there is no risk of issuing an authentication token to an abnormal client 40 whose validity is not recognized, and the reliability of the system is not compromised.

[0109] [Modification]

[0110] In the embodiment described above, a portion of the storage area of ​​the cache memory 207 is formed as the area serving as the token storage unit 24. In this regard, a portion of the storage area of ​​the main memory 202 or the auxiliary storage device 203 may also be formed as the area serving as the token storage unit 24.

[0111] In addition, although the timing of obtaining the authentication token is timed by the clock 204, the authentication token can also be requested and obtained from the API gateway 10 in response to a request for the authentication token from the client 40. However, if the authentication token is obtained and stored regularly as in this embodiment, it is possible to quickly respond to the request for the authentication token from the client 40.

[0112] In the above embodiment, the ID and password are exemplified as information for authenticating the validity of the client 40. The information for authenticating the validity is not limited to the ID and password. For example, the token issuing server 20 may authenticate the validity using only the ID of the client 40.

[0113] In addition, although several embodiments of the present invention have been described, these embodiments are provided as examples and are not intended to limit the scope of the invention. These novel embodiments may be implemented in various other forms, and various omissions, substitutions, and modifications may be made without departing from the spirit of the invention. In addition, these embodiments and their variations are intended to be included within the scope and spirit of the invention and, moreover, within the scope of the invention described in the claims and their equivalents.

Claims

1. A service management system, characterized in that: include: a relay device for relaying communication between a service providing server and a client utilizing the service, wherein the service providing server provides a service composed of one or more microservices; as well as A token issuing server communicates with the relay device and the client, wherein the token issuing server includes: an access key storage unit for storing the access key of 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 obtained by the token obtaining unit to the client in response to a token request from the client, The relay device includes: A token generation unit, generating the authentication token; a token authentication unit that authenticates the authentication token included in the service request from the client; and The service processing unit issues a command to the service providing server to execute the service requested by the client when the authentication of the authentication token by the token authentication unit is successful.

2. The service management system according to claim 1, wherein: The token issuing server also includes: A token storage unit stores the authentication token acquired by the token acquisition unit, wherein: The token acquisition unit periodically acquires an authentication token from the relay device and updates the data in the token storage unit. The token generation unit of the relay device periodically generates an authentication token.

3. The service management system according to claim 1 or 2, wherein: The token issuing server also includes: The access key acquisition unit acquires the access key from the relay device, wherein: The access key storage unit stores the access key acquired by the access key acquisition unit. The relay device further includes: The access key sending unit sends the access key to the token issuing server.

4. The service management system according to claim 3, wherein: The token issuing server also includes: A change confirmation unit confirms whether the access key of the relay device has been changed, wherein: When the change confirmation unit confirms that the access key has been changed, the access key acquisition unit acquires a new access key. The relay device further includes: The disappearance detection unit detects the disappearance of the access key, wherein When the loss detection unit detects that the access key has been lost, the access key generation unit generates a new access key, and the access key transmission unit transmits the new access key.

5. A token issuing server, characterized in that: include: 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 utilizes the service; A second communication unit, communicating with the client; an access key storage unit for storing the 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 The token issuing unit issues the authentication token acquired by the token acquiring unit to the client in response to a token request from the client.

6. The token issuing server according to claim 5, further comprising: A token storage unit stores the authentication token acquired by the token acquisition unit, wherein: The token acquisition unit periodically acquires an authentication token from the relay device and updates data in the token storage unit.

7. The token issuing server according to claim 5 or 6, further comprising: The client authentication unit authenticates the client as the source of the service request, wherein: The token issuing unit issues the authentication token when authentication of the client by the client authentication unit is successful.

8. The token issuing server according to claim 5 or 6, further comprising: The access key acquisition unit acquires the access key from the relay device, wherein: The access key storage unit stores the access key acquired by the access key acquisition unit.

9. The token issuing server according to claim 8, further comprising: a change confirmation unit, configured to confirm whether the access key of the relay device has been changed, When the change confirming unit confirms that the access key has been changed, the access key acquiring unit acquires the changed access key.

10. A storage medium storing a program for causing a computer including a first communication unit and a second communication unit to implement the following functions, wherein the first communication unit 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 utilizes the service, and the second communication unit communicates with the client, the functions comprising: A function of storing the access key issued by the relay device in a storage unit; A function of obtaining an authentication token from the relay device using the access key stored in the storage unit; as well as A function of issuing the obtained authentication token to the client in response to a token request from the client.

Images