JP2025039005A - Authentication Systems and Servers - Google Patents

Abstract

[Problem] To provide an authentication system and authentication server that can reduce the possibility that single sign-on (SSO) authentication will not function properly. [Solution] The authentication system includes a client device 10, an SP server (service provider server) 11, and an IdP server (SSO authentication server) 12. The IdP server 12 acquires the load state of the SP server 11, determines whether the load state is a high load state or a low load state, and if the load state is a high load state, notifies the client device 10 that access to the SP server 11 is not possible. [Selected Figure] Figure 2

Description

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.

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 a Service Provider (SP) server receives SSO access from a user terminal, it stores the 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 Identify Provider (IdP) 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 obtains the 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.

JP 2016-118930 A

Various SSO authentication methods are known, such as SAML, which is 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.

In this type of authentication method, for example, let us consider a case where 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 services provided by the SP server will be stopped. Furthermore, if the services provided by the SP server are stopped, this may cause the access load to the SP server to increase further, and it may take a long time to restore the services. In other words, when such a situation occurs, there is a high possibility that SSO authentication will not function properly even if the IdP server has sufficient resources. Furthermore, there is a risk that the period during which SSO authentication functions will be suspended will be prolonged.

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

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.

A brief overview of a representative embodiment of the invention disclosed in this application is as follows:

An authentication system according to one embodiment includes a client device, a service providing server that provides a predetermined service to the client device in response to 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, and if the load state is a high load state, notifies the client device that access to the service providing server is not possible.

To briefly explain the effect of a representative embodiment of the invention disclosed in this application, it is possible to reduce the possibility that single sign-on authentication will not function properly.

1 is a schematic diagram showing a configuration example of an authentication system according to a first embodiment; FIG. 4 is a sequence diagram showing an example of 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 . 2 is a functional block diagram showing a configuration example of a main part of an IdP server in FIG. 1. 5 is a flowchart showing an example of main processing contents of the IdP server in FIG. 4 . 5 is a flowchart showing an example of main processing contents of the IdP server in FIG. 4 . FIG. 11 is a sequence diagram showing an example of processing contents in an authentication system according to the second embodiment. FIG. 11 is a sequence diagram showing an example of processing contents in the underlying authentication system.

The following describes in detail an embodiment of the present invention with reference to the drawings. In all drawings used to explain the embodiment, the same components are generally designated by the same reference numerals, and repeated explanations will be omitted.

(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. The authentication system shown in Fig. 1 applies an SSO authentication method. 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, etc.

The authentication system shown in FIG. 1 comprises a client device 10, an SP server 11, an IdP server 12, and a network 13 connecting these. The network 13 is, for example, the Internet, and is responsible for Layer 3 (L3) relay processing, etc. 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, for example. The SP server 11 and the IdP server 12 are also realized by a computer system including, for example, a processor and a memory.

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 ease of explanation, one SP server 11 is provided here, but typically multiple SP servers 11 can be provided.

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 to the SP server 11 indicating the authentication result obtained in the SSO authentication processing. In other words, the SSO authentication server 12 authenticates the client device 10 on behalf of the SP server 11.

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

Then, in response to the authentication request from the SP server 11, the IdP server 12 performs SSO authentication processing with the client device 10 (step S103). This authentication processing can use various methods, such as ID/password authentication and session cookie authentication. Next, the IdP server 12 uses HTTP redirection or the like to send an authentication result response, which is one of the SAML responses, to the SP server 11 via the client device 10 (step S104).

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.

Now, let us consider a case where 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 services provided by the SP server 11 will be stopped. Furthermore, this may result in a higher access load on the SP server 11, which may result in a longer recovery time for the services.

In addition, the SP server 11 may not be able to properly send an authentication request as shown in step S102 in FIG. 7. Even if the SP server 11 is able to send an authentication request, it may not be able to properly receive a response from the IdP server 12 as shown in step S104 in FIG. 7.

In this way, when the load on the SP server 11 becomes high, there is a high possibility that SSO authentication will not function properly even if the IdP server 12 has sufficient resources. Furthermore, there is a risk that the period during which SSO authentication functions are not functioning will be extended. Therefore, it is beneficial to use the method of the embodiment described below.

<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 status of the SP server 11, which is a service providing server (step S201). In detail, the IdP server 12 starts periodically acquiring the load status of the SP server 11 (steps S202, S206).

Then, the IdP server 12 determines 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 determines 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 determines the load state acquired in step S202 to be a high-load state, and then determines the load state acquired in step S206 to be a low-load state.

Specific methods for acquiring the load state of the SP server 11 include, for example, the following methods. In one method, the IdP server 12 measures the time required to send a specific request to the SP server 11 and then receive 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 the reference state, and the IdP server 12 determines that the state is high-loaded if the measured required time is longer than the reference time, and determines that the state is low-loaded if the measured required time is shorter than the reference time.

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

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 the IdP server 12 comparing the state with a reference state, and various other methods can be used. For example, the SP server 11 itself may determine whether the server is in a high-load state or a low-load state, and the IdP server 12 may simply obtain the result of the determination made by the SP server 11.

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, 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.

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.

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 has been registered in advance in the IdP server 12 as an SSO linked server.

In the web screen 20b, the SP server [1] is in a high load state and therefore cannot be selected by the client 15. On the other hand, the 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 the client device 10 from accessing the SP server 11, which is in a high load state.

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, for example. 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 possible.

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 previously described 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.

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).

