Authentication system and authentication server

Abstract

To provide an authentication system and an authentication server which can reduce possibility that single sign-on (SSO) authentication does not function normally.SOLUTION: An authentication system comprises a client device 10, an SP server (service providing server) 11, and an IdP server (SSO authentication server) 12. The IdP server 12: acquires a load state of the SP server 11; determines whether the load state is a high load state or a low load state; and in a case of the high load state, notifies the client device 10 of a fact that access to the SP server 11 is impossible.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] The present invention relates to an authentication system and an authentication server to which a single sign-on (also called SSO) authentication method is applied. [Background technology]

[0002] Patent Document 1 shows an authentication system that can provide a service user with a service according to pre-SSO information after SSO using SAML (Security Assertion Markup Language). Specifically, when an SP (Service Provider) server receives SSO access from a user terminal, the SP server stores pre-SSO communication session information of the user terminal in an information storage unit as pre-SSO information, and redirects the user terminal to an IdP (Identify Provider) server. The IdP server performs SSO authentication by referring to an SSO authentication DB using authentication information input from the user terminal, and redirects the user terminal to the SP server if the SSO authentication is successful. After the SSO authentication is successful, the SP server acquires pre-SSO information from the information storage unit, and provides the user terminal with a service according to the contents of the pre-SSO information. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2016-118930 A Summary of the Invention [Problem to be solved by the invention]

[0004] Various SSO authentication methods are known, such as SAML shown in Patent Document 1. For example, in SAML, an identity provider (IdP) server, which is an SSO authentication server, performs SSO authentication on a client device on behalf of a service provider (SP) server and notifies the SP server of the authentication result. This allows the SP server to authenticate the client device.

[0005] In such an authentication method, for example, let us assume that the load on the SP server becomes high. In this case, if further access to the SP server occurs, there is a risk that the Web service provided by the SP server will be stopped. Furthermore, if the service provided by the SP server is stopped, this may cause the access load to the SP server to increase further, and it may take a long time to restore the service. In other words, if such a situation occurs, there is a high possibility that the SSO authentication will not function properly even if the IdP server has sufficient resources. Furthermore, there is a risk that the period during which the SSO authentication function is stopped will be prolonged.

[0006] The present invention has been made in consideration of the above, and one of its objectives is to provide an authentication system and an authentication server that can reduce the possibility that single sign-on (SSO) authentication will not function properly.

[0007] The above and other objects and novel features of the present invention will become apparent from the description of this specification and the accompanying drawings. [Means for solving the problem]

[0008] Among the inventions disclosed in this application, a brief outline of a representative embodiment will be described as follows.

[0009] An authentication system according to an embodiment includes a client device, a service providing server that provides a predetermined service to the client device in response to an access from the client device, and an SSO authentication server that performs SSO authentication processing between the client device and the service providing server and transmits an authentication result response obtained in the authentication processing to the service providing server in response to an authentication request from the service providing server. Here, the SSO authentication server acquires the load state of the service providing server, determines whether the load state is a high load state that is higher than a reference state or a low load state that is lower than a reference state, and if the load state is a high load state, notifies the client device that access to the service providing server is not possible. Effect of the Invention

[0010] To briefly explain the effect obtained by the representative embodiment of the invention disclosed in this application, the possibility that single sign-on authentication will not function properly can be reduced. [Brief description of the drawings]

[0011] [Figure 1] 1 is a schematic diagram showing a configuration example of an authentication system according to a first embodiment. [Diagram 2] FIG. 4 is a sequence diagram showing an example of processing contents in the authentication system according to the first embodiment. [Diagram 3] 3 is a diagram for explaining a specific example of a part of the processing contents shown in FIG. 2.

