Identity authentication method and device, electronic equipment and storage medium

Abstract

The invention discloses an identity authentication method and device, electronic equipment and a storage medium, and relates to the computer technology, the method comprises the following steps: receiving a login request initiated by a client, the login request comprising a user identifier and a login key hash; performing first-level identity authentication on the login key hash and the corresponding registration key hash by calling an intelligent contract deployed on the block chain to obtain a first-level authentication result; wherein the smart contract is used for accessing the registration key hash in the database on the chain according to the user identifier; and under the condition that the first-level authentication result is that the authentication is passed, allowing the user to log in the springboard machine environment. According to the invention, the registration key hash is stored in the distributed nodes of the block chain, and the calling of the smart contract is cooperatively processed by a plurality of nodes in the block chain network; even if part of the nodes fail, other nodes can still normally respond to the authentication request, and the beneficial effect of improving the availability and fault tolerance of the authentication system is achieved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computers, and in particular to an identity authentication method and device, an electronic device, and a storage medium. BACKGROUND

[0002] A bastion host, also known as a bastion machine, is a core component in a network security system and is the only entrance for operation and maintenance personnel to access internal network resources. It effectively improves the security of internal network resources through centralized access control, identity authentication, operation audit, and other functions.

[0003] At present, the identity authentication module of a bastion host system generally relies on a traditional centralized authentication system. Common solutions include authentication based on a local database (such as checking the matching of a user account password and a locally stored password hash value through a Linux system pluggable authentication module (PAM)) and a distributed authentication mode based on a remote authentication service (such as an LDAP or RADIUS server). In these architectures, the bastion host acts as an authentication intermediary, forwards the credentials submitted by the user to the authentication server for verification, and determines whether to allow access based on the result returned by the server.

[0004] However, the above solutions are highly dependent on one or a small number of centralized authentication servers. Once the central authentication server stops serving due to hardware failure, downtime, or maintenance, or the network connection between the authentication server and the bastion host is interrupted, the identity authentication service of the entire bastion host system will immediately be paralyzed, and the system fault tolerance is poor. At this time, all legitimate users cannot complete the login authentication process, resulting in the interruption of their normal operation and maintenance access to internal resources, which seriously affects the continuity and stability of the business. SUMMARY

[0005] The present application provides an identity authentication method, device, electronic device, and storage medium, which can improve the existing identity authentication solution when logging into a bastion host environment.

[0006] In a first aspect, the present application provides an identity authentication method, which includes:

[0007] receiving a login request initiated by a client, the login request including a user identifier and a login key hash; performing first-level identity authentication on the login key hash and a corresponding registration key hash by calling a smart contract deployed on a blockchain, to obtain a first-level authentication result; wherein the smart contract is used to access a registration key hash in an on-chain database according to the user identifier; and allowing the user to log into a bastion host environment if the first-level authentication result is passed.

[0008] In a second aspect, the present application provides an identity authentication device, which includes:

[0009] request receiving module, configured to receive a login request initiated by a client, the login request comprising a user identifier and a login key hash;

[0010] identity authentication module, configured to perform first-level identity authentication on the login key hash and a corresponding registration key hash by invoking a smart contract deployed on a blockchain, to obtain a first-level authentication result; wherein the smart contract is configured to access the registration key hash in a database on the chain according to the user identifier;

[0011] user login module, configured to allow a user to log in to a jump plate machine environment if the first-level authentication result is passed.

[0012] In a third aspect, the present application further provides an electronic device, comprising:

[0013] at least one processor; and

[0014] a memory in communication with the at least one processor; wherein

[0015] the memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to perform the identity authentication method according to any one of the embodiments of the present application.

[0016] In a fourth aspect, the present application further provides a computer readable storage medium, which stores computer instructions for enabling a processor to perform the identity authentication method according to any one of the embodiments of the present application.

[0017] In a fifth aspect, the present application further provides a computer program product comprising a computer program, which, when executed by a processor, implements the identity authentication method according to any one of the embodiments of the present application.

[0018] The identity authentication scheme provided by the embodiments of the present application stores the registration key hash in the distributed nodes of the blockchain, and the invocation of the smart contract is processed by multiple nodes in the blockchain network. Even if some nodes fail (such as the central server is down), other nodes can still normally respond to the authentication request, improving the fault tolerance of identity authentication in the network interruption scenario. The problem of poor system fault tolerance in the prior art scheme which highly depends on one or a few centralized authentication servers is solved, and the availability and fault tolerance of the authentication system are improved.

[0019] It should be noted that the above computer instructions can be stored on the computer readable storage medium in whole or in part. The computer readable storage medium can be packaged together with the processor of the identity authentication apparatus, or can be packaged separately from the processor of the identity authentication apparatus, and the present application does not limit this.

[0020] The second aspect, the third aspect, the fourth aspect and the fifth aspect of the present application are described in detail in the first aspect, and the beneficial effects of the second aspect, the fourth aspect and the fifth aspect are analyzed in the first aspect, which will not be repeated here.