In step S103, the Idp server 12 performs authentication processing based on, for example, a session cookie stored in the browser of the client device 10 following the authentication processing 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.

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, the SP server 11 responds to the client device 10 as to whether or not login is permitted (step S105).

By using a sequence such as that shown in FIG. 2, it is possible to prevent access from the client device 10 to the SP server 11, which is in a high load state. This makes it possible to prevent further load from being placed on the SP server 11, and, for example, to reduce the possibility of service interruptions in the SP server 11 and the possibility of service recovery being prolonged. Furthermore, when the SP server 11 is in a high load state, the start trigger for SSO authentication targeting that SP server 11, i.e., step S101 in FIG. 7, can be stopped. As a result, it is possible to reduce the possibility that SSO authentication will not function properly. It may also be possible to shorten the period during which SSO authentication is out of function.

<Details of IdP server (SSO authentication server)>
Fig. 4 is a functional block diagram showing a configuration example of a 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 notifying unit 24, an authentication result responding unit 25, a load status acquiring unit 26, and a load status determining unit 27.

The SSO authentication DB23 is stored in memory. The other components are realized, for example, by a processor executing a program stored in memory. However, implementation is not limited to software using such a processor, and hardware implementation using a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC) may also be used as appropriate.

The login request receiving unit 20 receives a login request from the client device 10, notifies the access permission notification unit 24 of the request, 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 of the request, and causes the authentication processing unit 22 to perform authentication processing.

For example, the ID/password to be authenticated is registered in the SSO authentication DB 23. The authentication processing unit 22 performs SSO authentication processing with the client device 10 by checking the input ID/password against the SSO authentication DB 23, confirming the transmitted session cookie, and the like, and outputs an authentication result of authentication permission or authentication denial. This executes the processing of steps S203, S204, S102, and S103 in FIG. 2.

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.

When the load state determination unit 27 determines that the load state is high, the access permission notification 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 state determination unit 27 determines that the load state is high, the access permission notification 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.

On the other hand, the access permission notification unit 24 receives a 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 notification 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.

The authentication result response unit 25 transmits to the SP server 11 a response of the authentication result by the authentication processing unit 22 in response to an authentication request from the SP server 11. More specifically, when the result of the determination by the load state determination unit 27 is a low load state, 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 result of the determination by the load state determination unit 27 is a high load state, the authentication result response unit 25 does not transmit a response of the authentication result.

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

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

Furthermore, after step S304, the access permission notification unit 24 determines whether the judgment result of the load state judgment unit 27 has changed from a high load state to a low load state (step S305). Then, if the judgment result has changed from a high load state to a low load state (step S305: Yes), the access permission notification unit 24 notifies the client device 10 that access to the SP server 11 has become possible (step S306).