[0023] FIG. [Figure 4] 2 is a functional block diagram showing a configuration example of a main part of the IdP server appearing in FIG. 1. [Figure 5A] 5 is a flowchart showing an example of main processing contents of the IdP server in FIG. 4. [Figure 5B] 5 is a flowchart showing an example of main processing contents of the IdP server in FIG. 4. [Figure 6] FIG. 11 is a sequence diagram showing an example of processing contents in an authentication system according to the second embodiment. [Figure 7] FIG. 11 is a sequence diagram showing an example of processing contents in the underlying authentication system. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings. In all the drawings for explaining the embodiment, the same members are generally designated by the same reference numerals, and the repeated description will be omitted.

[0013] (First embodiment) <Authentication system configuration and prerequisite operations> Fig. 1 is a schematic diagram showing a configuration example of an authentication system according to a first embodiment. An SSO authentication method is applied to the authentication system shown in Fig. 1. Here, a case where SAML is used as the SSO authentication method is taken as an example. However, the SSO authentication method is not limited to SAML, and may be, for example, OpenID, OpenID Connect, or the like.

[0014] 1 includes a client device 10, an SP server 11, an IdP server 12, and a network 13 connecting them. The network 13 is, for example, the Internet, and is responsible for relay processing of layer 3 (L3). The client device 10 is used by a client 15, and is realized by a computer system such as a personal computer (PC) or a tablet terminal. The SP server 11 and the IdP server 12 are also realized by a computer system including, for example, a processor and a memory.

[0015] The SP server 11 is a service providing server that provides a predetermined service, such as a Web service, to the client device 10 in response to access from the client device 10 via the network 13. For convenience of explanation, one SP server 11 is provided here, but typically multiple SP servers can be provided.

[0016] The IdP server 12 is an SSO authentication server, and performs SSO authentication processing with the client device 10 via the network 13. In addition, in response to an authentication request from the SP server 11 via the network 13, the IdP server 12 transmits a response of the authentication result obtained in the SSO authentication processing to the SP server 11. In other words, the SSO authentication server 12 authenticates the client device 10 on behalf of the SP server 11.

[0017] Fig. 7 is a sequence diagram showing an example of processing contents in the prerequisite authentication system. The configuration of the prerequisite authentication system is the same as that in Fig. 1. The operation shown in Fig. 7 is called "SP-Initiated SSO". In Fig. 7, first, the client device 10 accesses the SP server 11 (step S101). In response, the SP server 11 transmits an authentication request, which is one of SAML requests, to the IdP server 12 via the client device 10 using HTTP (Hypertext Transfer Protocol) redirection or the like (step S102).

[0018] Next, the IdP server 12 performs SSO authentication processing with the client device 10 in response to the authentication request from the SP server 11 (step S103). For this authentication processing, various methods can be used, such as ID / password authentication and session cookie authentication. Next, the IdP server 12 uses HTTP redirection or the like to transmit a response of the authentication result, which is one of the SAML responses, to the SP server 11 via the client device 10 (step S104).

[0019] Then, the SP server 11 responds to the client device 10 as to whether or not login is permitted, depending on the contents of the response of the received authentication result (step S105). Specifically, if the authentication result is authentication permitted, the SP server 11 provides, for example, the service requested in association with the access in step S101 to the client device 10. On the other hand, if the authentication result is authentication not permitted, the SP server 11 notifies, for example, the client device 10 that login is not permitted.

[0020] Here, assume that the load on the SP server 11 becomes high in the operation shown in Fig. 7. In this case, for example, when access to the SP server 11 occurs as shown in step S101 in Fig. 7, there is a risk that the Web service or the like provided by the SP server 11 will be stopped. Furthermore, this may result in a higher access load to the SP server 11, and it may take a long time to restore the service.

[0021] Also, the SP server 11 may not be able to normally transmit the authentication request as shown in step S102 in Fig. 7. Furthermore, even if the SP server 11 can transmit the authentication request, it may not be able to normally receive the response from the IdP server 12 as shown in step S104 in Fig. 7.