[0021] It should be understood that the contents described in this part are not intended to identify the key or important features of the embodiments of the present application, nor to limit the scope of the present application. Other features of the present application will become apparent from the following description. BRIEF DESCRIPTION OF DRAWINGS

[0022] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments. It should be understood that the following drawings only show some embodiments of the present application, and therefore should not be regarded as limiting the scope. For those skilled in the art, other related drawings can also be obtained without creative labor.

[0023] Figure 1 is a flowchart of the identity authentication method provided by the embodiments of the present application;

[0024] Figure 2 is another flowchart of the identity authentication method provided by the embodiments of the present application;

[0025] Figure 3 is a structural schematic diagram of the identity authentication apparatus provided by the embodiments of the present application;

[0026] Figure 4 is a structural schematic diagram of the electronic device provided by the embodiments of the present application. DETAILED DESCRIPTION

[0027] In order to make the person skilled in the art better understand the present application, the technical solutions in the present application will be described clearly and completely in the following with reference to the drawings in the embodiments. Obviously, the described embodiments are only a part of the embodiments of the present application, not all. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor should be within the scope of protection of the present application.

[0028] It should be noted that the terms "first", "second" and the like in the description and in the claims of the present application and above and below are used only for distinguishing between similar objects and not necessarily for describing a specific sequential or chronological order. It is to be understood that the use of data as described herein can be interchanged in order to carry out the embodiments of the present application as described herein. Furthermore, the terms "comprise", "comprising", "have", "having", "include", "including" and the like are intended to cover a non-exclusive inclusion such that processes, methods, articles, or apparatuses that comprise, have, include or the like a list of steps or elements are not necessarily limited to those steps or elements but can include other not expressly listed steps or elements.

[0029] The present application will be further described below in conjunction with the accompanying drawings and embodiments. It can be understood that the specific embodiments described herein are only used to explain the present application, but not to limit the present application. In addition, it should be noted that for the purpose of description, only the parts related to the present application are shown in the drawings, not all the structures.

[0030] Figure 1 A flowchart of an identity authentication method provided by an embodiment of the present application is shown. The embodiment can be applied to the case of user identity authentication when logging in to a jump machine. The method can be executed by an identity authentication device, which can be realized in the form of hardware and / or software and integrated in an electronic device for executing the method. Preferably, the electronic device in the embodiment of the present application can be a server, and can also be a computer device, etc.

[0031] Reference Figure 1 The identity authentication method provided by the embodiment includes but is not limited to the following steps:

[0032] S110, receiving a login request initiated by a client.

[0033] The client represents a terminal device or an application program used by a user to initiate a login operation. For example, a PC end operation and maintenance tool, a mobile phone application program or a browser, etc. is an interface for the user to interact with the system.

[0034] The login request represents an application instruction containing identity information sent by a user to an identity authentication system when the user wants to access a jump machine. In the embodiment, the login request includes a user identifier and a login key hash.

[0035] The user identifier represents a string uniquely identifying the identity of a user, such as a user name, a user identity identifier, a user mobile terminal number, a user email or a user account, etc. The type of specific user identifier is not limited herein.

[0036] Login key hash, which represents a fixed-length string generated by hashing the login key (such as password or private key) entered by the user. Hashing algorithm has one-way property, that is, the original key cannot be retrieved from the hash value to protect the security of the original key.

[0037] Generally, the way the client generates a login request can be that the user enters a user identifier and a login key on the client; the client locally processes the login key through a hashing algorithm (such as SHA-256) to generate a login key hash; the client packs the user identifier and the login key hash into structured data to generate a login request; further, the client can send the login request to the identity authentication system through an encrypted transmission protocol for identity authentication operation.

[0038] A preferred implementation, in the scheme provided in this embodiment, user registration needs to be performed on the client in advance before receiving the login request initiated by the client, so as to write the credentials into the blockchain for storage. The specific way can be:

[0039] Receiving a registration request initiated from the client, the registration request including a user identifier and a registration key; performing hash processing on the registration key to generate a registration key hash; sending the user identifier and the registration key hash to the smart contract to store the user identifier and the corresponding registration key hash in the on-chain database of the blockchain through the smart contract.

[0040] The user submits registration information through the client, the registration information including a user identifier and a registration key; the system applies a hash algorithm to the user's registration key to perform hash calculation to generate a corresponding registration key hash, and immediately discards the original password after the calculation is completed; the system calls a smart contract method named "user registration" through the software development kit (Software Development Kit, SDK) of the blockchain, and inputs the user identifier and the registration key hash as parameters; the smart contract executes the registration logic, writes the mapping relationship between the user identifier and the registration key hash as a record into the distributed ledger of the blockchain. This process generates a transaction, and after network consensus, the data is permanently stored.

[0041] S120, performing first-level identity authentication on the login key hash and the corresponding registration key hash by calling the smart contract deployed on the blockchain, to obtain a first-level authentication result.