In FIG. 5B, the IdP server 12 receives a request from the client device 10 or the SP server 11 (step S401). The IdP server 12 then 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).

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 notification unit 24 notifies the client device 10 that access to the SP server 11 is not possible (step S404). That is, the access permission notification unit 24 causes the client device 10 to display, for example, a web screen 20b as shown in FIG. 3.

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 notification unit 24 notifies the client device 10 that access to the SP server 11 is possible (step S405). That is, the access permission notification unit 24 causes the client device 10 to display, for example, a web screen 20c as shown in FIG. 3.

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 notification 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 send 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 sends a response to the authentication result obtained by the authentication processing unit 22 to the SP server 11 (step S408).

The sequence shown in FIG. 2 is a mechanism that prevents the client device 10 from accessing the SP server 11 when the load is high, and therefore, in principle, prevents an authentication request from the SP server 11 when the load is high. For this reason, when using the sequence shown in FIG. 2, the process does not generally reach step S407 in FIG. 5B.

<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 is required to allow the client device 10 to access the IdP server 12 before the SP server 11.

Such a mechanism can be realized, for example, by operating a network. One specific example is a method of configuring the client device 10 at startup so that logging in to the IdP server 12 occurs at startup. Another specific example is a method of allowing the client device 10 to use the IdP server 12 as a portal site.

<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.

(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 the same as that in Fig. 1. Fig. 6 shows the operation when the client device 10 accesses the SP server 11 before the IdP server 12, as in Fig. 7, unlike the case in Fig. 2.

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

Here, unlike the case of FIG. 7 and further unlike 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).

Furthermore, if 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 send 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, if 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 sends a response of the authentication result to the SP server 11 via the client device 10.

After that, in step S504, the IdP server 12 acquires the load state of the SP server 11 in conjunction 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, in the stages of steps S503 and S505.

When the client device 10 accesses the SP server 11 based on the operation by the client 15 in response to step S505 (step S101b), the same process as in FIG. 7 is performed thereafter. Briefly, 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).

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 as to whether or not login is possible, depending on the contents of the received response of the authentication result (step S105). The IdP server 12 also stops monitoring the load status of the SP server 11 (step S506).

By using the sequence shown in FIG. 6, it is possible to stop the IdP server 12 from sending a response to the SP server 11, which is 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 not possible, it is possible to prevent further access from the client device 10 to the SP server 11. As a result, it is possible to reduce the possibility that SSO authentication will not function properly. It may also be possible to shorten the period during which SSO authentication is out of function.

<Details of IdP server (SSO authentication server)>
The configuration and operation of the IdP server 12, which is an SSO authentication server, are almost the same as those in Fig. 4, Fig. 5A, and Fig. 5B. The main difference from the first embodiment is that in the second embodiment, the flowchart shown in Fig. 5A is executed after receiving an authentication request from the SP server 11, and if the acquired load state is a high load state, it is executed periodically thereafter until it changes to a low load state.

In addition, in FIG. 5B, in the first embodiment, as described above, the process of step S407 is not generally reached, but in the second embodiment, as shown in step S503 in FIG. 6, the process of step S407 can be executed. However, unlike the first embodiment, the process of steps S404 and S405 is not generally reached.

<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, as in the case of the first embodiment, it is possible to reduce the possibility that the SSO authentication will not function normally.

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 an authentication request in response to the access (step S102a) is not sent. Therefore, in order to improve the effect, it is desirable to use the method of the first embodiment.

The invention made by the 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 explain the invention in an easy-to-understand manner, and the invention is not necessarily limited to having all of the configurations described. It is also possible to replace 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. It is also possible to add, delete, or replace part of the configuration of each embodiment with other configurations.

For example, the various programs described above can 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.

10...Client device, 11...SP server (service provider server), 12...IdP server (SSO authentication server), 15...Client, 20...Login request receiving unit, 21...Authentication request receiving unit, 22...Authentication processing unit, 24...Accessibility notification unit, 25...Authentication result response unit, 26...Load status acquisition unit, 27...Load status determination unit

Claims (14)

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. 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. The authentication system according to claim 2,
The SSO authentication server periodically acquires the load status.
Authentication system. 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. 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, performing the authentication process with the client device in response to the authentication request, and transmitting a response of the authentication result 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. 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. The authentication system according to claim 6,
The SSO authentication server includes:
If the acquired load state is the high load state, the load state is periodically acquired;
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. 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 that acquires 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. 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. The authentication server according to claim 9,
The load condition acquisition unit periodically acquires the load condition.
Authentication server. 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. 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. 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. 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