[0022] In this way, when the load on the SP server 11 becomes high, the SSO authentication is likely to not function properly even if the resources of the IdP server 12 are sufficient. Furthermore, there is a risk that the SSO authentication function will be out of operation for a long period of time. Therefore, it is beneficial to use the method of the embodiment described below.

[0023] <Operation of the authentication system according to the first embodiment> Fig. 2 is a sequence diagram showing an example of the processing contents in the authentication system according to the first embodiment. Fig. 3 is a diagram for explaining a specific example of a part of the processing contents shown in Fig. 2. In Fig. 2, first, the IdP server 12, which is an SSO authentication server, starts monitoring the load state of the SP server 11, which is a service providing server (step S201). In detail, the IdP server 12 starts periodically acquiring the load state of the SP server 11 (steps S202, S206).

[0024] Then, the IdP server 12 judges whether the acquired load state is a high-load state or a low-load state. Specifically, the IdP server 12, for example, compares the acquired load state with a predetermined reference state and judges whether the load state is a high-load state that is a higher load than the reference state or a low-load state that is a lower load than the reference state. In this example, the IdP server 12 judges the load state acquired in step S202 to be a high-load state, and then judges the load state acquired in step S206 to be a low-load state.

[0025] As a specific method for acquiring the load state of the SP server 11, for example, the following method can be mentioned. In one method, the IdP server 12 measures the time required for transmitting a specific request to the SP server 11 and then receiving a response to the request from the SP server 11. In this case, a state in which the required time is a predetermined reference time is taken as a reference state, and the IdP server 12 may determine that the state is in a high load state if the measured required time is longer than the reference time, and may determine that the state is in a low load state if the measured required time is shorter than the reference time.

[0026] As another method, the IdP server 12 acquires various statuses such as the CPU usage rate and memory usage rate of the SP server 11 using SNMP (Simple Network Management Protocol) or the like. In this case, a state in which the CPU usage rate or the like is a predetermined standard ratio is taken as the standard state, and the IdP server 12 determines that the state is in a high load state when the acquired usage rate is higher than the standard ratio, and determines that the state is in a low load state when the acquired usage rate is lower than the standard ratio. Note that various methods other than the above can be applied as the method of acquiring the load state.

[0027] Furthermore, the method by which the IdP server 12 determines whether the SP server 11 is in a high-load state or a low-load state is not limited to a method in which the IdP server 12 compares the state with a reference state, and various other methods can be used. For example, the SP server 11 itself may determine whether the state is in a high-load state or a low-load state, and the IdP server 12 may simply acquire the result of the determination by the SP server 11.

[0028] After step S202, the client device 10 transmits a login request to the IdP server 12 (step S203). In response to the login request, the IdP server 12 performs SSO authentication processing with the client device 10 (step S204). In step S204, for example, if ID / password authentication is used, the IdP server 12 causes the client device 10 to display a Web screen 20a as shown in FIG. 3. The client 15 inputs an ID / password on the Web screen 20a and performs a login operation. In response to this, the IdP server 12 checks the ID / password associated with the login operation against the registered contents of the SSO authentication database to determine whether authentication is permitted / rejected.

[0029] In this example, the authentication result in step S204 is authentication permitted. In this case, the IdP server 12 provides the client device 10 with a link to the SP server 11. At this time, if the load state acquired in the most recent step S202 is a high load state, the IdP server 12 notifies the client device 10 that access to the SP server 11 is not possible (step S205). Specifically, the IdP server 12 notifies the client device 10 that access to the SP server 11 is not possible, for example, by not displaying a link to the SP server 11 on the client device 10.

[0030] As a specific example of the process of step S205, the IdP server 12 causes the client device 10 to display, for example, a Web screen 20b as shown in Fig. 3. The Web screen 20b displays a list of links to each SP server 11 that is registered in advance in the IdP server 12 as an SSO linked server.