[0042] Blockchain is a distributed ledger technology, data is stored in blocks, maintained by multiple nodes, has the characteristics of non-tamperability, decentralization, traceability. In this embodiment, the blockchain stores the user's registration information, and completes the user's identity authentication logic by running the smart contract.

[0043] A smart contract is an automated execution code deployed on a blockchain, which defines pre-agreed rules and logic, and the contract will be automatically executed when certain conditions are met. Because it runs on a blockchain, its execution process is transparent and tamper-proof. In this embodiment, identity authentication is performed through a smart contract, replacing the traditional centralized authentication server, to solve the problem of identity authentication paralysis of the jump machine system when the central authentication server fails in the existing solution.

[0044] In this embodiment, a smart contract is used to access the registered key hash in the on-chain database according to the user identifier.

[0045] The registered key hash is the hash value of the original key (such as the initial password) stored on the blockchain after being hashed by the user when registering the system. When the user logs in, the input password (or other key) is hashed to obtain a login key hash, which is used for comparison with the pre-stored registered key hash. The on-chain database refers to the distributed ledger of the blockchain itself, which is an unalterable database with complete copies of all nodes. In this embodiment, the mapping relationship between the user identifier of all users and the corresponding registered key hash is stored.

[0046] Further, the authentication service module in the jump machine sends a smart contract invocation request to the blockchain network through the application programming interface (API) of the blockchain node, and the smart contract invocation request carries the user identifier and the login key hash; the smart contract queries the corresponding registered key hash from the on-chain database according to the user identifier; and the smart contract automatically compares the login key hash and the registered key hash to perform primary identity authentication.

[0047] A preferred implementation, in this embodiment, the step S120 can be implemented by the following way: sending the user identifier and the login key hash to the smart contract; obtaining the primary authentication result returned by the smart contract; the primary authentication result includes authentication pass and authentication fail;

[0048] The primary authentication result is obtained by the smart contract in the following way: obtaining the corresponding registered key hash from the on-chain database based on the user identifier; comparing the login key hash and the registered key hash; generating an authentication pass authentication result when the login key hash and the registered key hash are consistent; and generating an authentication fail authentication result when the login key hash and the registered key hash are inconsistent.

[0049] Specifically, after the user identifier and the login key hash of the user are obtained, the jump machine constructs a transaction through a blockchain SDK. The essence of the transaction is to call a function named "verify" in the smart contract and package the user identifier and the login key hash as parameters; the jump machine uses a pre-configured blockchain account private key to digitally sign the transaction, and then sends it to a node in the blockchain network. Further, after the transaction is received by the blockchain node, it is broadcasted in the network; the consensus node will package the transaction into a new block, and the smart contract will access the blockchain state database to find the corresponding registration key hash of the user identifier; the smart contract will compare the incoming login key hash with the registration key hash just found from the database; if they are completely consistent, a successful authentication result is generated, and if they are not consistent, an unsuccessful authentication result is generated. Further, the execution result of the smart contract is included in the transaction receipt, and the SDK of the jump machine listens to the network to obtain the transaction receipt and parse the final first-level authentication result (pass / fail) from it; and then the jump machine decides whether to allow the user to log in according to the result.

[0050] The way of performing first-level identity authentication provided by the above embodiment has the following advantages: the smart contract is deployed on a distributed blockchain network, and as long as there are nodes alive in the network, the authentication service is available. The jump machine can connect to any reachable blockchain node to complete authentication, thereby greatly improving business continuity; and once the registration key hash of the user is written into the blockchain through a transaction, it cannot be tampered with by any single entity, effectively preventing internal personnel from forging identities or tampering by external attackers.

[0051] In another preferred implementation, in this embodiment, the following operation can also be included: generating an authentication log of the identity authentication result through the smart contract, and uploading the authentication log to the blockchain for storage.

[0052] The above authentication log specifically refers to a record automatically generated by the smart contract after completing identity authentication and permanently written into the blockchain. It is an unalterable and globally verifiable digital proof of a single authentication event.

[0053] In this embodiment, the authentication log at least includes the user identifier, the authentication time, and the authentication result. The user identifier represents the subject of this authentication event; the authentication time is used to represent the time point at which this authentication event occurred. Usually in the form of a timestamp, it is automatically attached by the blockchain network when the transaction is packaged, ensuring the objectivity and consistency of the time and preventing forgery; the authentication result is used to represent the final result of this authentication, success or failure.

[0054] Optionally, the authentication log can further include a transaction hash, a client Internet protocol address, and an operation type (login or logout).

