WO2024100843A1 - 通信システム、サーバ、および通信方法 - Google Patents

通信システム、サーバ、および通信方法 Download PDF

Info

Publication number
WO2024100843A1
WO2024100843A1 PCT/JP2022/041931 JP2022041931W WO2024100843A1 WO 2024100843 A1 WO2024100843 A1 WO 2024100843A1 JP 2022041931 W JP2022041931 W JP 2022041931W WO 2024100843 A1 WO2024100843 A1 WO 2024100843A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
server
login
private key
user
Prior art date
Application number
PCT/JP2022/041931
Other languages
English (en)
French (fr)
Inventor
堅登 西辻
悠平 坂東
Original Assignee
三菱電機株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 三菱電機株式会社 filed Critical 三菱電機株式会社
Priority to PCT/JP2022/041931 priority Critical patent/WO2024100843A1/ja
Publication of WO2024100843A1 publication Critical patent/WO2024100843A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/41—User authentication where a single sign-on provides access to a plurality of computers

Definitions

  • This disclosure relates to a communication system, a server, and a communication method.
  • Patent Document 1 discloses a system that realizes so-called single sign-on.
  • Single sign-on is a technology that allows a user to log in to multiple servers with a single login operation.
  • the present disclosure has been made to solve these problems, and its purpose is to enable convenient login to a server.
  • the communication system of the present disclosure includes a first device, a second device, and a third device.
  • the first device has a first memory that stores a first private key.
  • the second device has a second memory that stores a second private key that is the same as the first private key.
  • the third device transmits the first data to the first device when an operation including inputting the first data is performed by a user to log in to the first device.
  • the first device determines whether or not the login to the first device is successful based on the first data. If the login to the first device is successful, the second data is generated based on the first private key and the first data.
  • the first device transmits the second data to the third device.
  • the third device transmits the second data to the second device without the first data being input.
  • the second device verifies the second data using the second private key, and approves the login to the second device if the second data is valid.
  • the communication system of the present disclosure includes a first device and a second device.
  • the first device has a memory that stores a private key.
  • the second device includes input of first data and transmits the first data to the first device when a login operation to the first device is performed by a user.
  • the first device performs user authentication based on the first data. If the user authentication is successful, the first device generates second data from the first data using the private key.
  • the first device transmits the second data to the second device.
  • the second device transmits the second data to the first device without the first data being input.
  • the first device verifies the second data using the private key, and approves login to the first device if the second data is valid.
  • the server of the present disclosure includes an interface for communicating with a client device, a memory for storing a private key, and a processor.
  • the processor performs user authentication based on the first data, which includes input of first data, and is transmitted from the client device when a login operation to the server is performed by a user on the client device. If the user authentication is successful, the processor generates second data from the first data using the private key. The processor transmits the second data to the client device. The processor verifies the second data transmitted from the client device without inputting the first data using the private key, and approves login to the server if the second data is valid.
  • the communication method of the present disclosure is executed by a first device, a second device, and a third device.
  • the communication method includes the third device transmitting first data to the first device when an operation for logging in to the first device and including inputting the first data is performed by a user.
  • the communication method includes the first device determining whether or not logging in to the first device is successful based on the first data.
  • the communication method includes the first device generating second data based on a first private key and the first data when logging in to the first device is successful.
  • the communication method includes the first device transmitting the second data to the third device.
  • the communication method includes the third device transmitting the second data to the second device without inputting the first data.
  • the communication method includes the second device verifying the second data using a second private key that is the same as the first private key, and approving the login to the second device if the second data is valid.
  • the communication method of the present disclosure is executed by a server communicating with a client device.
  • the communication method includes inputting first data and performing user authentication based on the first data transmitted from the client device when a login operation to the server is performed by a user on the client device.
  • the communication method includes generating second data from the first data using a private key if the user authentication is successful.
  • the communication method includes transmitting the second data to the client device.
  • the communication method includes verifying the second data transmitted from the client device without inputting the first data using the private key, and approving login to the server if the second data is valid.
  • logging in to a server can be conveniently achieved.
  • FIG. 1 is a diagram illustrating a configuration example of a communication system according to a first embodiment.
  • FIG. 2 is a diagram illustrating a hardware configuration of a client device and the like.
  • FIG. 13 illustrates an example of a user table.
  • FIG. 2 is a functional block diagram of a first server, a second server, etc.
  • FIG. 1 illustrates an example of a communication system of a comparative example. 2 is a flowchart showing a process flow according to the first embodiment;
  • FIG. 13 is a diagram illustrating a method for registering a common key.
  • FIG. 11 is a diagram for explaining a configuration example of a communication system according to a second embodiment.
  • FIGS. 13A to 13C are diagrams illustrating an example of a transition of a screen displayed by a display device according to a second embodiment.
  • FIG. 13 is a diagram illustrating a configuration example of a communication system according to a third embodiment.
  • 13 is a flowchart showing a process flow according to a third embodiment.
  • FIG. 1 is a diagram showing a configuration example and a process flow of a communication system 500 according to the present embodiment.
  • a first server 100 corresponds to the "first device” of the present disclosure
  • the second server 200 corresponds to the "second device” of the present disclosure
  • the client device 300 corresponds to the "third device” of the present disclosure.
  • the client device 300 is a device that can be operated by a user, such as a PC (Personal Computer), a tablet terminal, or a smartphone.
  • the first server 100 holds a common key 150.
  • the second server 200 holds a common key 150.
  • the common key 150 held by the first server 100 and the common key 150 held by the second server 200 are the same secret key.
  • the common key 150 possessed by the first server 100 corresponds to the "first secret key” in the present disclosure
  • the common key 150 possessed by the second server 200 corresponds to the "second secret key” in the present disclosure.
  • the communication system 500 of this embodiment realizes single sign-on (SSO: Single Sign On).
  • SSO Single Sign On
  • a login operation including input of user data is performed on the first server 100 by the single sign-on and login to the first server 100 is successful
  • login to the second server 200 can be approved without inputting user data corresponding to the second server 200. Therefore, the burden on the user can be reduced in that the user does not have to input user data corresponding to the second server 200.
  • the client device 300 displays a login screen (see, for example, FIG. 9(A) described below).
  • a user performs a login operation on the login screen.
  • the login operation is an operation for logging in to the first server 100 and includes input of user data.
  • the user data is, for example, a user name (user ID (identification)) and a password.
  • the user data corresponds to the "first data" of this disclosure.
  • the client device 300 transmits the input user data to the first server 100.
  • step (2) the first server 100 performs user authentication based on the user data transmitted from the client device 300.
  • User authentication is a process for determining whether login to the first server 100 has been successful. If the user authentication is successful, the first server 100 generates a token from the user data using the common key 150. The method of generating the token will be described later. The token corresponds to the "second data" of this disclosure.
  • step (3) the first server 100 transmits the generated token to the client device 300.
  • step (4) the client device 300 transmits the token to the second server 200 without inputting user data for logging in to the second server 200.
  • the address of the second server 200 (second server information) is stored in the client device 300, for example, in the following first or second method.
  • the client device 300 generates a common key.
  • a management device (not shown) or the like causes the client device 300 to store the address of the second server 200.
  • the first server 100 may transmit the address of the second server 200 together with the token.
  • the client device 300 stores the transmitted address of the second server 200.
  • the second server 200 verifies the token using the common key 150.
  • the method of token verification will be described later.
  • the second server 200 determines whether or not to approve login to the second server 200 by verifying the token. If the token verification determines that the token is valid, the second server 200 approves login to the second server 200 by the client device 300. On the other hand, if the token verification determines that the token is invalid, the second server 200 prohibits approval of login to the second server 200 by the client device 300.
  • the client device 300 sends a request signal to the first server 100, and the first server 100 sends data (service) corresponding to the request signal to the client device 300. Also, if login to the second server 200 is successful, the client device 300 sends a request signal to the second server 200, and the second server 200 sends data (service) corresponding to the request signal to the client device 300.
  • the communication system 500 in FIG. 1 As shown in part ⁇ in FIG. 1, communication between the first server 100 and the second server 200 is not required. Therefore, the communication system 500 can advantageously realize single sign-on (login to a server) while simplifying the configuration of the communication system 500.
  • Fig. 2 is a diagram showing a hardware configuration of the client device 300.
  • the client device 300 includes a CPU (Central Processing Unit) 381 that executes a program, a ROM (Read Only Memory) 382 that stores data in a non-volatile manner, a RAM (Random Access Memory) 383 that stores data in a volatile manner, a display device 385, an input device 386, and a communication I/F (Interface) 388.
  • the display device 385 corresponds to the "display" in the present disclosure.
  • the communication I/F 388 of the client device 300 is capable of communicating with the first server 100 and the second server 200 via the network 670.
  • the processing in the client device 300 is realized by each piece of hardware and a program executed by the CPU 381. Such a program may be stored in advance in the ROM 382 or the like.
  • the CPU 381 reads the program from the ROM 382.
  • the input device 386 is, for example, a keyboard or a pointing device such as a mouse, and accepts commands from the user (for example, input of user data).
  • the display device 385 is, for example, a liquid crystal display (LCD) panel, and displays a screen (for example, a login screen) to the user.
  • LCD liquid crystal display
  • the display device 385 and the input device 386 are integrally formed.
  • the first server 100 includes a CPU 181 that executes programs, a ROM 182 that stores data in a non-volatile manner, a RAM 183 that stores data in a volatile manner, and a communication I/F 188.
  • the communication I/F 188 of the first server 100 is capable of communicating with the client device 300 via the network 670.
  • the first server 100 and the second server 200 are configured not to communicate with each other.
  • the first server 100 also holds a common key 150 and a user table 650, which will be described later.
  • the common key 150 and the user table 650 are stored in the ROM 182.
  • the second server 200 includes a CPU 281 that executes programs, a ROM 282 that stores data in a non-volatile manner, a RAM 283 that stores data in a volatile manner, and a communication I/F 288.
  • the communication I/F 288 of the second server 200 is capable of communicating with the client device 300 via the network 670.
  • the second server 200 is configured not to communicate with the first server 100.
  • the second server 200 also holds a common key 150 and a user table 650.
  • the common key 150 and the user table 650 described below are stored in the ROM 282.
  • a "processor” is configured from a CPU, ROM, RAM, etc.
  • the processor is also called a "control circuit.”
  • FIG. 3 is an example of a user table 650.
  • the user table 650 is a table in which the user data of each of a plurality of legitimate users is defined in association with an ID.
  • the user data is composed of a user name and a password.
  • a user name A1 and a password P1 are stored as one piece of user data, and Q1 is associated with the user data as an ID.
  • a user name A2 and a password P2 are stored as one piece of user data, and Q2 is associated with the user data as an ID.
  • User data is determined by the user. Furthermore, an ID is created based on the user data by a management device (not shown) or the like.
  • the management device is a device operated by an administrator who has authority over the communication system 500.
  • the management device registers a new user, a registration request and user data are transmitted from the client device 300 to the management device.
  • the management device Upon receiving the registration request and user data, the management device generates an ID using random numbers or the like.
  • the management device then transmits the user data and ID to the first server 100 and the second server 200.
  • the first server 100 and the second server 200 add the user name and password to the user table 650.
  • the user table 650 held by the first server 100 and the user table 650 held by the second server 200 are the same.
  • Fig. 4 is a functional block diagram of the first server 100, the second server 200, etc.
  • a token is used, and the token in this embodiment is a token based on JKT (JSON Web Token). Note that the token may be another token.
  • the first server 100 has a communication unit 102, an authentication unit 104, a generation unit 106, and a storage unit 108.
  • a user table 650 (see FIG. 3) and a common key 150 are stored in the storage unit 108.
  • the communication unit 102 corresponds to the communication I/F 188 and the like.
  • the authentication unit 104 and the generation unit 106 correspond to the CPU 181 and the like.
  • the storage unit 108 corresponds to the ROM 182 and the like.
  • the second server 200 has a communication unit 202, a verification unit 204, and a storage unit 208.
  • the storage unit 208 stores a user table 650 (see FIG. 3) and a common key 150.
  • the communication unit 202 corresponds to the communication I/F 288 and the like.
  • the verification unit 204 corresponds to the CPU 281 and the like.
  • the storage unit 208 corresponds to the ROM 282 and the like.
  • the display device 385 of the client device 300 displays a login screen for the first server 100, and the user inputs user data on the login screen.
  • the client device 300 transmits the user data to the first server 100 (see step (1) in FIG. 1).
  • the authentication unit 104 refers to the user table 650 (see FIG. 3) and performs user authentication based on the user data. Specifically, the authentication unit 104 determines whether the user data (combination of user name and password) exists in the user table 650.
  • the authentication unit 104 determines that the user authentication has been successful. The authentication unit 104 then refers to the user table 650 to extract the ID corresponding to the user data, and outputs the ID to the generation unit 106. On the other hand, if the user data does not exist in the user table, the authentication unit 104 determines that the user authentication has failed. The first server 100 then sends a signal to the client device 300 indicating that the user authentication has failed.
  • the generation unit 106 generates a token based on the common key 150 and the user data.
  • An example of a method for generating a token is described below.
  • the generation unit 106 generates first token data and second token data using an ID corresponding to the user data and the common key 150.
  • the generation unit 106 then generates a token by combining the first token data and the second token data.
  • the generation unit 106 creates a "signature-less token" by executing a first operation on the ID.
  • This signature-less data corresponds to the first token data.
  • the generation unit 106 then generates a "signature” by applying the common key 150 to the signature-less token (first token data) (for example, by encrypting the signature-less token).
  • This signature corresponds to the second token data.
  • the generation unit 106 then generates a token by combining the first token data (signature-less token) and the second token data (signature).
  • An expiration date is set for the token.
  • Other information for example, a hash may also be used to generate the token.
  • the generation unit 106 When the generation unit 106 generates the token, it transmits the token to the client device 300 via the communication unit 102. In addition, when the user performs an operation to log in to the second server, it transmits the token to the second server 200.
  • the token is output to the verification unit 204.
  • the verification unit 204 verifies the token based on the user table 650 (see FIG. 3) and the public key (second private key) stored in the storage unit 208. An example of a method for verifying a token is described below.
  • the verification unit 204 divides the token into first token data (unsigned token) and second token data (signature). The verification unit 204 then generates a "provisional signature" (also referred to as "third token data") by applying the common key 150 to the unsigned token (for example, by encrypting the unsigned token). The verification unit 204 then compares the second token data (signature) with the third token data (provisional signature).
  • provisional signature also referred to as "third token data”
  • the verification unit 204 extracts an ID by executing a second operation on the unsigned token.
  • the second operation is the inverse operation of the first operation described above. Then, if the verification unit 204 determines that this ID exists in the user table 650 in the storage unit 208, it determines that the token is valid. If the token is valid, the second server 200 approves login to the second server 200. On the other hand, if the second token data and the third token data are different, the verification unit 204 determines that the token is invalid. Also, if the ID extracted by executing the above-mentioned second operation does not exist in the user table 650 in the storage unit 208, the verification unit 204 determines that the token is invalid. If the token is invalid, the second server 200 prohibits login to the second server.
  • the verification unit 204 transmits the verification result (information indicating whether or not login to the second server 200 is possible) to the client device 300 via the communication unit 202.
  • the client device 300 notifies the user of the verification result (whether or not login to the second server 200 is possible).
  • a configuration may be adopted in which, if the second token data and the third token data match, the verification unit 204 determines that the token is valid.
  • the verification unit 204 determines that the token is invalid.
  • the user table 650 in the storage unit 208 is not necessary.
  • the verification unit 204 may compare the second token data (signature) with the third token data (provisional signature), thereby improving the security of the communication system 500. As a modified example, the verification unit 204 may not perform this comparison.
  • [Comparison with Comparative Example] 5 is a diagram showing an example of a communication system 500L of a comparative example. Single sign-on is also realized in the communication system 500L.
  • the second server 200L does not have a private key, and is configured so that the first server 100L and the second server 200L communicate with each other.
  • the method of the communication system 500L of the comparative example is also called an "agent method.”
  • step (1) the client device 300L transmits user data.
  • the first server 100L generates a token based on the user data and the private key 150L.
  • step (3) the first server 100 transmits the token to the client device 300.
  • step (4) the client device 300 transmits the token to the second server.
  • step (51) the second server 200L requests the first server 100L to verify the token.
  • the first server 100L verifies the token using the private key 150L, and in step (52), transmits the verification result to the second server 200L.
  • step (6) the second server 200L transmits the verification result to the client device 300.
  • a communication function (communication path) between the first server 100L and the second server 200L is required.
  • this communication function is required, the configuration of the communication system 500L becomes complicated. For example, if the designer who builds the communication system 500L is not very skilled, the burden on the designer may increase.
  • the first server 100 and the second server 200 hold the same common key 150.
  • the first server 100 generates a token using the common key 150 of the first server 100
  • the second server 200 verifies the token using the common key 150 of the second server 200. Therefore, the communication system 500 of this embodiment can generate and verify a token without requiring a communication function between the first server 100 and the second server 200 (see part ⁇ in FIG. 1). Therefore, the communication system 500 of this embodiment can advantageously realize single sign-on (login to a server) in that the configuration of the communication system 500 can be simplified.
  • FIG. 6 is a flowchart showing the flow of processing executed by the client device 300, the first server 100, and the second server 200.
  • step S1 the client device 300 displays a login screen on the display device 385.
  • step S2 the client device 300 determines whether or not a login operation to the first server 100 has been performed by the user.
  • step S4 the client device 300 transmits the user data entered by the user through this login operation to the first server 100 (see step (1) in FIG. 1).
  • the first server 100 refers to the user table 650 (see FIG. 3) and performs user authentication based on the user data. In step S6, the first server 100 determines whether the user authentication is successful. If the user authentication is successful (YES in step S6), the process proceeds to step S8. On the other hand, if the user authentication is unsuccessful (NO in step S6), the process in FIG. 6 ends.
  • step S8 the first server 100 generates a token (see step (2) in FIG. 1). Then, in step S10, the first server 100 transmits the token to the client device 300 (see step (3) in FIG. 1).
  • step S12 the client device 300 determines whether or not the user has performed a login operation to the second server 200.
  • step S12 the client device 300 waits until the user has performed a login operation to the second server 200 (NO in step S12). Then, if the user has performed a login operation to the second server 200 (YES in step S12), in step S14, the client device 300 transmits the token transmitted in step S10 to the second server 200 (see step (4) in FIG. 1).
  • step S16 the second server 200 verifies the token (see step (5) in FIG. 1). Then, in step S18, the second server 200 transmits the verification result (see step (6) in FIG. 1).
  • the communication system 500 also employs the following first or second configuration.
  • the first configuration provides the services of the first server 100 and the second server 200 only if login to both the first server 100 and the second server 200 is successful.
  • the first configuration also provides neither the services of the first server 100 nor the services of the second server 200 if login to the first server 100 is successful but login to the second server 200 is unsuccessful.
  • the first server 100 provides the services of the first server 100, regardless of whether the login to the second server 200 is successful or not. Also, in the second configuration, if the login to the second server 200 is successful, the second server 200 provides the services of the second server 200, and if the login to the second server 200 fails, the second server 200 does not provide the services of the second server 200.
  • the common key 150 is created by a device different from either the first server 100 or the second server 200.
  • the device that creates the common key 150 corresponds to the "creation device" of the present disclosure.
  • FIG. 7 is a diagram for explaining a method for registering the common key 150.
  • FIG. 7 discloses an example in which the creation device is a client device 300.
  • the client device 300 that creates the common key 150 may be the same as the client device 300 shown in FIG. 1, or may be different.
  • the client device 300 in FIG. 7 has a creation unit 302 that creates the common key 150.
  • the creation of the shared key 150 is performed, for example, by an administrator of the communication system 500.
  • the administrator of the communication system 500 executes a login operation on the client device 300.
  • This login operation is for the purpose of creating the shared key 150 and includes inputting administrator data into the client device 300.
  • the administrator data is, for example, an administrator name (administrator ID) and a password.
  • the administrator data corresponds to the "third data" of this disclosure.
  • the client device 300 transmits the administrator data entered by the administrator to the first server 100 and the second server 200.
  • the first server 100 and the second server 200 perform administrator authentication based on the administrator data.
  • the first server 100 and the second server 200 hold an administrator table in which one or more valid administrator data are specified, and perform administrator authentication by determining whether the administrator data transmitted from the client device 300 is specified in the administrator table. If the administrator data is specified in the administrator table, the administrator authentication is successful, and if the administrator data is not specified in the administrator table, the administrator authentication is unsuccessful.
  • step (23) the first server 100 and the second server 200 transmit the authentication results. If both the administrator authentication by the first server 100 and the administrator authentication by the second server 200 are successful, the creation unit 302 of the client device 300 creates the common key 150. The creation unit 302 creates the common key 150 using random numbers, for example. Furthermore, if at least one of the administrator authentication by the first server 100 and the administrator authentication by the second server 200 fails, the creation unit 302 is prohibited from creating the common key 150.
  • the creation unit 302 When the creation unit 302 creates the common key 150, it transmits the common key 150 to the first server 100 and the second server 200.
  • the first server 100 stores (registers) the common key 150 in the ROM 182
  • the second server 200 stores (registers) the common key 150 in the ROM 282.
  • the first server 100 creates the common key 150 and transmits the common key 150 to the second server 200.
  • a communication function between the first server 100 and the second server 200 is required.
  • a creation device different from the first device and the second device creates the common key 150 and transmits it to the first server 100 and the second server 200. Therefore, according to the communication system 500 of FIG. 7, the common key 150 can be appropriately created without requiring a communication function between the first server 100 and the second server 200.
  • the client device 300 creates the common key 150 if both the administrator authentication by the first server 100 and the administrator authentication by the second server 200 are successful. Therefore, the security of the common key 150 can be improved compared to a configuration in which the common key 150 is created if either the administrator authentication by the first server 100 or the administrator authentication by the second server 200 is successful.
  • the client device 300 is an installed remote controller such as a system controller, the common key 150 is created in advance at the time of installation.
  • Embodiment 2 a communication system will be described in which the communication system 500 described in the first embodiment is applied to the management of air conditioners.
  • Fig. 8 is a diagram for explaining a configuration example of a communication system 700 according to the second embodiment.
  • the first server 100 is associated with at least one first air conditioner 401.
  • the first server 100 is connected to each of the at least one first air conditioner 401.
  • the first server 100 manages (controls) the at least one first air conditioner 401.
  • the second server 200 is also associated with at least one second air conditioner 402. Typically, the second server 200 is connected to each of the at least one second air conditioner 402.
  • the second server 200 manages (controls) the at least one second air conditioner 402.
  • the first air conditioner 401 is installed in a first facility (first building)
  • the second air conditioner 402 is installed in a second facility (second building) different from the first facility.
  • At least one first air conditioner 401 constitutes a first air conditioner group 401A. Also, at least one second air conditioner 402 constitutes a second air conditioner group 402A.
  • the services of the first air conditioner group 401A are sent to the client device 300.
  • “Services of the first air conditioner group 401A” refers to the display of the management screen of the first air conditioner group 401A.
  • the services of the second air conditioner group 402A are sent to the client device 300.
  • “Second air conditioner group 402A” refers to the display of the management screen of the second air conditioner group 402A.
  • the management screen refers to a screen for controlling the air conditioners, and a screen that displays the settings of the air conditioners, etc.
  • the management screen may be a screen that accepts changes to the settings by the user.
  • FIG. 9 is a diagram showing an example of the transition of screens displayed by the display device 385 of this embodiment.
  • FIG. 9(A) is a diagram showing an example of a login screen for the first server 100. In this login screen, an input area 392 is displayed. The user inputs user data in the input area 392.
  • the input area 392 includes an input area for a user name and an input area for a password.
  • the first server 100 causes the display device 385 to display a management screen for the first air conditioner group 401A (see FIG. 8).
  • the management screen for the first air conditioner group 401A is also referred to as the "first management screen.”
  • FIG. 9(B) is an example of the first management screen.
  • a setting value image 393 of at least one first air conditioner (first air conditioner A to first air conditioner N) that constitutes the first air conditioner group 401A is displayed.
  • the setting value image 393 is an image that shows the setting value of each of the first air conditioners that constitute the first air conditioner group 401A.
  • the setting temperature of the first air conditioner A to first air conditioner N is displayed as the setting value image 393.
  • other setting values (such as air volume) may be displayed as the setting value image 393.
  • a login button 394 is displayed.
  • the login button 394 is a button for performing a login operation to the second server 200 (see step S12 in FIG. 6).
  • the client device 300 transmits a token (see step (4) in FIG. 1 and step S14 in FIG. 6).
  • the second server 200 causes the display device 385 to display a management screen for the second air conditioner group 402A (see FIG. 8).
  • the management screen for the second air conditioner group 402A is also referred to as the "second management screen.”
  • FIG. 9(C) is an example of the second management screen.
  • the second management screen of FIG. 9(C) displays a setting value image 395 of at least one second air conditioner (second air conditioner A to second air conditioner M) that constitutes the second air conditioner group 402A.
  • the setting value image 395 is an image that shows the setting values of each of the second air conditioners that constitute the second air conditioner group 402A.
  • the setting temperatures of the second air conditioners A to M are displayed as the setting value image 395.
  • a switch button 396 is displayed.
  • the switch button 396 is a button for switching to the first management screen.
  • the client device 300 switches the display from the second management screen to the first management screen. Note that, when login to the second server 200 is successful, the switch button for switching to the second management screen may be on the first management screen.
  • the first management screen and the second management screen can be displayed on the display device 385 of the client device 300 without requiring a communication function between the first server 100 and the second server 200. Therefore, it is possible to allow the user to manage the first air conditioner 401 and the second air conditioner 402 while simplifying the configuration of the communication system 700.
  • the communication system 700 displays the second management screen without displaying the login screen of the second server 200, that is, without requiring the user to enter user data for logging in to the second server 200. Therefore, single sign-on can be appropriately achieved, reducing the burden on the user.
  • a configuration may be adopted in which the processing of step S12 is omitted. If such a configuration is adopted, the client device 300 transmits the token transmitted in step S6 to the second server 200 in step S14. In other words, when a login operation to the first server 100 is performed, the success or failure of login to the first server 100 and the success or failure of login to the second server 200 are automatically determined. Also, if a configuration is adopted in which the processing of step S12 is omitted in the communication system 700, the login button 394 is not displayed.
  • the communication systems of the first and second embodiments have been described as having two servers (first server 100 and second server 200). However, the communication system may also have a configuration including three or more servers.
  • Embodiment 3 In the above-described embodiment, a communication system has been described that includes the client device 300, the first server 100, and the second server 200.
  • a communication system 500A according to the third embodiment includes one server (the first server 100) and the client device 300.
  • FIG. 10 is a diagram showing an example of the configuration of a communication system 500A according to the third embodiment.
  • the token transmitted in step (3) is transmitted to the first server 100 (step (4A)).
  • this login operation does not include an operation of inputting user data.
  • the first server 100 verifies the token sent in step (4A) (step (5A)). If the token verification reveals that the token is valid, the client device 300 continues logging in to the first server 100. On the other hand, if the second server 200 verifies that the token is invalid, it terminates the client device 300's login to the first server 100. The first server 100 sends the verification result to the client device 300 (step (6A)).
  • FIG. 11 is a flowchart showing the flow of processing executed by the client device 300 and the first server 100 in the third embodiment.
  • the client device 300 transmits a token to the first server 100.
  • a data request signal is transmitted to the first server 100 in step S14A.
  • the data request signal is a signal for requesting data from the first server 100.
  • the data is, for example, data for an air conditioner management screen (see FIG. 9).
  • step S16A the first server 100 verifies the token. Then, in step S18A, the first server 100 transmits the verification result. Note that if the token is found to be invalid as a result of the token verification in step S16A, the data requested in the data request signal transmitted in step S14A is not transmitted to the client device 300.
  • First server 100 First server, 102, 202 Communication unit, 104 Authentication unit, 106 Generation unit, 108, 208 Storage unit, 150 Common key, 200 Second server, 204 Verification unit, 300 Client device, 302 Creation unit, 385 Display device, 386 Input device, 392 Input area, 393, 395 Setting value image, 394 Login button, 396 Switch button, 401 First air conditioner, 401A First air conditioner group, 402 Second air conditioner, 402A Second air conditioner group, 500, 700 Communication system, 650 User table, 670 Network.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