[0031] On this Web screen 20b, SP server [1] is in a high-load state and therefore cannot be selected by the client 15. On the other hand, SP server [2] is in a low-load state and therefore can be selected by the client 15. For example, by using such a screen, unlike the case of FIG. 7, it is possible to prevent access from the client device 10 to the SP server 11, which is in a high-load state.

[0032] If the authentication result in step S204 is not permitted, the IdP server 12 is configured not to provide the client device 10 with a link to the SP server 11, regardless of the load state of the SP server 11. However, even if the authentication result is not permitted, the IdP server 12 may provide the client device 10 with a link to the SP server 11 as shown on the Web screen 20b. Even in this case, in the subsequent step S103, it is determined that the authentication is not permitted, and login to the SP server 11 is not permitted.

[0033] After that, in step 206, the load state of the SP server 11 changes from a high load state to a low load state. When the load state of the SP server 11 changes from a high load state to a low load state, the IdP server 12 notifies the client device 10 that access to the SP server 11 has become possible (step S207). As a specific example of this process, the IdP server 12 causes the client device 10 to display, for example, a Web screen 20c as shown in FIG. 3. Unlike the above-mentioned Web screen 20b, the Web screen 20c is in a state in which a link to the SP server [1] can be selected by the client 15.

[0034] Accordingly, when the client 15 selects the link to the SP server 11, the same processing as in steps S101-S105 described in Fig. 7 is performed. That is, the client device 10 accesses the SP server 11 (step S101). In response to the access, the SP server 11 transmits an authentication request to the IdP server 12 via the client device 10 (step S102). In response to the authentication request, the IdP server 12 performs SSO authentication processing with the client device 10 (step S103).

[0035] In step S103, the Idp server 12 performs the authentication process based on, for example, a session cookie stored in the browser of the client device 10 following the authentication process in step S204. Specifically, if the authentication result in step S204 is authentication permitted, the session cookie is stored in the client device 10. Therefore, if the authentication result in step S204 is authentication permitted, there is no need to re-enter the ID / password in step S103.

[0036] After the authentication process in step S103, the IdP server 12 transmits an authentication result, for example, a response indicating that authentication is permitted, to the SP server 11 via the client device 10 (step S104). In response to this, the SP server 11 responds to the client device 10 as to whether login is permitted (step S105).

[0037] By using the sequence as shown in Fig. 2, it is possible to prevent the client device 10 from accessing the SP server 11 under high load. This makes it possible to prevent further load from being applied to the SP server 11, and, for example, to reduce the possibility of service interruption in the SP server 11 and the possibility of service recovery being prolonged. Furthermore, when the SP server 11 is under high load, the start trigger of the SSO authentication for that SP server 11, that is, step S101 in Fig. 7, can be stopped. As a result, it is possible to reduce the possibility that the SSO authentication will not function normally. Furthermore, it may be possible to shorten the period during which the SSO authentication is out of function.

[0038] <Details of the IdP Server (SSO Authentication Server)> Figure 4 is a functional block diagram showing a configuration example of the main part of the IdP server in FIG. 1. The IdP server 12 shown in FIG. 4 includes a login request receiving unit 20, an authentication request receiving unit 21, an authentication processing unit 22, an SSO authentication database (abbreviated as DB) 23, an access permission notification unit 24, an authentication result response unit 25, a load status acquisition unit 26, and a load status determination unit 27.

[0039] The SSO authentication DB 23 is stored in the memory. Each of the other units is realized, for example, by a processor executing a program stored in the memory. However, it is not limited to the software implementation form using such a processor, and a hardware implementation form using an FPGA (Field Programmable Gate Array), an ASIC (Application Specific Integrated Circuit), etc. may be appropriately applied.

[0040] The login request receiving unit 20 receives a login request from the client device 10, notifies the access permission notification unit 24 to that effect, and causes the authentication processing unit 22 to perform authentication processing. The authentication request receiving unit 21 receives an authentication request from the SP server 11, notifies the access permission notification unit 24 to that effect, and causes the authentication processing unit 22 to perform authentication processing.