[0055] Specifically, the way of generating the authentication log by the smart contract based on the identity authentication result can be as follows: after the smart contract executes the identity authentication logic and generates the authentication result, the smart contract code will immediately continue to execute the following operation: the smart contract will collect relevant data (user identifier, authentication result), and obtain a current blockchain timestamp as an authentication time, and combine them into a structured log record in the memory; the smart contract can publish the record by calling a special log event or directly updating a state variable. This process triggers a new transaction. The content of the transaction is not a transfer, but to “record a log”. The transaction is packaged into a new block by the consensus node, and is confirmed by network consensus. Once confirmed, the authentication log becomes part of the unchangeable historical record on the blockchain.

[0056] According to the embodiment, any login attempt is permanently and unchangeably recorded by generating the authentication log, which effectively prevents internal personnel or external hackers from tampering with the log and destroying the evidence afterwards, and provides the highest credibility data basis for security incident investigation and compliance audit.

[0057] S130, in the case that the primary authentication result is passed, allowing the user to log in to the jump machine environment.

[0058] Allowing to log in to the jump machine environment means that when the blockchain smart contract returns the primary authentication passed, the system opens the access permission of the jump machine to the user, and the user can perform subsequent operation and maintenance through the jump machine, such as remotely logging in to the server, executing instructions, or jumping to the target resource through the jump machine.

[0059] The identity authentication method provided by the embodiment stores the registration key hash in the distributed nodes of the blockchain, and the calling of the smart contract is processed by multiple nodes in the blockchain network. Even if part of the nodes fail, other nodes can still normally respond to the authentication request, which improves the fault tolerance of the identity authentication in the network interruption scenario. The problem of poor system fault tolerance in the prior art which highly depends on one or a few centralized authentication servers is solved, and the beneficial effects of improving the availability and fault tolerance of the authentication system are achieved.

[0060] Figure 2is another flowchart of the identity authentication method provided by the embodiment of the present application, and the embodiment of the present application is optimized on the basis of the above-mentioned embodiments. Specifically, on the basis of the one-level identity authentication provided in the above-mentioned embodiments, the embodiment of the present application further provides a two-level identity authentication scheme to not store any target host account password or private key in the jump machine, thereby improving the access security of the target host.

[0061] Specifically, referring to Figure 2 The identity authentication method of the embodiment includes but is not limited to the following steps:

[0062] S210, receiving a login request initiated by a client, the login request including a user identifier and a login key hash.

[0063] S220, performing one-level identity authentication on the login key hash and the corresponding registration key hash by calling a smart contract deployed on a blockchain, to obtain a one-level authentication result; wherein the smart contract is used to access the registration key hash in the on-chain database according to the user identifier.

[0064] S230, in the case where the one-level authentication result is authentication passed, allowing the user to log in to the jump machine environment.

[0065] S240, intercepting a connection command initiated by the user to the target host in the jump machine environment, the connection command including a target host identifier.

[0066] Before introducing the embodiment, the conventional scheme for connecting to the target host needs to be described in advance. In the conventional scheme, in order to realize automatic connection of the jump machine to the target host, a special account for Secure Shell (SSH) connection is usually preset on the jump machine, and a private key is generated for the special account. These private keys must be saved on the jump machine. Once the jump machine is intruded, the attacker can obtain the access permission of the target host, causing serious security threat. Therefore, the embodiment provides a two-level identity authentication scheme on the basis of the foregoing embodiments, to not store any target host account password or private key in the jump machine, thereby improving the access security of the target host. For details, see the scheme corresponding to steps S240-S270 of the embodiment.

[0067] The connection command specifically refers to a command input by the user in the command line environment of the jump machine when intending to connect to other internal servers (target host). The most common command is the SSH command. Alternatively, it can also include a remote desktop connection command, a Secure Copy Protocol (SCP) command or a remote login protocol command, and the type of connection command is not limited herein.

[0068] The target host identification is information specified in the connection command for uniquely identifying the target host. Generally, the target host identification can represent an Internet Protocol address of the target host, and when the connection command is an SSH command, the target host identification can be carried in an SSH configuration file.

[0069] The target host identification is information specified in the connection command for uniquely identifying the target host. Generally, the target host identification can represent an Internet Protocol address of the target host, and when the connection command is an SSH command, the target host identification can be carried in an SSH configuration file.

[0070] S250, in response to the connection command, obtaining authentication credentials for accessing the target host corresponding to the target host identification.

[0071] After the jump machine system detects that the user attempts to connect to a certain target host, the system automatically starts a security process to ask the user for and obtain a password or key specifically for logging in to the specific target host.

[0072] In this embodiment, obtaining authentication credentials for accessing the target host corresponding to the target host identification means that the system actively and securely collects sensitive information provided by the user. This action is initiated by a security module on the jump machine, such as the Pluggable Authentication Modules (PAM).

[0073] The above-mentioned way of obtaining authentication credentials for accessing the target host corresponding to the target host identification can be that the SSH command on the jump machine is intercepted by a custom PAM module; the PAM module triggers the system to pop up a secure input dialog box; the user inputs the password or private key password (authentication credentials) of the target host in this dialog box; the PAM module provides these credentials to the SSH client process on the jump machine for subsequent connection.