第１サーバ（１００）は、ユーザデータに基づいて第１サーバ（１００）へのログインの成否を判断する。第１サーバ（１００）は、第１サーバ（１００）へのログインが成功した場合に共通鍵（１５０）およびユーザデータに基づいてトークンを生成する。第１サーバ（１００）は、トークンをクライアント装置（３００）に送信する。クライアント装置（３００）は、ユーザデータが入力されることなくトークンを第２サーバ（２００）に送信する。第２サーバ（２００）は、公開鍵（１５０）を用いてトークンを検証し該トークンが正当であれば第２サーバ（２００）へのログインを承認する。

Description

通信システム、サーバ、および通信方法
　本開示は、通信システム、サーバ、および通信方法に関する。
　特開２００２－３３４０５６号公報（特許文献１）には、いわゆるシングルサインオンを実現させるシステムが開示されている。シングルサインオンは、ユーザによる１回のログイン操作により、複数のサーバにログインできる技術である。
特開２００２－３３４０５６号公報
　通信システムにおいて、より好適にサーバへのログインを実現させることが望まれている。
　本開示は、このような課題を解決するためになされたものであって、その目的は、好適にサーバへのログインを実現させることである。
　本開示の通信システムは、第１装置と、第２装置と、第３装置とを備える。第１装置は、第１秘密鍵を記憶する第１メモリを有する。第２装置は、第１秘密鍵と同一の第２秘密鍵を記憶する第２メモリを有する。第３装置は、第１装置にログインするためでありかつ第１データの入力を含む操作がユーザにより実行されたときに該第１データを第１装置に送信する。第１装置は、第１データに基づいて第１装置へのログインの成否を判断する。第１装置へのログインが成功した場合に第１秘密鍵および第１データに基づいて第２データを生成する。第１装置は、第２データを第３装置に送信する。第３装置は、第１データが入力されることなく第２データを第２装置に送信する。第２装置は、第２秘密鍵を用いて第２データを検証し該第２データが正当であれば第２装置へのログインを承認する。
　本開示の通信システムは、第１装置と、第２装置とを備える。第１装置は、秘密鍵を記憶するメモリを有する。第２装置は、第１データの入力を含みかつ第１装置へのログイン操作がユーザにより実行されたときに該第１データを第１装置に送信する。第１装置は、第１データに基づいてユーザ認証を実行する。第１装置は、ユーザ認証が成功した場合に秘密鍵を用いて第１データから第２データを生成する。第１装置は、第２データを第２装置に送信する。第２装置は、第１データが入力されることなく第２データを第１装置に送信する。第１装置は、秘密鍵を用いて第２データを検証し該第２データが正当であれば第１装置へのログインを承認する。
　本開示のサーバは、クライアント装置と通信するインタフェースと、秘密鍵を記憶するメモリと、プロセッサとを備える。プロセッサは、第１データの入力を含みかつサーバへのログイン操作がユーザによりクライアント装置に対して実行されたときに該クライアント装置から送信された第１データに基づいてユーザ認証を実行する。プロセッサは、ユーザ認証が成功した場合に秘密鍵を用いて第１データから第２データを生成する。プロセッサは、第２データをクライアント装置に送信する。プロセッサは、第１データが入力されることなくクライアント装置から送信された第２データを、秘密鍵を用いて検証し該第２データが正当であればサーバへのログインを承認する。
　本開示の通信方法は、第１装置と、第２装置と、第３装置とにより実行される。通信方法は、第３装置が、第１装置にログインするためでありかつ第１データの入力を含む操作がユーザにより実行されたときに該第１データを第１装置に送信することを備える。通信方法は、第１装置が、第１データに基づいて第１装置へのログインの成否を判断することを備える。通信方法は、第１装置が、第１装置へのログインが成功した場合に第１秘密鍵および第１データに基づいて第２データを生成することを備える。通信方法は、第１装置が、第２データを第３装置に送信することを備える。通信方法は、第３装置が、第１データが入力されることなく第２データを第２装置に送信することを備える。通信方法は、第２装置が、第１秘密鍵と同一の第２秘密鍵を用いて第２データを検証し該第２データが正当であれば第２装置へのログインを承認することを備える。
　本開示の通信方法は、クライアント装置と通信するサーバにより実行される。通信方法は、第１データの入力を含みかつサーバへのログイン操作がユーザによりクライアント装置に対して実行されたときに該クライアント装置から送信された第１データに基づいてユーザ認証を実行することを備える。通信方法は、ユーザ認証が成功した場合に秘密鍵を用いて第１データから第２データを生成することを備える。通信方法は、第２データをクライアント装置に送信することを備える。通信方法は、第１データが入力されることなくクライアント装置から送信された第２データを、秘密鍵を用いて検証し該第２データが正当であればサーバへのログインを承認することを備える。
　本開示によれば、好適にサーバへのログインを実現させることができる。
実施の形態１の通信システムの構成例を示す図である。 クライアント装置などのハードウェア構成を示す図である。 ユーザテーブルの一例を示す図である。 第１サーバおよび第２サーバなどの機能ブロック図である。 比較例の通信システムの一例を示す図である。 実施の形態１の処理の流れを示すフローチャートである。 共通鍵の登録の手法を示す図である。 実施の形態２の通信システムの構成例を説明するための図である。 実施の形態２の表示装置が表示する画面の遷移の一例を示す図である。 実施の形態３の通信システムの構成例を示す図である。 実施の形態３の処理の流れを示すフローチャートである。
　以下、本実施の形態について、図面を参照しながら詳細に説明する。なお、図中の同一または相当部分には同一符号を付してその説明は繰り返さない。
　実施の形態１．
　［通信システムの構成］
　図１は、本実施の形態の通信システム５００の構成例および処理の流れを示す図である。図１の例では、第１サーバ１００と、第２サーバ２００と、クライアント装置３００とを備える。第１サーバ１００が、本開示の「第１装置」に対応し、第２サーバ２００が、本開示の「第２装置」に対応し、クライアント装置３００が、本開示の「第３装置」に対応する。クライアント装置３００は、ユーザが操作可能な装置であり、たとえば、ＰＣ（Personal Computer）、タブレット端末、およびスマートフォンなどである。第１サーバ１００は、共通鍵１５０を保持している。また、第２サーバ２００は、共通鍵１５０を保持している。ここで、第１サーバ１００が有する共通鍵１５０と、第２サーバ２００が有する共通鍵１５０とは、同一の秘密鍵である。第１サーバ１００が有する共通鍵１５０は、本開示の「第１秘密鍵」に対応し、第２サーバ２００が有する共通鍵１５０は、本開示の「第２秘密鍵」に対応する。
　本実施の形態の通信システム５００は、シングルサインオン（ＳＳＯ：Single Sign On）を実現する。本実施の形態においては、当該シングルサインオンにより、ユーザデータの入力を含むログイン操作を第１サーバ１００に行い該第１サーバ１００へのグインが成功すれば、第２サーバ２００に対応するユーザデータを入力しなくても、第２サーバ２００へのログインが承認され得る。したがって、第２サーバ２００に対応するユーザデータのユーザによる入力を省略できる点で、ユーザの負担を軽減できる。
　以下に、図１を用いて処理の流れを説明する。クライアント装置３００は、ログイン画面（たとえば、後述の図９（Ａ）参照）を表示する。ユーザによりログイン画面に対してログイン操作が実行される。ログイン操作は、第１サーバ１００にログインするためでありかつユーザデータの入力を含む操作である。ユーザデータは、たとえば、ユーザ名（ユーザＩＤ（identification））およびパスワードである。ユーザデータは、本開示の「第１データ」に対応する。ステップ（１）において、クライアント装置３００は、入力されたユーザデータを第１サーバ１００に送信する。
　ステップ（２）において、第１サーバ１００は、クライアント装置３００から送信されたユーザデータに基づいて、ユーザ認証を実行する。ユーザ認証は、第１サーバ１００へのログインの成否を判断するための処理である。第１サーバ１００は、該ユーザ認証が成功した場合に、共通鍵１５０を用いてユーザデータからトークンを生成する。トークンの生成の手法については後述する。トークンは、本開示の「第２データ」に対応する。
　ステップ（３）において、第１サーバ１００は、生成したトークンをクライアント装置３００に送信する。ステップ（４）において、クライアント装置３００は、第２サーバ２００へのログインのためのユーザデータが入力されることなく、トークンを第２サーバ２００に送信する。
　また、ステップ（４）において生成したトークンを第２サーバ２００に送信するために、第２サーバ２００のアドレス（第２サーバ情報）を、クライアント装置３００に記憶させる手法として、たとえば、以下の第１の手法または第２の手法が採用される。まず、第１の手法を説明する。後述の図７に示すように、クライアント装置３００が共通鍵を作成する。クライアント装置３００による共通鍵の作成の段階で、図示しない管理装置等により、クライアント装置３００に第２サーバ２００のアドレスを記憶させる。また、第２の手法として、ステップ（３）において、第１サーバ１００は、トークンとともに、第２サーバ２００のアドレスを送信するようにしてもよい。クライアント装置３００は、該送信された第２サーバ２００のアドレスを記憶する。
　ステップ（５）において、第２サーバ２００は、共通鍵１５０を用いてトークンを検証する。トークンの検証の手法については後述する。第２サーバ２００は、トークンの検証により、第２サーバ２００へのログインの承認の可否を判断する。第２サーバ２００は、トークンの検証により該トークンが正当であれば、クライアント装置３００による第２サーバ２００へのログインを承認する。一方、第２サーバ２００は、トークンの検証により該トークンが不当であれば、クライアント装置３００による第２サーバ２００へのログインの承認を禁止する。
　第１サーバ１００へのログインが成功した場合において、クライアント装置３００は、リクエスト信号を第１サーバ１００に送信すると、第１サーバ１００は該リクエスト信号に応じたデータ（サービス）をクライアント装置３００に送信する。また、第２サーバ２００へのログインが成功した場合において、クライアント装置３００は、リクエスト信号を第２サーバ２００に送信すると、第２サーバ２００は該リクエスト信号に応じたデータ（サービス）をクライアント装置３００に送信する。
　また、図１の通信システム５００であれば、図１の個所αに示すように、第１サーバ１００と第２サーバ２００との通信を不要とする。したがって、通信システム５００は、通信システム５００の構成を簡素化しつつ好適にシングルサインオン（サーバへのログイン）を実現することができる。
　［ハードウェア構成］
　図２は、クライアント装置３００のハードウェア構成を示す図である。図２を参照して、クライアント装置３００は、プログラムを実行するＣＰＵ（Central Processing Unit）３８１と、データを不揮発的に格納するＲＯＭ（Read Only Memory）３８２とデータを揮発的に格納するＲＡＭ（Random Access Memory）３８３と、表示装置３８５と、入力装置３８６と、通信Ｉ／Ｆ（Interface）３８８とを備える。表示装置３８５は、本開示の「ディスプレイ」に対応する。
　クライアント装置３００の通信Ｉ／Ｆ３８８は、ネットワーク６７０を介して、第１サーバ１００および第２サーバ２００と通信可能である。クライアント装置３００における処理は、各ハードウェアおよびＣＰＵ３８１により実行されるプログラムによって実現される。このようなプログラムは、ＲＯＭ３８２などに予め記憶されている場合がある。ＣＰＵ３８１は、ＲＯＭ３８２からプログラムを読み取る。
　入力装置３８６は、たとえばキーボードあるいはマウスなどのポインティングデバイスであり、ユーザからの指令（たとえば、ユーザデータの入力）を受け付ける。表示装置３８５は、たとえば液晶（ＬＣＤ：Liquid Crystal Display）パネルで構成され、ユーザに画面（たとえば、ログイン画面）を表示する。ユーザインターフェースとしてタッチパネルが用いられる場合には、表示装置３８５と入力装置３８６とが一体的に形成される。
　第１サーバ１００は、プログラムを実行するＣＰＵ１８１と、データを不揮発的に格納するＲＯＭ１８２と、データを揮発的に格納するＲＡＭ１８３と、通信Ｉ／Ｆ１８８などを備える。
　第１サーバ１００の通信Ｉ／Ｆ１８８は、ネットワーク６７０を介して、クライアント装置３００と通信可能である。一方、図１の個所αでも示したように、第１サーバ１００と第２サーバ２００とは通信しない構成となっている。また、第１サーバ１００は、共通鍵１５０と、後述のユーザテーブル６５０とを保持している。図２の例では、共通鍵１５０と、ユーザテーブル６５０とは、ＲＯＭ１８２に格納されている。
　第２サーバ２００は、プログラムを実行するＣＰＵ２８１と、データを不揮発的に格納するＲＯＭ２８２と、データを揮発的に格納するＲＡＭ２８３と、通信Ｉ／Ｆ２８８などを備える。
　第２サーバ２００の通信Ｉ／Ｆ２８８は、ネットワーク６７０を介して、クライアント装置３００と通信可能である。一方、図１の個所αでも示したように、第２サーバ２００は、第１サーバ１００と通信しない構成となっている。また、第２サーバ２００は、共通鍵１５０と、ユーザテーブル６５０とを保持している。図２の例では、共通鍵１５０と、後述のユーザテーブル６５０とは、ＲＯＭ２８２に格納されている。
　クライアント装置３００と、第１サーバ１００と、第２サーバ２００とにおいて、ＣＰＵと、ＲＯＭと、ＲＡＭなどにより「プロセッサ」が構成される。プロセッサは、「制御回路」とも称される。
　［ユーザテーブル］
　図３はユーザテーブル６５０の一例である。ユーザテーブル６５０は、正当な複数のユーザのそれぞれのユーザデータと、ＩＤとが対応付けて規定されているテーブルである。ユーザデータは、ユーザ名と、パスワードとにより構成される。図３の例では、ユーザ名Ａ１と、パスワードＰ１とが１つのユーザデータとして格納されており、該ユーザデータにＩＤとしてＱ１が対応付けられている。また、ユーザ名Ａ２と、パスワードＰ２とが１つのユーザデータとして格納されており、該ユーザデータにＩＤとしてＱ２が対応付けられている。
　ユーザデータは、ユーザにより決定される。また、ＩＤは、該ユーザデータに基づいて図示しない管理装置などにより作成される。管理装置は、通信システム５００に対する権限を有する管理者により操作される装置である。管理装置がユーザを新規登録する場合には、クライアント装置３００から、登録要請およびユーザデータを当該管理装置に送信する。当該管理装置は、登録要請およびユーザデータを受信すると、乱数などを用いてＩＤを生成する。そして、管理装置は、該ユーザデータおよびＩＤを第１サーバ１００および第２サーバ２００に送信する。第１サーバ１００および第２サーバ２００は、該ユーザ名およびパスワードをユーザテーブル６５０に追加させる。また、第１サーバ１００が有するユーザテーブル６５０と、第２サーバ２００が有するユーザテーブル６５０とは同一である。
　［機能ブロック図］
　図４は、第１サーバ１００および第２サーバ２００などの機能ブロック図である。図４の通信システム５００においては、トークンが用いられるが、本実施の形態のトークンは、ＪＫＴ（JSON Web Token）に基づいたトークンであるとする。なお、トークンは他のトークンとしてもよい。
　第１サーバ１００は、通信部１０２と、認証部１０４と、生成部１０６と、記憶部１０８とを有する。記憶部１０８には、ユーザテーブル６５０（図３参照）と、共通鍵１５０とが格納されている。通信部１０２は、通信Ｉ／Ｆ１８８などに対応する。認証部１０４と、生成部１０６とは、ＣＰＵ１８１などに対応する。記憶部１０８は、ＲＯＭ１８２などに対応する。
　第２サーバ２００は、通信部２０２と、検証部２０４と、記憶部２０８とを有する。記憶部２０８には、ユーザテーブル６５０（図３参照）と、共通鍵１５０とが格納されている。通信部２０２は、通信Ｉ／Ｆ２８８などに対応する。検証部２０４は、ＣＰＵ２８１などに対応する。記憶部２０８は、ＲＯＭ２８２などに対応する。
　クライアント装置３００の表示装置３８５が第１サーバ１００へのログイン画面を表示し、ユーザが該ログイン画面に対してユーザデータを入力する。クライアント装置３００は、該ユーザデータを第１サーバ１００に送信する（図１のステップ（１）参照））。
　通信部１０２が、ユーザデータを取得すると、該ユーザデータは、認証部１０４に出力される。認証部１０４は、ユーザテーブル６５０（図３参照）を参照して、ユーザデータに基づいてユーザ認証を実行する。具体的には、認証部１０４は、ユーザデータ（ユーザ名およびパスワードの組合せ）が、ユーザテーブル６５０に存在するか否かを判断する。
　ユーザデータがユーザテーブルに存在している場合には、認証部１０４は、ユーザ認証が成功したと判断する。そして、認証部１０４は、ユーザテーブル６５０を参照して該ユーザデータに対応するＩＤを抽出し、該ＩＤを生成部１０６に出力する。一方、ユーザデータがユーザテーブルに存在していない場合には、認証部１０４は、ユーザ認証が失敗したと判断する。なお、第１サーバ１００は、ユーザ認証が失敗したことを示す信号をクライアント装置３００に送信する。
　生成部１０６は、共通鍵１５０およびユーザデータに基づいてトークンを生成する。以下に、トークンの生成の手法の一例を説明する。本実施の形態においては、生成部１０６は、ユーザデータに対応するＩＤと、共通鍵１５０とを用いて、第１トークンデータおよび第２トークンデータを生成する。そして、生成部１０６は、第１トークンデータおよび第２トークンデータを結合することにより、トークンを生成する。
　たとえば、生成部１０６は、ＩＤに対して第１演算を実行することにより「署名無しトークン」を作成する。この署名無しデータが、第１トークンデータに対応する。そして、生成部１０６は、署名無しトークン（第１トークンデータ）に対して共通鍵１５０を適用することにより（たとえば、署名無しトークンを暗号化することにより）、「署名」を生成する。この署名が、第２トークンデータに対応する。そして、生成部１０６は、第１トークンデータ（署名無しトークン）と、第２トークンデータ（署名）とを結合することにより、トークンを生成する。また、当該トークンは、有効期限が設定される。また、トークンの生成には、他の情報（たとえば、ハッシュ）などが用いられてもよい。
　生成部１０６は、トークンを生成すると、通信部１０２を介して、クライアント装置３００に該トークンを送信する。また、ユーザにより第２サーバへのログインする旨を操作が実行された場合には、該トークンを第２サーバ２００に送信する。
　通信部２０２が、トークンを取得すると、該トークンは、検証部２０４に出力される。検証部２０４は、記憶部２０８に記憶されているユーザテーブル６５０（図３参照）および公開鍵（第２秘密鍵）に基づいて、トークンを検証する。以下に、トークンの検証の手法の一例を説明する。
　まず、検証部２０４は、トークンを第１トークンデータ（署名無しトークン）と、第２トークンデータ（署名）とに分割する。そして、検証部２０４は、署名無しトークンに対して共通鍵１５０を適用することにより（たとえば、署名無しトークンを暗号化することにより）、「仮署名」（「第３トークンデータ」とも称される。）を生成する。そして、検証部２０４は、第２トークンデータ（署名）と、第３トークンデータ（仮署名）とを比較する。
　第２トークンデータと、第３トークンデータとが一致すれば、検証部２０４は、署名無しトークンに対して、第２演算を実行することによりＩＤを抽出する。第２演算は、上述の第１演算とは逆の演算である。そして、検証部２０４は、このＩＤが、記憶部２０８内のユーザテーブル６５０に存在すると判断した場合には、トークンは正当であると判断する。トークンが正当である場合には、第２サーバ２００は、第２サーバ２００へのログインを承認する。一方、第２トークンデータと、第３トークンデータとが異なれば、検証部２０４は、トークンは不当であると判断する。また、上述の第２演算を実行することにより抽出したＩＤが、記憶部２０８内のユーザテーブル６５０に存在しない場合にも、検証部２０４は、トークンは不当であると判断する。トークンが不当である場合には、第２サーバ２００は、第２サーバへのログインを禁止する。
　検証部２０４は、検証結果（第２サーバ２００へのログインの可否を示す情報）を通信部２０２を介して、クライアント装置３００に該検証結果を送信する。クライアント装置３００は、検証結果（第２サーバ２００へのログインの可否）をユーザに通知する。
　なお、変形例として、第２トークンデータと、第３トークンデータとが一致すれば、検証部２０４は、トークンは正当であると判断する構成が採用されてもよい。このような構成が採用された場合において、第２トークンデータと、第３トークンデータとが異なれば、検証部２０４は、トークンは不当であると判断する。また、このような構成においては、記憶部２０８内のユーザテーブル６５０は不要となる。
　第２トークンデータ（署名）と、第３トークンデータ（仮署名）との比較を検証部２０４が実行することにより、通信システム５００のセキュリティ性を高めることができる。なお、変形例として、検証部２０４は、該比較を実行しないようにしてもよい。
　［比較例との対比］
　図５は、比較例の通信システム５００Ｌの一例を示す図である。通信システム５００Ｌにおいても、シングルサインオンは実現される。比較例の通信システム５００Ｌにおいては、第２サーバ２００Ｌは秘密鍵を有しておらず、かつ第１サーバ１００Ｌと第２サーバ２００Ｌとが通信するように構成されている。比較例の通信システム５００Ｌの方式は、「エージェント方式」とも称される。
　ステップ（１）において、クライアント装置３００Ｌは、ユーザデータを送信する。第１サーバ１００Ｌは、ユーザデータおよび秘密鍵１５０Ｌに基づいて、トークンを生成する。ステップ（３）において、第１サーバ１００は、クライアント装置３００にトークンを送信する。ステップ（４）において、クライアント装置３００は、トークンを第２サーバに送信する。
　次に、ステップ（５１）において、第２サーバ２００Ｌは、第１サーバ１００Ｌに対して、トークンの検証を要求する。第１サーバ１００Ｌが、秘密鍵１５０Ｌを用いて、トークンを検証し、ステップ（５２）において検証結果を第２サーバ２００Ｌに送信する。そして、ステップ（６）において、第２サーバ２００Ｌは、検証結果をクライアント装置３００に送信する。
　比較例の通信システム５００Ｌにおいては、ステップ（５１）およびステップ（５２）で説明したように、第１サーバ１００Ｌと第２サーバ２００Ｌとの通信機能（通信経路）が必要となる。しかしながら、この通信機能が必要となる場合には、通信システム５００Ｌの構成が複雑になる。たとえば、通信システム５００Ｌを構築する設計者の熟練度が低い場合などには、該設計者の負担が増大する場合がある。
　これに対し、本実施の形態の通信システム５００においては、第１サーバ１００および第２サーバ２００は同一の共通鍵１５０を保持する。そして、第１サーバ１００は、第１サーバ１００の共通鍵１５０を用いてトークンを生成し、第２サーバ２００は、第２サーバ２００の共通鍵１５０を用いて該トークンを検証する。したがって、本実施の形態の通信システム５００は、第１サーバ１００と第２サーバ２００との通信機能を必要とすることなく（図１の個所α参照）、トークンの生成および検証を実行できる。したがって、本実施の形態の通信システム５００は、通信システム５００の構成を簡素化できる点で好適にシングルサインオン（サーバへのログイン）を実現させることができる。
　［フローチャート］
　図６は、クライアント装置３００、第１サーバ１００、および第２サーバ２００により実行される処理の流れを示すフローチャートである。
　まず、ステップＳ１において、クライアント装置３００は、表示装置３８５にログイン画面を表示する。次に、ステップＳ２において、クライアント装置３００は、第１サーバ１００へのユーザによるログイン操作が実行されたか否かを判断する。次に、ステップＳ４において、このログイン操作によりユーザが入力したユーザデータを、クライアント装置３００は、第１サーバ１００に送信する（図１のステップ（１）参照）。
　第１サーバ１００は、ユーザテーブル６５０（図３参照）を参照して、ユーザデータに基づいてユーザ認証を実行する。ステップＳ６において、第１サーバ１００は、該ユーザ認証が成功したか否かを判断する。ユーザ認証が成功した場合には（ステップＳ６でＹＥＳ）、処理は、ステップＳ８に進む。一方、ユーザ認証が失敗した場合には（ステップＳ６でＮＯ）、図６の処理は終了する。
　ステップＳ８において、第１サーバ１００は、トークンを生成する（図１のステップ（２）参照）。そして、ステップＳ１０において、第１サーバ１００は、クライアント装置３００にトークンを送信する（図１のステップ（３）参照）。
　ステップＳ１２において、クライアント装置３００は、ユーザにより第２サーバ２００へのログイン操作が実行されたか否かを判断する。ステップＳ１２においては、クライアント装置３００は、ユーザにより第２サーバ２００へのログイン操作が実行されるまで待機する（ステップＳ１２でＮＯ）。そして、ユーザにより第２サーバ２００へのログイン操作が実行された場合には（ステップＳ１２でＹＥＳ）、ステップＳ１４において、クライアント装置３００は、ステップＳ１０で送信されたトークンを第２サーバ２００に送信する（図１のステップ（４）参照）。
　ステップＳ１６において、第２サーバ２００は、該トークンを検証する（図１のステップ（５）参照）。そして、ステップＳ１８において、第２サーバ２００は、検証結果を送信する（図１のステップ（６）参照）。
　また、通信システム５００は、以下の第１の構成または第２の構成が採用される。第１の構成は、第１サーバ１００および第２サーバ２００の双方のログインが成功した場合のみ、第１サーバ１００のサービスおよび第２サーバ２００のサービスを提供する。また、第１の構成は、第１サーバ１００のログインが成功したが第２サーバ２００のログインが失敗した場合には、第１サーバ１００のサービスおよび第２サーバ２００のサービスのいずれも提供しない。
　また、第２の構成は、第１サーバ１００のログインが成功した場合には、第２サーバ２００のログインが成功したか否かに関わらず、第１サーバ１００は、第１サーバ１００のサービスを提供する。また、第２の構成においては、第２サーバ２００のログインが成功した場合には、第２サーバ２００は第２サーバ２００のサービスを提供し、第２サーバ２００のログインが失敗した場合には、第２サーバ２００は第２サーバ２００のサービスを提供ない。
　［共通鍵の登録］
　次に、共通鍵１５０の第１サーバ１００および第２サーバ２００への登録の手法の一例を説明する。本実施の形態においては、共通鍵１５０は、第１サーバ１００および第２サーバ２００のいずれとも異なる装置により作成される。共通鍵１５０を作成する装置は、本開示の「作成装置」に対応する。
　図７は、共通鍵１５０の登録の手法を説明するための図である。図７では、作成装置がクライアント装置３００である例が開示されている。なお、共通鍵１５０を作成するクライアント装置３００は、図１で示したクライアント装置３００と同一であってもよく、異なっていてもよい。また、図７のクライアント装置３００は、共通鍵１５０を作成する作成部３０２を有する。
　また、共通鍵１５０の作成については、たとえば、通信システム５００の管理者などにより行われる。通信システム５００の管理者が、クライアント装置３００に対してログイン操作を実行する。このログイン操作は、共通鍵１５０を作成するためでありかつ管理者データのクライアント装置３００への入力を含む操作である。管理者データは、たとえば、管理者名（管理者ＩＤ）およびパスワードである。管理者データは、本開示の「第３データ」に対応する。
　ステップ（２１）において、クライアント装置３００は、管理者により入力された管理者データを第１サーバ１００および第２サーバ２００に送信する。ステップ（２２）において、第１サーバ１００および第２サーバ２００は、管理者データに基づいて管理者認証を実行する。管理者認証は、たとえば、第１サーバ１００および第２サーバ２００は、１以上の正当な管理者データが規定されている管理者テーブルを保持しており、クライアント装置３００から送信された管理者データが、該管理者テーブルに規定されているか否かを判断することにより実行される。管理者データが管理者テーブルに規定されている場合には、管理者認証は成功であり、管理者データが管理者テーブルに規定されていない場合には、管理者認証は失敗である。
　ステップ（２３）において、第１サーバ１００および第２サーバ２００は認証結果を送信する。第１サーバ１００による管理者認証および第２サーバ２００による管理者認証の双方が成功した場合に、クライアント装置３００の作成部３０２は共通鍵１５０を作成する。作成部３０２は、たとえば、乱数により共通鍵１５０を作成する。また、第１サーバ１００による管理者認証および第２サーバ２００による管理者認証の少なくとも一方が失敗した場合には、作成部３０２による共通鍵１５０の作成は禁止される。
　作成部３０２が、共通鍵１５０を作成すると、該共通鍵１５０を第１サーバ１００および第２サーバ２００に送信する。第１サーバ１００は、共通鍵１５０をＲＯＭ１８２に格納（登録）するとともに、第２サーバ２００は、共通鍵１５０をＲＯＭ２８２に格納（登録）する。
　たとえば、第１サーバ１００が共通鍵１５０を作成し、該共通鍵１５０を第２サーバ２００に送信する構成が考えられる。しかしながら、このような構成においては、第１サーバ１００と第２サーバ２００との通信機能が必要となる。
　これに対し、図７の構成であれば、第１装置および第２装置とは異なる作成装置（クライアント装置３００）が共通鍵１５０を作成し、第１サーバ１００および第２サーバ２００に送信する。したがって、図７の通信システム５００によれば、第１サーバ１００と第２サーバ２００との通信機能を必要とすることなく、共通鍵１５０を適切に作成できる。
　また、図７の通信システム５００によれば、クライアント装置３００は、第１サーバ１００による管理者認証および第２サーバ２００による管理者認証の双方が成功した場合に共通鍵１５０を作成する。したがって、第１サーバ１００による管理者認証および第２サーバ２００による管理者認証のいずれか一方が成功した場合に共通鍵１５０を作成する構成と比較して、共通鍵１５０の安全性を高めることができる。
　なお、共通鍵１５０の作成については、クライアント装置３００が、たとえば、システムコントローラのような据付リモートコントローラの場合は、該据付の際に事前に行われる。
　実施の形態２．
　実施の形態２においては、実施の形態１で説明した通信システム５００が空調機の管理に適用される通信システムが説明される。図８は、実施の形態２の通信システム７００の構成例を説明するための図である。
　図８の例では、第１サーバ１００と、少なくとも１つの第１空調機４０１とが対応付けられている。典型的には、第１サーバ１００は、少なくとも１つの第１空調機４０１の各々と接続されている。そして、第１サーバ１００は、少なくとも１つの第１空調機４０１を管理（制御）する。
　また、第２サーバ２００と、少なくとも１つの第２空調機４０２とが対応付けられている。典型的には、第２サーバ２００は、少なくとも１つの第２空調機４０２の各々と接続されている。そして、第２サーバ２００は、少なくとも１つの第２空調機４０２を管理（制御）する。たとえば、第１空調機４０１は、第１施設（第１建物）に設置され、第２空調機４０２は、第１施設とは異なる第２施設（第２建物）に設置される。
　図８の例では、少なくとも１つの第１空調機４０１は第１空調機群４０１Ａを構成する。また、少なくとも１つの第２空調機４０２は第２空調機群４０２Ａを構成する。
　第１サーバ１００へのログインが成功した場合には、第１空調機群４０１Ａのサービスをクライアント装置３００に送信する。「第１空調機群４０１Ａのサービス」とは、第１空調機群４０１Ａの管理画面の表示である。また、第２サーバ２００へのログインが成功した場合には、第２空調機群４０２Ａのサービスをクライアント装置３００に送信する。「第２空調機群４０２Ａ」とは、第２空調機群４０２Ａの管理画面の表示である。ここで、管理画面とは、空調機を制御するための画面であり、空調機の設定値などを表示する画面である。また、管理画面は、該設定値のユーザによる変更を受付ける画面であってもよい。
　図９は、本実施の形態の表示装置３８５が表示する画面の遷移の一例を示す図である。図９（Ａ）は、第１サーバ１００へのログイン画面の一例を示す図である。このログイン画面においては、入力領域３９２が表示される。ユーザは、該入力領域３９２にユーザデータを入力する。図９（Ａ）の例では、入力領域３９２は、ユーザ名の入力領域と、パスワードの入力領域とを含む。
　そして、該入力領域３９２に入力されたユーザデータによる、第１サーバ１００のユーザ認証が成功した場合には（図６のステップＳ６でＹＥＳ）、第１サーバ１００は、第１空調機群４０１Ａ（図８参照）の管理画面を表示装置３８５に表示させる。また、第１空調機群４０１Ａの管理画面は、「第１管理画面」とも称される。
　図９（Ｂ）は、第１管理画面の一例である。図９（Ｂ）の第１管理画面では、第１空調機群４０１Ａを構成する少なくとも１つの第１空調機（第１空調機Ａ～第１空調機Ｎ）の設定値画像３９３が表示されている。設定値画像３９３は、第１空調機群４０１Ａを構成する第１空調機のそれぞれの設定値を示す画像である。図９（Ｂ）の例では、設定値画像３９３として、第１空調機Ａ～第１空調機Ｎの設定温度が表示されている。また、設定値画像３９３として、たとえば、他の設定値（たとえば、風量など）が表示されてもよい。
　また、図９（Ｂ）の第１管理画面においては、ログインボタン３９４が表示される。ログインボタン３９４は、第２サーバ２００へのログイン操作（図６のステップＳ１２参照）を行うためのボタンである。ログインボタン３９４が操作された場合には、クライアント装置３００は、トークンを送信する（図１のステップ（４）、および図６のステップＳ１４参照）。そして、トークンの検証により、トークンが正当である場合には、第２サーバ２００は、第２空調機群４０２Ａ（図８参照）の管理画面を表示装置３８５に表示させる。また、第２空調機群４０２Ａの管理画面は、「第２管理画面」とも称される。
　図９（Ｃ）は、第２管理画面の一例である。図９（Ｃ）の第２管理画面では、第２空調機群４０２Ａを構成する少なくとも１つの第２空調機（第２空調機Ａ～第２空調機Ｍ）の設定値画像３９５が表示されている。設定値画像３９５は、第２空調機群４０２Ａを構成する第２空調機のそれぞれの設定値を示す画像である。図９（Ｃ）の例では、設定値画像３９５として、第２空調機Ａ～第２空調機Ｍの設定温度が表示されている。
　また、図９（Ｃ）の第２管理画面においては、切換ボタン３９６が表示される。切換ボタン３９６は、第１管理画面に切換えるためのボタンである。ユーザにより切換ボタン３９６が操作された場合には、クライアント装置３００は、第２管理画面から、第１管理画面に表示を切換える。なお、第２サーバ２００のログインが成功した場合には、第２管理画面に切換えるための切換ボタンが、第１管理画面にされてもよい。
　以上のような構成によれば、第１サーバ１００と第２サーバ２００との通信機能を必要とすることなく、第１管理画面および第２管理画面をクライアント装置３００の表示装置３８５に表示できる。したがって、通信システム７００の構成を簡素化しつつ、ユーザに第１空調機４０１および第２空調機４０２を管理させることができる。
　また、図９の最下部に記載されているように、通信システム７００は、第２サーバ２００のログイン画面を表示せずに、つまり、第２サーバ２００へのログインのためのユーザデータを入力させることなく、第２管理画面を表示する。したがって、適切にシングルサインオンを実現できることから、ユーザの負担を軽減できる。
　また、図６において、ステップＳ１２の処理は省略される構成が採用されてもよい。このような構成が採用された場合には、クライアント装置３００は、ステップＳ６で送信されたトークンをステップＳ１４で第２サーバ２００に送信する。つまり、第１サーバ１００へのログイン操作が実行されたときには、自動的に、第１サーバ１００へのログインの成否および第２サーバ２００へのログインの成否が判断される。また、通信システム７００において、ステップＳ１２の処理が省略された構成が採用された場合には、ログインボタン３９４は表示されない。
　なお、実施の形態１および実施の形態２の通信システムは、２つのサーバ（第１サーバ１００および第２サーバ２００）を備える構成が説明された。しかしながら、通信システムは、３以上のサーバを備える構成であってもよい。
　実施の形態３．
　上述の実施の形態においては、クライアント装置３００と、第１サーバ１００と、第２サーバ２００とを備える通信システムが説明された。実施の形態３の通信システム５００Ａは、１つのサーバ（第１サーバ１００）と、クライアント装置３００とを備える。
　図１０は、実施の形態３の通信システム５００Ａの構成例を示す図である。図１０の例では、ステップ（１）～（３）の処理が終了した後において、再び、クライアント装置３００から第１サーバ１００へのログイン操作が実行されると、ステップ（３）で送信されたトークンを、第１サーバ１００に送信する（ステップ（４Ａ））。また、このログイン操作においては、ユーザデータを入力する操作を含まない。
　次に、ステップ（４Ａ）で送信されたトークンを、第１サーバ１００は、検証する（ステップ（５Ａ））。トークンの検証により該トークンが正当であれば、クライアント装置３００による第１サーバ１００へのログインを継続する。一方、第２サーバ２００は、トークンの検証により該トークンが不当であれば、クライアント装置３００による第１サーバ１００へのログインを終了させる。第１サーバ１００は、検証結果をクライアント装置３００に送信する（ステップ（６Ａ））。
　図１１は、実施の形態３のクライアント装置３００、および第１サーバ１００により実行される処理の流れを示すフローチャートである。ステップＳ１４Ａにおいて、クライアント装置３００は、トークンを第１サーバ１００に送信する。また、図１１のステップＳ６において、ユーザ認証が成功していることから、本実施の形態においては、ステップＳ１４Ａにおいて、データ要求信号を第１サーバ１００に送信する。データ要求信号とは、第１サーバ１００にデータを要求するための信号である。データは、たとえば、空調機の管理画面（図９参照）のデータである。
　ステップＳ１６Ａにおいて、第１サーバ１００は、該トークンを検証する。そして、ステップＳ１８Ａにおいて、第１サーバ１００は、検証結果を送信する。なお、ステップＳ１６Ａにおいてトークンの検証により該トークンが不当であれば、ステップＳ１４Ａで送信されたデータ要求信号で要求されているデータは、クライアント装置３００に送信されない。
　このような構成によれば、第１サーバ１００へのログインが成功した場合において、トークンの有効期限内においては、ユーザは、ユーザデータを入力しなくても、第１サーバ１００にログインできる。したがって、ユーザの利便性を向上させる点で、好適にサーバへ（第１サーバ１００）のログインを実現させることができる。なお、実施の形態３の思想は、実施の形態１および実施の形態２に適用されてもよい。
　今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本開示の範囲は上記した説明ではなくて請求の範囲によって示され、請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
　１００　第１サーバ、１０２，２０２　通信部、１０４　認証部、１０６　生成部、１０８，２０８　記憶部、１５０　共通鍵、２００　第２サーバ、２０４　検証部、３００　クライアント装置、３０２　作成部、３８５　表示装置、３８６　入力装置、３９２　入力領域、３９３，３９５　設定値画像、３９４　ログインボタン、３９６　切換ボタン、４０１　第１空調機、４０１Ａ　第１空調機群、４０２　第２空調機、４０２Ａ　第２空調機群、５００，７００　通信システム、６５０　ユーザテーブル、６７０　ネットワーク。