[0041] In the SSO authentication DB 23, for example, IDs / passwords, etc. that are the objects of authentication permission are registered. The authentication processing unit 22 performs SSO authentication processing with the client device 10 by collating the input ID / password with the SSO authentication DB 23, confirming the transmitted session cookie, etc., and outputs an authentication result of authentication permission or authentication non - permission. Thereby, the processes of steps S203, S204, S102, and S103 in FIG. 2 are executed.

[0042] The load status acquisition unit 26 acquires the load status of the SP server 11, and for example, periodically acquires the load status at a predetermined interval. The load status determination unit 27 determines, for example, whether the acquired load status is a high load status that is a higher load than a reference status, or a low load status that is a lower load than a reference status. This causes the processing of steps S202 and S206 in FIG. 2 to be executed.

[0043] When the load condition determining unit 27 determines that the load condition is high, the access permission notifying unit 24 notifies the client device 10 that access to the SP server 11 is not possible. More specifically, even if a login request is received, when the load condition determining unit 27 determines that the load condition is high, the access permission notifying unit 24 does not cause the client device 10 to display a link to the SP server 11. This causes the process of step S205 in FIG. 2 to be executed.

[0044] On the other hand, the access permission notifying unit 24 receives the login request, and if the load state is a low load state, or if the authentication result is authentication permitted, causes the client device 10 to display a link to the SP server 11. Furthermore, if the load state changes from a high load state to a low load state, the access permission notifying unit 24 notifies the client device 10 that access to the SP server 11 has become possible. This causes the processing of step 207 in FIG. 2 to be executed.

[0045] The authentication result response unit 25 transmits a response of the authentication result by the authentication processing unit 22 to the SP server 11 in response to an authentication request from the SP server 11. More specifically, when the determination result of the load condition determination unit 27 is a low-load condition, the authentication result response unit 25 transmits a response of the authentication result to the SP server 11 via the client device 10. This causes the process of step S104 in Fig. 2 to be executed. On the other hand, when the determination result of the load condition determination unit 27 is a high-load condition, the authentication result response unit 25 does not transmit a response of the authentication result.

[0046] Figures 5A and 5B are flowcharts showing an example of main processing contents of the IdP server in Figure 4. The flowcharts shown in Figures 5A and 5B are executed independently. In addition, the IdP server 12 periodically executes the flowchart shown in Figure 5A at a predetermined interval.

[0047] 5A, the load condition acquisition unit 26 acquires the load condition of the SP server 11 (step S301). Next, the load condition determination unit 27 determines whether the acquired load condition is higher than a reference condition (step S302). If the load condition is higher than the reference condition (step S302: Yes), the load condition determination unit 27 determines that the SP server 11 is in a high load condition (step S303), and if the load condition is lower than the reference condition (step S302: No), the load condition determination unit 27 determines that the SP server 11 is in a low load condition (step S304).

[0048] After step S304, the access permission notifying unit 24 determines whether the result of the load state determining unit 27 has changed from a high load state to a low load state (step S305). If the result of the determination has changed from a high load state to a low load state (step S305: Yes), the access permission notifying unit 24 notifies the client device 10 that access to the SP server 11 has become possible (step S306).

[0049] 5B, the IdP server 12 receives a request from the client device 10 or the SP server 11 (step S401). Then, the IdP server 12 identifies the type of the request, and causes the login request receiving unit 20 to receive the login request from the client device 10, and causes the authentication request receiving unit 21 to receive the authentication request from the SP server 11 (step S402).

[0050] When a login request is received and the load state determination unit 27 determines that the load state is high (step S403: Yes), the access permission notifier 24 notifies the client device 10 that access to the SP server 11 is not possible (step S404). That is, the access permission notifier 24 causes the client device 10 to display, for example, a Web screen 20b as shown in FIG.