[0074] S260, according to the authentication credentials and the target host identification, initiating a connection to the target host to perform secondary identity authentication on the authentication credentials through the target host, and obtaining a secondary authentication result.

[0075] In the embodiment, the jumpboard machine acts as an agent to facilitate the standard SSH authentication between the user and the target host. The specific process is as follows: the PAM module on the jumpboard machine acts as an SSH client, uses the obtained target host identifier and authentication credentials to initiate a brand-new SSH connection to the target port of the target host; the SSH service of the target host independently performs the local identity authentication process as for any ordinary connection, and verifies whether the credentials transmitted by the jumpboard machine are correct; in the process, the jumpboard machine does not participate in decision-making and only forwards the credentials; the target host decides whether to allow the connection according to the authentication result, and if the authentication is passed, the target host allows the SSH connection to be established, and the jumpboard machine is connected successfully; if the authentication is not passed, the target host rejects the connection, and the jumpboard machine fails to be connected. In the process, the SSH request is intercepted by the PAM module on the jumpboard machine and forwarded to the target host for remote authentication, and the jumpboard machine does not save any account password or private key information of the target host, thereby fundamentally eliminating the risk of the target host being compromised due to the compromise of the jumpboard machine, and realizing the security isolation.

[0076] In one preferred implementation, the step S260 can be implemented in the following manner:

[0077] The target host receives the authentication credentials sent by the jumpboard machine; and the target host performs the secondary identity authentication on the authentication credentials according to the preset policy file to obtain a secondary authentication result. In the secondary identity authentication scheme provided in the embodiment, the target host completely controls the authentication policy, and the jumpboard machine only triggers the authentication, and the final security decision is always made in the target host, thereby realizing the end-to-end security verification in a true sense.

[0078] Specifically, the secure shell daemon (sshd) service running on the target host listens to a network port, receives the connection request from the jumpboard machine, and parses the authentication credentials from the network data packet; then the sshd sends the authentication work to the PAM framework through the interface function of the PAM, and sends the received authentication credentials to the PAM; the PAM framework reads the corresponding preset policy configuration file according to the sshd, and the preset policy file defines the complete authentication process, including a plurality of rules, such as the module type (authentication, account management, session management, and password update), the control flag (deciding the influence degree of the success or failure of the module on the final result), the module path (pointing to the shared library file for implementing the authentication logic), and the module parameter (additional options passed to the module). Further, the PAM framework executes the rules defined in the policy file in sequence, that is, loads each specified authentication management module and calls the verification method thereof; the PAM framework comprehensively calculates the final authentication result according to the return result of all modules and the control flag of each rule, to generate the secondary authentication result.

[0079] In a further preferred implementation, the preset policy file includes at least one authentication rule, and each authentication rule includes at least a control flag and an authentication management module; the authentication credential includes a password credential and a public key credential.

[0080] The password credential refers to that after the jump machine intercepts a command of the user to connect to the target host, an interactive prompt such as "please enter the password of the target host" is popped up. The user manually inputs the password under the prompt, and the jump machine temporarily acquires the password and uses it for this connection. The public key credential refers to a password set by the user for decrypting an SSH private key file, which is used to unlock the private key for subsequent public key authentication processes.

[0081] Preferably, the target host performs secondary authentication on the authentication credential according to the preset policy file, and the secondary authentication result can be obtained by the following method: the target host sequentially executes the authentication rules, and calls the corresponding authentication management module according to the control flag in each authentication rule to perform secondary authentication on the authentication credential, and obtains the secondary authentication result. The authentication management module includes a first authentication module and a second authentication module, the first authentication module is used to compare the password credential with a locally stored password hash value; and the second authentication module is used to check whether the public key credential exists in an authorized key list of the corresponding user.

[0082] Specifically, the sshd service of the target host receives the authentication credential from the jump machine, and the sshd calls the PAM framework to pass in the authentication credential; then the PAM loads the first authentication module, the first authentication module acquires the password credential, performs hash calculation, and compares with the locally stored hash value; when the comparison is consistent, success is returned, and when the comparison is inconsistent, failure is returned. In the first authentication module, the control flag is a required condition flag (required), which functions in that this module must be successful. If it fails, the final result is doomed to fail, but the PAM will continue to execute all subsequent modules, which aims to record logs and not to expose the failure point.

[0083] Further, the PAM loads the second authentication module, which checks whether the public key credential used for login is in the authorized key list of the corresponding user. When it is in the authorized key list of the user, the check is successful; otherwise, the check fails. In the second authentication module, the control flag is a sufficient condition flag (sufficient), which functions in that if this module is successful and no required module has failed before, the PAM will immediately determine that the overall authentication is successful, and skip all subsequent modules.

[0084] Finally, the PAM framework generates the final secondary authentication result according to the results of all modules and the logical relationship of the control flags.

[0085] S270, in the case of the secondary authentication result being authentication passed, establishing a connection with the target host in the jump machine environment.