Claims (9)

  1. 　第１装置と、第２装置と、第３装置とを備える通信システムであって、
    　前記第１装置は、第１秘密鍵を記憶する第１メモリを有し、
    　前記第２装置は、前記第１秘密鍵と同一の第２秘密鍵を記憶する第２メモリを有し、
    　前記第３装置は、前記第１装置にログインするためでありかつ第１データの入力を含む操作がユーザにより実行されたときに該第１データを前記第１装置に送信し、
    　前記第１装置は、
    　　前記第１データに基づいて前記第１装置へのログインの成否を判断し、
    　　前記第１装置へのログインが成功した場合に前記第１秘密鍵および前記第１データに基づいて第２データを生成し、
    　　前記第２データを前記第３装置に送信し、
    　前記第３装置は、前記第１データが入力されることなく前記第２データを前記第２装置に送信し、
    　前記第２装置は、前記第２秘密鍵を用いて前記第２データを検証し該第２データが正当であれば前記第２装置へのログインを承認する、通信システム。
  2. 　前記第１秘密鍵および前記第２秘密鍵は、前記第１装置および前記第２装置とは異なる作成装置により作成され、
    　前記作成装置は、前記第１秘密鍵を前記第１装置に送信し、前記第２秘密鍵を前記第２装置に送信する、請求項１に記載の通信システム。
  3. 　前記作成装置は、前記第３装置であり、
    　前記第１秘密鍵および前記第２秘密鍵を作成するためでありかつ第３データの入力を含む操作が管理者により実行されたときに該第３データを前記第１装置および前記第２装置に送信し、
    　前記第１装置および前記第２装置は、前記第３データに基づいて管理者認証を実行し、
    　前記第３装置は、前記第１装置および前記第２装置による管理者認証が成功した場合に前記第１秘密鍵および前記第２秘密鍵を作成する、請求項２に記載の通信システム。
  4. 　前記通信システムは、さらに、
    　前記第１装置により管理される第１空調機と、
    　前記第２装置により管理される第２空調機とを備え、
    　前記第３装置は、
    　　前記第１装置へのログインが承認された場合に前記第１空調機の管理画面をディスプレイに表示し、
    　　前記第２装置へのログインが承認された場合に前記第２空調機の管理画面を前記ディスプレイに表示する、請求項１～請求項３のいずれか１項に記載の通信システム。
  5. 　前記第３装置は、
    　　前記第１装置にログインするための画面でありかつ前記第１データの入力を受付けるログイン画面を前記ディスプレイに表示し、
    　　前記ログイン画面により受付けた前記第１データを前記第１装置に送信し、
    　　前記第２装置にログインするための画面でありかつ前記第１データの入力を受付けるログイン画面を表示せずに前記第２データを前記第２装置に送信する、請求項４に記載の通信システム。
  6. 　第１装置と、第２装置とを備える通信システムであって、
    　前記第１装置は、秘密鍵を記憶するメモリを有し、
    　前記第２装置は、第１データの入力を含みかつ前記第１装置へのログイン操作がユーザにより実行されたときに該第１データを前記第１装置に送信し、
    　前記第１装置は、
    　　前記第１データに基づいてユーザ認証を実行し、
    　　前記ユーザ認証が成功した場合に前記秘密鍵を用いて前記第１データから第２データを生成し、
    　　前記第２データを前記第２装置に送信し、
    　前記第２装置は、前記第１データが入力されることなく前記第２データを前記第１装置に送信し、
    　前記第１装置は、前記秘密鍵を用いて前記第２データを検証し該第２データが正当であれば前記第１装置へのログインを承認する、通信システム。
  7. 　サーバであって、
    　クライアント装置と通信するインタフェースと、
    　秘密鍵を記憶するメモリと、
    　プロセッサとを備え、
    　前記プロセッサは、
    　　第１データの入力を含みかつ前記サーバへのログイン操作がユーザにより前記クライアント装置に対して実行されたときに該クライアント装置から送信された前記第１データに基づいてユーザ認証を実行し、
    　　前記ユーザ認証が成功した場合に前記秘密鍵を用いて前記第１データから第２データを生成し、
    　　前記第２データを前記クライアント装置に送信し、
    　　前記第１データが入力されることなく前記クライアント装置から送信された前記第２データを、前記秘密鍵を用いて検証し該第２データが正当であれば前記サーバへのログインを承認する、サーバ。
  8. 　第１装置と、第２装置と、第３装置とにより実行される通信方法であって、
    　前記第３装置が、前記第１装置にログインするためでありかつ第１データの入力を含む操作がユーザにより実行されたときに該第１データを前記第１装置に送信することと、
    　前記第１装置が、前記第１データに基づいて前記第１装置へのログインの成否を判断することと、
    　前記第１装置が、前記第１装置へのログインが成功した場合に第１秘密鍵および前記第１データに基づいて第２データを生成することと、
    　前記第１装置が、前記第２データを前記第３装置に送信することと、
    　前記第３装置が、前記第１データが入力されることなく前記第２データを前記第２装置に送信することと、
    　前記第２装置が、前記第１秘密鍵と同一の第２秘密鍵を用いて前記第２データを検証し該第２データが正当であれば前記第２装置へのログインを承認することとを備える、通信方法。
  9. 　クライアント装置と通信するサーバにより実行される通信方法であって、
    　第１データの入力を含みかつ前記サーバへのログイン操作がユーザによりクライアント装置に対して実行されたときに該クライアント装置から送信された前記第１データに基づいてユーザ認証を実行することと、
    　前記ユーザ認証が成功した場合に秘密鍵を用いて前記第１データから第２データを生成することと、
    　前記第２データを前記クライアント装置に送信することと、
    　前記第１データが入力されることなく前記クライアント装置から送信された前記第２データを、前記秘密鍵を用いて検証し該第２データが正当であれば前記サーバへのログインを承認することとを備える、通信方法。