[0051] Furthermore, when a login request is received and the load state determination unit 27 determines that the load state is low (step S403: No), the access permission notifier 24 notifies the client device 10 that access to the SP server 11 is permitted (step S405). That is, the access permission notifier 24 causes the client device 10 to display, for example, a Web screen 20c as shown in FIG.

[0052] On the other hand, when an authentication request is received and the load state determination unit 27 determines that the load state is high (step S406: Yes), the access permission notifying unit 24 notifies the client device 10 that access to the SP server 11 is not possible (step S407). In this case, the authentication result response unit 25 does not transmit a response to the SP server 11. Also, when an authentication request is received and the load state determination unit 27 determines that the load state is low (step S406: No), the authentication result response unit 25 transmits a response to the authentication result obtained by the authentication processing unit 22 to the SP server 11 (step S408).

[0053] 2 is a mechanism that prevents the client device 10 from accessing the SP server 11 in a high load state, and therefore prevents, in principle, an authentication request from the SP server 11 in a high load state. Therefore, when using the sequence shown in FIG. 2, the process basically does not reach step S407 in FIG. 5B.

[0054] <Basic method of the first embodiment> The method of the first embodiment is a method in which the client device 10 accesses the IdP server 12 before the SP server 11, and the IdP server 12 determines whether or not to transition to the operation of "SP-Initiated SSO" shown in Fig. 7 according to the load state of the SP server 11. For this reason, a mechanism for allowing the client device 10 to access the IdP server 12 before the SP server 11 is required.

[0055] Such a mechanism can be realized, for example, by operating a network. As a specific example, there is a method of performing startup settings in the client device 10 so that logging in to the IdP server 12 is performed at startup. As another specific example, there is a method of allowing the client device 10 to use the IdP server 12 as a portal site.

[0056] <Major Effects of the First Embodiment> As described above, in the first embodiment, the authentication server acquires the load state of the service providing server, and if the acquired load state is a high load state, notifies the client device that access to the service providing server is not possible. This makes it possible to stop the client device from accessing the service providing server in a high load state, thereby reducing the possibility that the SSO authentication will not function properly.

[0057] (Embodiment 2) <Operation of the authentication system according to the second embodiment> Fig. 6 is a sequence diagram showing an example of processing contents in the authentication system according to the second embodiment. The configuration of the authentication system according to the second embodiment is similar to that in Fig. 1. Unlike the case of Fig. 2, Fig. 6 shows the operation when the client device 10 accesses the SP server 11 before the IdP server 12, similar to the case of Fig. 7.

[0058] 6, first, the client device 10 accesses the SP server 11 (step S101a) in the same manner as in the case of Fig. 7. In response to this, the SP server 11 transmits an authentication request to the IdP server 12 via the client device 10 (step S102a).

[0059] 7 and also different from the case of FIG. 2, the IdP server 12 acquires the load status of the SP server 11 after receiving an authentication request from the SP server 11 (step S501). In this example, the IdP server 12 determines that the load status acquired in step S501 is a high load status. If the acquired load status is a high load status, the IdP server 12 starts to periodically acquire the load status (step S502).

[0060] Furthermore, when the acquired load state is a high load state, the IdP server 12 does not perform SSO authentication processing with the client device 10, and does not transmit a response of the authentication result to the SP server 11. Instead, the IdP server 12 notifies the client device 10 that access to the SP server 11 is not possible (step S503). On the other hand, when the acquired load state is a low load state, the IdP server 12 performs SSO authentication processing as in the case of FIG. 7, and transmits a response of the authentication result to the SP server 11 via the client device 10.