[0086] The condition of the secondary authentication result being authentication passed is that all modules with the necessary condition flag must be successful, or a module with the sufficient condition flag is successful and the previous module with the necessary condition flag fails, so that the secondary authentication result is considered to be authentication passed. At this time, the sshd establishes an SSH session channel for the jump machine to establish a connection with the target host; otherwise, it is considered to be failed, the sshd directly disconnects the connection, and returns error information such as "permission denied" to the jump machine.

[0087] Specifically, for the secondary identity authentication, the following scenarios can be exemplified by the following ways:

[0088] Scenario one: required success and sufficient success; since the sufficient success, the secondary authentication result is authentication passed; scenario two: required failure and sufficient success, since the previous required module has failed, the overall authentication is failed, that is, the secondary authentication result is authentication not passed; scenario three: required success and sufficient failure, ignoring this failure, there is no other module, and all required modules have been successful, so that the overall authentication is considered to be successful, that is, the secondary authentication result is authentication passed.

[0089] The identity authentication method provided by the embodiment is used to verify the user identity when the user logs in the jump machine environment, and removes the dependence on the centralized authentication server; the distributed characteristics of the block chain are used to improve the availability of the system; the second identity authentication mechanism is used to intercept the connection command on the jump machine after the user specifies the target host, and forward the connection command to the target host for remote authentication, so that the jump machine does not save any account password or private key information of the target host, and the risk of the target host being compromised due to the compromise of the jump machine is fundamentally eliminated; the risk brought by the jump machine holding the target host credentials is eliminated, and the overall security is improved.

[0090] Figure 3 is a structural schematic diagram of an identity authentication device provided by the embodiment of the application, and the device is suitable for executing the identity authentication method provided by the embodiment of the application. As shown in Figure 3 the device specifically can include: a request receiving module 310, an identity authentication module 320, and a user login module 330, wherein:

[0091] The request receiving module 310 is configured to receive a login request initiated by a client, wherein the login request includes a user identifier and a login key hash.

[0092] The identity authentication module 320 is configured to perform first-level identity authentication on the login key hash and the corresponding registration key hash by calling a smart contract deployed on a blockchain, and obtain a first-level authentication result; wherein the smart contract is configured to access the registration key hash in an on-chain database according to the user identifier;

[0093] The user login module 330 is configured to allow the user to log in to the jump machine environment if the first-level authentication result is authentication passed.

[0094] The identity authentication device provided by the embodiment of the present application stores the registration key hash in the distributed nodes of the blockchain, and the calling of the smart contract is processed by multiple nodes in the blockchain network. Even if some nodes fail (such as the central server is down), other nodes can still normally respond to the authentication request, which improves the fault tolerance of identity authentication in the network interruption scenario, solves the problem of poor system fault tolerance in the prior art when the system highly depends on one or a few centralized authentication servers, and achieves the beneficial effects of improving the availability and fault tolerance of the authentication system.

[0095] In an embodiment, the identity authentication module 320 is specifically configured to send the user identifier and the login key hash to the smart contract, obtain a first-level authentication result returned by the smart contract, and the first-level authentication result includes authentication passed and authentication failed.

[0096] The first-level authentication result is obtained by the smart contract in the following manner: obtaining the corresponding registration key hash from the on-chain database based on the user identifier, comparing the login key hash and the registration key hash, generating the authentication passed authentication result when the login key hash and the registration key hash are consistent, and generating the authentication failed authentication result when the login key hash and the registration key hash are inconsistent.

[0097] In an embodiment, the device further includes a log generation module, wherein:

[0098] The log generation module is configured to generate an authentication log by the smart contract based on the identity authentication result, and upload the authentication log to the blockchain for storage, wherein the authentication log at least includes the user identifier, an authentication time and an authentication result.

[0099] In an embodiment, the device further includes a hash processing module and a key sending module, wherein:

[0100] The request receiving module 310 is further configured to receive a registration request initiated from the client, and the registration request includes a user identifier and a registration key.

[0101] The hash processing module is configured to hash the registration key to generate a registration key hash;

[0102] The key sending module is configured to send the user identifier and the registration key hash to the smart contract, so as to store the user identifier and the corresponding registration key hash in the on-chain database of the blockchain through the smart contract.

[0103] In an embodiment, the apparatus further comprises a command interception module, a command response module, and a host connection module, wherein:

[0104] The command interception module is configured to intercept a connection command initiated by a user to a target host in the jump server environment, the connection command comprising a target host identifier.

[0105] The command response module is configured to obtain authentication credentials for accessing a target host corresponding to the target host identifier in response to the connection command.

[0106] The identity authentication module 320 is further configured to initiate a connection to the target host according to the authentication credentials and the target host identifier, so as to perform a secondary identity authentication on the authentication credentials through the target host to obtain a secondary authentication result.

[0107] The host connection module is configured to establish a connection with the target host in the jump server environment in a case where the secondary authentication result is authentication passed.