PCT/JP2022/041931 2022-11-10 2022-11-10 通信システム、サーバ、および通信方法 WO2024100843A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/041931 WO2024100843A1 (ja) 2022-11-10 2022-11-10 通信システム、サーバ、および通信方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/041931 WO2024100843A1 (ja) 2022-11-10 2022-11-10 通信システム、サーバ、および通信方法

Publications (1)

Publication Number Publication Date
WO2024100843A1 true WO2024100843A1 (ja) 2024-05-16

Family

ID=91032088

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/041931 WO2024100843A1 (ja) 2022-11-10 2022-11-10 通信システム、サーバ、および通信方法

Country Status (1)

Country Link
WO (1) WO2024100843A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014068632A1 (ja) * 2012-10-29 2014-05-08 三菱電機株式会社 設備管理装置、設備管理システム及びプログラム
JP2015226072A (ja) * 2014-05-26 2015-12-14 株式会社リコー 情報処理システム、情報処理方法、及びプログラム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014068632A1 (ja) * 2012-10-29 2014-05-08 三菱電機株式会社 設備管理装置、設備管理システム及びプログラム
JP2015226072A (ja) * 2014-05-26 2015-12-14 株式会社リコー 情報処理システム、情報処理方法、及びプログラム

Similar Documents

Publication Publication Date Title
US11431501B2 (en) Coordinating access authorization across multiple systems at different mutual trust levels
CN109428947B (zh) 权限转移系统及其控制方法和存储介质
KR102313859B1 (ko) 권한 위양 시스템, 그 제어 방법 및 클라이언트
EP3525415B1 (en) Information processing system and control method therefor
JP6061633B2 (ja) デバイス装置、制御方法、およびそのプログラム。
JP6141041B2 (ja) 情報処理装置及びプログラム、制御方法
US7366904B2 (en) Method for modifying validity of a certificate using biometric information in public key infrastructure-based authentication system
KR20180017734A (ko) 인증 시스템 및 방법과 이를 수행하기 위한 사용자 단말, 인증 서버 및 서비스 서버
US7581111B2 (en) System, method and apparatus for transparently granting access to a selected device using an automatically generated credential
JP2017027459A (ja) 権限委譲システム、その制御方法、認可サーバおよびプログラム
US20180205716A1 (en) Authentication systems and methods for online services
WO2017208305A1 (ja) サーバ装置、サービス方法、プログラム、ならびに、非一時的なコンピュータ読取可能な情報記録媒体
US20200403812A1 (en) Certificate issuing apparatus, verification apparatus, communication device, certificate issuing system, certificate issuing method, and non-transitory computer readable medium
EP3994593B1 (en) System, method, and computer program product for third-party authorization
JP2017220113A (ja) 認可サーバー、制御方法、およびプログラム。
JP6378424B1 (ja) 無欠性及び保安性が強化された使用者認証方法
WO2022103823A1 (en) Efficient transfer of authentication credentials between client devices
JP5036500B2 (ja) 属性証明書管理方法及び装置
WO2024100843A1 (ja) 通信システム、サーバ、および通信方法
US10873469B2 (en) Information processing apparatus and method for controlling information processing apparatus
JP2018022501A (ja) 複数のサービスシステムを制御するサーバシステム及び方法
KR101627896B1 (ko) 인증 어플리케이션을 이용한 인증 방법 및 장치
CN115208559A (zh) 用来对未连接设备中的用户进行认证的双因素认证
JP2019134333A (ja) 情報処理システム、クライアント装置、認証認可サーバー、制御方法とそのプログラム
JP7543154B2 (ja) 認証連携サーバ、認証連携方法、認証連携システムおよびプログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22965168

Country of ref document: EP

Kind code of ref document: A1