[0061] After that, in step S504, the IdP server 12 acquires the load state of the SP server 11 in accordance with the processing of step S502. In this example, the IdP server 12 determines that the load state acquired in step S504 is a low load state. In this way, when the load state changes from a high load state to a low load state, the IdP server 12 notifies the client device 10 that access to the SP server 11 has become possible, similar to the case of step S206 in FIG. 2 (step 505). Specifically, the IdP server 12 may, for example, cause the client device 10 to display Web screens 20b and 20c similar to the case of FIG. 3, respectively, at the stages of steps S503 and S505.

[0062] In response to step S505, when the client device 10 accesses the SP server 11 based on the operation by the client 15 (step S101b), hereinafter, the same processing as in the case of FIG. 7 is performed. Briefly described, the SP server 11 transmits an authentication request to the IdP server 12 via the client device 10 (step S102b). In response to the authentication request, the IdP server 12 performs SSO authentication processing with the client device 10 (step S103).

[0063] Then, the IdP server 12 transmits a response of the authentication result to the SP server 11 via the client device 10 (step S104). The SP server 11 responds to the client device 10 whether login is possible or not according to the received response content of the authentication result (step S105). Also, the IdP server 12 stops monitoring the load state of the SP server 11 (step S506).

[0064] By using the sequence as shown in FIG. 6, it is possible to stop transmitting a response from the IdP server 12 to the SP server 11 in a high load state. Also, as shown in step S503, by notifying the client device 10 that access to the SP server 11 is impossible, it is possible to prevent further access from the client device 10 to the SP server 11. As a result, the possibility that SSO authentication does not function properly can be reduced. Also, in some cases, the period during which the SSO authentication function stops can be shortened.

[0065] <Details of the IdP Server (SSO Authentication Server)> The configuration and operation of the IdP server 12, which is an SSO authentication server, are substantially the same as in the cases of FIGS. 4, 5A, and 5B. As the main difference from the case of the first embodiment, in the second embodiment, the flowchart shown in FIG. 5A is performed after receiving an authentication request from the SP server 11, and if the acquired load state is a high load state, it is periodically executed thereafter until it changes to a low load state.

[0066] Also, in Fig. 5B, as described above, in the first embodiment, the process of step S407 is not basically reached, but in the second embodiment, the process of step S407 may be executed as shown in step S503 in Fig. 6. However, unlike the first embodiment, the processes of steps S404 and S405 are not basically reached.

[0067] <Major Effects of the Second Embodiment> As described above, by using the method of the second embodiment, when the service providing server is in a high load state, it is possible to stop responses from the authentication server to the service providing server and to stop further access from the client device to the service providing server. As a result, it is possible to reduce the possibility that the SSO authentication will not function normally, as in the case of the first embodiment.

[0068] <Comparison between the first and second embodiments> However, in the second embodiment, unlike the method of the first embodiment, there is a possibility that an access from the client device 10 to the SP server 11 under high load (step S101a in FIG. 6) occurs and a corresponding authentication request (step S102a) is not sent. Therefore, in order to improve the effect, it is desirable to use the method of the first embodiment.

[0069] The invention made by the present inventor has been specifically described above based on the embodiments, but the present invention is not limited to the above-mentioned embodiments and can be modified in various ways without departing from the gist of the invention. For example, the above-mentioned embodiments have been described in detail to easily explain the present invention, and the present invention is not necessarily limited to those having all of the configurations described. In addition, it is possible to replace a part of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add the configuration of another embodiment to the configuration of one embodiment. In addition, it is possible to add, delete, or replace a part of the configuration of each embodiment with another configuration.

[0070] For example, the various programs described above may be stored in a non-transitory, tangible, computer-readable recording medium and then supplied to a computer device. Examples of such recording media include magnetic recording media such as hard disk drives, optical recording media such as DVDs (Digital Versatile Discs) and Blu-ray Discs, and semiconductor memories such as flash memories. [Explanation of symbols]

[0071] 10... client device, 11... SP server (service providing server), 12... IdP server (SSO authentication server), 15... client, 20... login request receiving unit, 21... authentication request receiving unit, 22... authentication processing unit, 24... access permission notifying unit, 25... authentication result response unit, 26... load status acquisition unit, 27... load status determination unit