[0108] In an embodiment, the identity authentication module 320 comprises a credential receiving unit and an identity authentication unit, wherein:

[0109] The credential receiving unit is configured to receive, by the target host, the authentication credentials sent by the jump server.

[0110] The identity authentication unit is configured to perform a secondary identity authentication on the authentication credentials according to a preset policy file to obtain the secondary authentication result.

[0111] In an embodiment, the preset policy file comprises at least one authentication rule, and each authentication rule comprises at least a control flag and an authentication management module; and the authentication credentials comprise a password credential and a public key credential.

[0112] The identity authentication unit is specifically configured to sequentially execute the authentication rules by the target host, call a corresponding authentication management module to perform secondary identity authentication on the authentication credentials according to a control flag bit in each of the authentication rules, and obtain the secondary authentication result; wherein the authentication management module includes a first authentication module and a second authentication module, the first authentication module is configured to compare the password credentials with a locally stored password hash value; and the second authentication module is configured to check whether the public key credentials exist in an authorized key list of a corresponding user.

[0113] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above functional modules is taken as an example, and in actual application, the above functions can be completed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. The specific working process of the above described functional modules can refer to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0114] The electronic device provided in the embodiments of the present application includes at least one processor, and a memory connected with the at least one processor in communication; wherein the memory stores a computer program which can be executed by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to execute the identity authentication method provided in any of the embodiments of the present application.

[0115] The embodiments of the present application further provide a computer readable medium, and the computer readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to execute the identity authentication method provided in any of the embodiments of the present application when the processor executes the computer instructions.

[0116] The following refers to Figure 4 , Figure 4 is a structural schematic diagram of an electronic device provided in the embodiments of the present application. It shows a structural schematic diagram of a computer system 500 of the electronic device suitable for implementing the embodiments of the present application. Figure 4 The electronic device shown is only an example, and should not bring any limitation to the functions and use range of the embodiments of the present application.

[0117] As Figure 4As shown, the computer system 500 includes a central processing unit (CPU) 501 which can perform various appropriate actions and processes according to programs stored in a read only memory (ROM) 502 or loaded into a random access memory (RAM) 503 from a storage section 508. In the RAM 503, various programs and data required for the operation of the system 500 are also stored. The CPU 501, the ROM 502, and the RAM 503 are connected to each other through a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0118] Connected to the I / O interface 505 are an input section 506 including a keyboard, a mouse, etc.; an output section 507 including a display device such as a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card such as a LAN card, a modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to the I / O interface 505 as necessary. A removable recording medium 511 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc. is attached to the drive 510 as necessary, so that a computer program read therefrom is installed into the storage section 508 as necessary.

[0119] In particular, according to the embodiments of the present disclosure, the processes described above with reference to the flowcharts can be implemented as a computer software program. For example, the embodiments of the present disclosure include a computer program product comprising a computer program carried on a computer readable medium, the computer program containing program codes for executing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network by the communication section 509, and / or installed from the removable recording medium 511. When the computer program is executed by the central processing unit (CPU) 501, the above-described functions defined in the system of the present disclosure are performed.

[0120] It should be noted that computer-readable medium of the present application can be computer-readable signal medium or computer-readable storage medium or any combination thereof. The computer-readable storage medium, for example, can include but is not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination thereof. More specific examples of the computer-readable storage medium can include, but are not limited to, an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the present application, the computer-readable storage medium can be any tangible medium that contains or stores a program used by or in connection with an instruction execution system, apparatus, or device. In the present application, the computer-readable signal medium can include a data signal that propagates in baseband or as part of a carrier wave by any suitable medium, including but not limited to wire, wireline, or fiber optic. Such a propagated signal can take any suitable form, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium that is not a storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted by any suitable medium, including but not limited to wireless, wireline, optical fiber, and the like, or any suitable combination thereof.

[0121] The flow diagrams and block diagrams in the drawings are illustrations of possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of the present application. In this regard, each block in the flow diagrams or block diagrams can represent a module, a segment, or a portion of code, which comprises one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or the blocks can sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flow diagrams, and combinations thereof, can be implemented by special purpose hardware-based systems that perform the specified functions or operations, or combinations of special purpose hardware and computer instructions.

[0122] The modules and / or units involved in the embodiments of the present application can be implemented by software or by hardware. The described modules and / or units can also be arranged in a processor, for example, can be described as: a processor includes a request receiving module, an identity authentication module and a user login module. In some cases, the names of these modules do not constitute a limitation on the modules themselves.

[0123] As another aspect, the present application also provides a computer readable medium, which can be included in the device described in the above embodiments, or can exist independently without being assembled into the device. The computer readable medium carries one or more programs, when the one or more programs are executed by the device, the device includes: receiving a login request initiated by a client, the login request including a user identifier and a login key hash; performing primary identity authentication on the login key hash and a corresponding registration key hash by calling a smart contract deployed on a blockchain, to obtain a primary authentication result; wherein the smart contract is used to access the registration key hash in the on-chain database according to the user identifier; in the case that the primary authentication result is authentication passed, allowing the user to log in to the jump server environment.