Claims

1. a client device for use by a client; a service providing server that provides a predetermined service to the client device in response to an access from the client device; an SSO authentication server that performs a single sign-on authentication process between the client device and the service providing server and transmits an authentication result response obtained in the authentication process to the service providing server in response to an authentication request from the service providing server; An authentication system comprising: The SSO authentication server includes: Acquire a load state of the service providing server; determining whether the load state is a high load state or a low load state; When the load state is the high load state, notifying the client device that the service providing server is not accessible; Authentication system.

2. 2. The authentication system according to claim 1, The client device sends a login request to the SSO authentication server; The SSO authentication server includes: When the load state is the low load state, displaying a link to the service providing server on the client device in response to the login request; When the load state is the high load state, notifying the client device that access to the service providing server is not possible by not displaying a link to the service providing server on the client device in response to the login request. Authentication system.

3. 3. The authentication system according to claim 2, The SSO authentication server periodically acquires the load status. Authentication system.

4. 4. The authentication system according to claim 3, when the load state changes from the high load state to the low load state, the SSO authentication server notifies the client device that access to the service providing server has become possible. Authentication system.

5. 2. The authentication system according to claim 1, The client device accesses the service providing server, the service providing server transmits an authentication request to the SSO authentication server via the client device in response to access from the client device; The SSO authentication server includes: When the load state is the low load state, the authentication process is performed between the client device and the service providing server in response to the authentication request, and a response of the authentication result is transmitted to the service providing server via the client device; When the load state is the high load state, a response of the authentication result is not transmitted to the service providing server. Authentication system.

6. 6. The authentication system according to claim 5, the SSO authentication server acquires the load state after receiving the authentication request from the service providing server; Authentication system.

7. 7. The authentication system according to claim 6, The SSO authentication server includes: If the acquired load state is the high load state, periodically acquire the load state; when the load state changes from the high load state to the low load state, notifying the client device that access to the service providing server has become possible; Authentication system.

8. an authentication processing unit that performs a single sign-on authentication process with the client device; an authentication result response unit that transmits a response of an authentication result by the authentication processing unit to the service providing server in response to an authentication request from the service providing server; a load status acquisition unit for acquiring a load status of the service providing server; a load state determination unit that determines whether the load state is a high load state or a low load state; an accessibility notifying unit that notifies the client device that access to the service providing server is not possible when the load state is the high load state; Equipped with Authentication server.

9. 9. The authentication server according to claim 8, a login request receiving unit that receives a login request from the client device, The access permission notification unit When the load state is the low load state, displaying a link to the service providing server on the client device in response to the login request; When the load state is the high load state, notifying the client device that access to the service providing server is not possible by not displaying a link to the service providing server on the client device in response to the login request. Authentication server.

10. 10. The authentication server according to claim 9, The load condition acquisition unit periodically acquires the load condition. Authentication server.

11. 11. The authentication server according to claim 10, the accessibility notifying unit notifies the client device that access to the service providing server has become possible when the load state changes from the high load state to the low load state. Authentication server.

12. 9. The authentication server according to claim 8, an authentication request receiving unit that receives an authentication request from the service providing server and causes the authentication processing unit to perform the authentication process; The authentication result response unit, When the load state is the low load state, a response of the authentication result by the authentication processing unit is transmitted to the service providing server via the client device; When the load state is the high load state, the response of the authentication result is not transmitted. Authentication server.

13. 13. The authentication server according to claim 12, the load status acquisition unit acquires the load status after receiving the authentication request from the service providing server. Authentication server.

14. 14. The authentication server according to claim 13, the load condition acquisition unit periodically acquires the load condition when the acquired load condition is the high load condition; the accessibility notifying unit notifies the client device that access to the service providing server has become possible when the load state changes from the high load state to the low load state. Authentication server.

Images