[0124] According to the technical scheme of the present embodiment, the registration key hash is stored in the distributed nodes of the blockchain, and the calling of the smart contract is processed by multiple nodes in the blockchain network. Even if part of the nodes fail (such as the central server is down), other nodes can still normally respond to the authentication request, improving the fault tolerance of identity authentication in the network interruption scenario; solve the problem that the existing scheme is highly dependent on one or a few centralized authentication servers, and obtain the beneficial effects of improving the availability and fault tolerance of the authentication system.

[0125] The above specific embodiments do not constitute a limitation on the protection scope of the present application. Those skilled in the art should understand that various modifications, combinations, sub-combinations and substitutions can occur depending on design requirements and other factors. Any modification, equivalent replacement and improvement made within the spirit and principle of the present application should be included in the protection scope of the present application.

Claims

1. An identity authentication method, characterized in that, The method includes: Receive a login request initiated by a client, the login request including a user identifier and a login key hash; The login key hash and the corresponding registration key hash are used to perform first-level identity authentication by calling a smart contract deployed on the blockchain to obtain a first-level authentication result; wherein, the smart contract is used to access the registration key hash in the on-chain database based on the user identifier; If the primary authentication result is successful, the user is allowed to log in to the jump server environment.

2. The identity authentication method according to claim 1, characterized in that, The step of performing first-level identity authentication by calling a smart contract deployed on the blockchain to verify the login key hash and the corresponding registration key hash, and obtaining the first-level authentication result, includes: Send the user identifier and the login key hash to the smart contract; Obtain the first-level authentication result returned by the smart contract; the first-level authentication result includes authentication passed and authentication failed; The first-level authentication result is obtained by the smart contract in the following way: Based on the user identifier, obtain the corresponding registration key hash from the on-chain database; Compare the login key hash with the registration key hash; When the login key hash and the registration key hash match, an authentication result indicating successful authentication is generated. If the login key hash and the registration key hash do not match, an authentication failure result is generated.

3. The identity authentication method according to claim 1, characterized in that, The method further includes: The smart contract generates an authentication log from the identity authentication result and uploads the authentication log to the blockchain for storage. The authentication log includes at least the user identifier, authentication time, and authentication result.

4. The identity authentication method according to claim 1, characterized in that, Before receiving a login request initiated by the client, the method further includes: Receive a registration request initiated from the client, the registration request including a user identifier and a registration key; The registration key is hashed to generate a registration key hash. The user identifier and the registration key hash are sent to the smart contract so that the user identifier and the corresponding registration key hash are stored in the on-chain database of the blockchain through the smart contract.

5. The identity authentication method according to claim 1, characterized in that, After allowing users to log in to the jump server environment, the method further includes: Intercept connection commands initiated by users to the target host in the jump server environment, the connection commands including the target host identifier; In response to the connection command, obtain authentication credentials for accessing the target host corresponding to the target host identifier; A connection is initiated to the target host based on the authentication credentials and the target host identifier, so as to perform secondary authentication on the authentication credentials through the target host and obtain the secondary authentication result; If the secondary authentication result is successful, a connection is established with the target host in the jump server environment.

6. The identity authentication method according to claim 5, characterized in that, The step of performing secondary authentication on the authentication credentials through the target host to obtain a secondary authentication result includes: The target host receives the authentication credentials sent by the jump server; The target host performs secondary authentication on the authentication credentials according to a preset policy file to obtain the secondary authentication result.

7. The identity authentication method according to claim 6, characterized in that, The preset policy file includes at least one authentication rule, and each authentication rule includes at least a control flag and an authentication management module; The authentication credentials include password credentials and public key credentials; The target host performs secondary authentication on the authentication credentials according to a preset policy file to obtain the secondary authentication result, including: The target host executes the authentication rules sequentially, and calls the corresponding authentication management module to perform secondary authentication on the authentication credentials according to the control flag bit in each authentication rule, thereby obtaining the secondary authentication result; wherein, the authentication management module includes a first authentication module and a second authentication module, the first authentication module is used to compare the password credentials with the locally stored password hash value; the second authentication module is used to verify whether the public key credentials exist in the corresponding user's authorized key list.

8. An identity authentication device, characterized in that, The device includes: The request receiving module is used to receive login requests initiated by clients, the login requests including user identifiers and login key hashes; The identity authentication module is used to perform first-level identity authentication on the login key hash and the corresponding registration key hash by calling a smart contract deployed on the blockchain, and obtain a first-level authentication result; wherein, the smart contract is used to access the registration key hash in the on-chain database according to the user identifier; The user login module is used to allow users to log in to the jump server environment if the first-level authentication result is successful.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the authentication method according to any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the authentication method as described in any one of claims 1-7.

Images