Cross-domain identity authentication method and system for private instant messaging system based on alliance chain

Abstract

The application discloses a cross-domain identity authentication method and system of a special instant messaging system based on a consortium chain. First, a consortium chain is constructed, and the consensus nodes of the consortium chain are communication servers subordinate to a certain domain. An administrator manages the cross-domain authentication rights of users, and cross-domain two-way authentication is performed between users connected to different communication servers. If the cross-domain authentication is passed, cross-domain communication is established. This technical solution does not change the authentication mode in the original system, connects the communication servers of each system as consortium chain nodes, each system is provided with an administrator responsible for managing and allocating cross-domain authentication rights, the administrator stores the related information of users with cross-domain authentication rights on a chain, and through the characteristics of the blockchain technology, such as difficulty of tampering, collective maintenance of account books and distributed multi-center, the trustworthiness is improved, the authentication transmission process is reduced, and an efficient cross-domain two-way identity authentication scheme is designed, so that the cross-domain authentication process becomes more convenient.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of computer security, and relates to a cross-domain authentication method, in particular to a cross-domain identity authentication method and system for a special instant messaging system based on a consortium chain. BACKGROUND

[0002] At present, many enterprises and institutions will deploy a special instant messaging system for internal use for the sake of communication efficiency and security. The special instant messaging system can guarantee the communication efficiency and security of enterprise and institution users at work. In order to ensure security, the system often controls access, which makes the system have a certain degree of closure. When the special instant messaging systems of enterprises and institutions and various cooperative units access each other, the problem of trust arises, and cross-domain authentication technology is needed. However, the traditional cross-domain authentication technology has problems such as complex trust path construction, long verification path, low verification efficiency, centralization and the like.

[0003] Chinese patent application No. 2021103119489 provides a cross-domain authentication method for remote medical treatment based on a consortium chain, which adopts blockchain technology to avoid the online query process of the revocation state of traditional certificates, optimizes the verification mode of identity certificates, effectively guarantees the timeliness of certificate information on the chain, and reduces the storage space size of certificate data. SUMMARY

[0004] The purpose of the present application is to provide a cross-domain identity authentication method and system for a special instant messaging system based on a consortium chain, which has high trustworthiness and fast cross-domain authentication process.

[0005] In order to achieve the above purpose, the solution of the present application is as follows:

[0006] A cross-domain identity authentication method for a special instant messaging system based on a consortium chain, comprising the following steps:

[0007] Step 1: Construct a consortium chain, wherein the consortium chain is provided with a plurality of consensus nodes, the consensus nodes are communication servers belonging to a certain domain, and the communication servers have been verified and permitted by the consortium chain; the consortium chain is provided with a ledger, which is used to record the user information of the communication servers corresponding to each consensus node that has cross-domain authentication demand, the user information including user attributes, a digital certificate signed by a CA in the system where the user is located, and a timestamp;

[0008] Step two, the first user connected to the first communication server initiates a cross-domain authentication permission application to the second user connected to the second communication server, and the second administrator corresponding to the second communication server decides whether to accept, if accepted, the second administrator confirms that the first user is in the friend list of the second user, and the first administrator confirms that the second user is in the friend list of the first user; then turn to step three; if the second administrator does not accept, feedback information to the second communication server;

[0009] Step three, the first user connected to the first communication server and the second user connected to the second communication server perform cross-domain two-way authentication, and if the cross-domain authentication is passed, the first user and the second user establish cross-domain communication, and if the cross-domain authentication is not passed, the first user and the second user do not establish cross-domain communication.

[0010] The specific process of the above step two is,

[0011] Step A1, the first administrator corresponding to the first communication server submits cross-domain authentication permission request information to the first communication server, and the cross-domain authentication permission request information includes the second communication server and the second user information;

[0012] Step A2, after the first communication server confirms the identity of the first administrator, it queries the address information of the second communication server from the alliance chain, and sends the cross-domain authentication permission request information of the first user to the second communication server;

[0013] Step A3, after the second communication server receives the request information of the first communication server, it first confirms the identity of the first communication server, and then generates the corresponding cross-domain authentication permission request information and feeds back to the second administrator corresponding to the second communication server;

[0014] Step A4, after the second administrator receives the cross-domain authentication permission request of the first user to the second user, it decides whether to allow the first user and the second user to establish cross-domain communication, and feeds back the information of allowing or not allowing to establish cross-domain communication to the second communication server; if allowed, turn to step A5, if not allowed, turn to step A6;

[0015] Step A5, it is judged whether the second user is in the cross-domain authentication whitelist of the second communication server, if yes, the first user is added to the friend list of the second user; if not, the second communication server first packs the user information of the second user into a block, and after multi-party consensus, it is chained, that is, the attributes of the second user, the digital certificate signed by the CA in the system where it is located and the current blockchain system timestamp are written into the alliance chain account book, and then the first user is added to the friend list of the second user; then turn to step A6;

[0016] Step A6, the second communication server feeds back the information of allowing or not allowing to establish cross-domain communication decided by the second administrator to the first communication server;

[0017] Step A7, the first communication server receives and parses the information fed back by the second communication server; if the second administrator allows to establish cross-domain communication, step A8 is transferred; if the second administrator does not allow to establish cross-domain communication, step A9 is transferred;

[0018] Step A8, it is judged whether the first user is in the cross-domain authentication whitelist of the first communication server, if yes, the second user is added to the friend list of the first user; if not, the first communication server first chains the user information of the first user, that is, the attributes of the first user, the digital certificate signed by the CA in the system where the first user is located and the current blockchain system timestamp are written into the alliance chain ledger, and then the second user is added to the friend list of the first user; then step A9 is transferred;

[0019] Step A9, the first communication server feeds back the information of the second administrator deciding to allow or not to allow to establish cross-domain communication and the operation result of the first communication server to the first administrator and the first user.

[0020] The specific process of the above step three is,

[0021] Step B1, the first user initiates a cross-domain communication request to the first communication server;

[0022] Step B2, the first communication server verifies the identity of the first user, and after verification, the first communication server obtains the certificate Cert B of the second user marked with the latest timestamp and sends it to the first user;

[0023] Step B3, after the first user receives the certificate Cert B of the second user, a cross-domain authentication message M A is generated based on the public key K pub_B of the second user, and M A is sent to the first communication server, M A contains C A and cross-domain communication information, C A is encrypted information containing random number r A , and the cross-domain authentication information includes the information of the second user;

[0024] Step B4, after the first communication server receives M A , M A is forwarded to the second communication server;

[0025] Step B5, after the second communication server receives M A , the certificate Cert A of the first user marked with the latest timestamp is obtained from the alliance chain, and M Aand Cert A Send to the second user;

[0026] Step B6, the second user receives M A and Cert A Afterwards, from M A Extracting C A and using the second user's private key K pri_B Decryption yields r A The second user also obtained information from Cert. A Extract the first user's public key K pub_A And based on K pub_A Decryption yields r A ', determine r A With r A Are they equal? ​​If r A ==r A Then a cross-domain authentication message M is generated. B and M B Sent to the first communication server, M B Contains r A hash value h A And the information of the first user; if r A ≠r A Then the second user rejects the first user's cross-domain authentication request and returns a cross-domain authentication failure message;

[0027] Step B7, the first communication server receives M B Then, verify its legality; if M B If invalid, discard the request and return a cross-domain authentication failure message; if valid, send it to the first user.

[0028] Step B8, the first user receives M B Afterwards, from M B Extract the hash value h A And determine its relationship with r. A hash value h A 'Whether they are equal, if h A ==h A Then, cross-domain authentication between the first user and the second user is successful, and cross-domain communication is established; if h A ≠h A If the first user does not establish cross-domain communication with the second user, a cross-domain authentication failure message will be returned.

[0029] Step B2 above also includes: the first communication server verifies the identity of the first user; after successful verification, the first communication server checks if the second user is in the cross-domain authentication whitelist; if so, the first communication server obtains the second user's certificate Cert, marked with the latest timestamp, from the consortium blockchain. BThe system continues to check if the certificate content is empty. If the certificate content is not empty, it is sent to the first user. If the certificate content is empty, the cross-domain authentication request initiated by the first user is rejected. If there is no certificate for the second user, the cross-domain authentication request initiated by the first user is rejected.

[0030] The specific content of step B3 above is as follows:

[0031] Step B31, the first user receives the second user's certificate (Cert). B After that, the certificate Cert B Extract the second user's public key K pub_B ;

[0032] Step B32, generate a random number r A And using the first user's private key K pri_A Encryption r A Get R A ;

[0033] Step B33, generate authentication message m A m A =R A ||r A , || indicates a concatenation operation;

[0034] Step B34, using the second user's public key K pub_B Encryption m A Get C A ;

[0035] Step B35, generate cross-domain authentication message M A and M A Sent to the first communication server, M A Includes C A And the information of the second user.

[0036] The specific content of step B6 above is as follows:

[0037] Step B61, the second user receives M A and Cert A Afterwards, from M A Extracting C A From Cert A Extract the first user's public key K pub_A ;

[0038] Step B62, using your own private key K pri_B Decrypting C A Received authentication message m A and from m A Extract r A and R A ;

[0039] Step B63, use the first user's public key K pub_A Decrypt R A Get r A ', determine whether r A is equal to r A '; if r A == r A , it means that the identity of the first user is trusted, and the second user will accept the cross-domain authentication request of the first user, go to step B64; if r A ≠ r A , it means that the identity of the first user is not trusted, and the second user rejects the cross-domain authentication request of the first user, and returns cross-domain authentication failure information;

[0040] Step B64, calculate the hash value h A of r A , generate a cross-domain authentication message M B , and send M B to the first communication server, M B contains h A and the information of the first user.

[0041] In the above step B5, after the second communication server receives M A , it first verifies whether the first user is in the cross-domain authentication whitelist, if not, it discards M A and returns cross-domain authentication failure information; if yes, it continues to verify the legality of M A ; if M A is illegal, it is discarded and cross-domain authentication failure information is returned; if M A is legal, the certificate Cert A of the first user marked with the latest timestamp is obtained from the alliance chain, and it is determined whether the certificate content is empty, if not, M A and Cert A are sent to the second user; if it is empty, M A is discarded and cross-domain authentication failure information is returned.

[0042] A cross-domain identity authentication system of a special instant messaging system based on an alliance chain, comprising a plurality of communication servers in the alliance chain as consensus nodes thereof, the plurality of communication servers belong to a certain domain, and each communication server has been verified and permitted by the alliance chain;

[0043] Any of the communication servers corresponds to an administrator, which is used to determine whether to accept a cross-domain authentication permission application initiated by a user connected to another communication server;

[0044] Cross-domain two-way authentication is performed between two users connected to two different communication servers, cross-domain authentication is passed, and the two users establish cross-domain communication, cross-domain authentication is not passed, and the two users do not establish cross-domain communication.

[0045] Any of the above communication servers corresponds to an administrator, and the administrator is further configured to submit a user information update application of a user connected to the communication server to the communication server, and the communication server updates the user information.

[0046] Any of the above communication servers corresponds to an administrator, and the administrator is further configured to submit a user information update application of a user connected to the communication server to the communication server, and the communication server updates the user information.

[0047] Any of the above communication servers corresponds to an administrator, and the administrator is further configured to submit a user information update application of a user connected to the communication server to the communication server, and the communication server updates the user information.

[0048] After the above scheme is adopted, the present application connects the communication servers of each system as alliance chain nodes without changing the authentication mode in the original system, each system is provided with an administrator responsible for managing and controlling and distributing cross-domain authentication permissions, the administrator stores the related information of the user with cross-domain authentication permission on the chain, and through the characteristics of the blockchain technology such as tamper resistance, collective maintenance of the ledger and distributed multi-center, the trustworthiness is improved, the authentication transmission process is reduced, and an efficient cross-domain two-way identity authentication scheme is designed, so that the cross-domain authentication process becomes more convenient.

[0049] The beneficial effects of the present application are:

[0050] (1) The cross-domain authentication permission in the present application is managed and controlled and distributed by the administrator, the system responsibility subject has management and control ability on the cross-domain authentication permission of the user, can effectively master and control the cross-domain authentication permission of the user according to the authorization rules, the manager can effectively control the cross-domain authentication behavior of the system user, and meets the controllability requirement of network information security on the system.

[0051] (2) The present application only needs to store the related information of the cross-domain authentication user on the chain, the on-chain information is less, and the system running efficiency is high; the alliance chain node only has the cross-domain authentication user information, only the user with cross-domain authentication permission can be visible to each other, and the risk of user information leakage is low.

[0052] (3) The authentication speed of the present application is fast, and only 1-RTT is needed to complete the two-way identity authentication. BRIEF DESCRIPTION OF DRAWINGS

[0053] Figure 1 is a cross-domain authentication framework diagram of the present application;

[0054] Figure 2 is a cross-domain authentication permission request flowchart of the present application;

[0055] Figure 3 is a cross-domain identity authentication flowchart of the present application. DETAILED DESCRIPTION

[0056] The technical solutions and beneficial effects of the present application will be described in detail below with reference to the accompanying drawings.

[0057] The present application provides a special instant messaging system cross-domain identity authentication method and system based on a consortium chain, which includes three stages of constructing a consortium chain, cross-domain permission management and cross-domain authentication, and the specific implementation steps are as follows:

[0058] I. Constructing a consortium chain

[0059] As shown in Figure 1 , the consortium chain refers to a blockchain jointly managed by several institutions, each of which runs one or more nodes. Compared with a private chain, it is more in line with the business needs of cross-domain communication between enterprises. On the other hand, compared with a public chain, the consortium chain has higher block generation efficiency and stronger system scalability. Therefore, the present application adopts the form of a consortium chain to construct a blockchain.

[0060] After the communication servers under multiple domains are verified and permitted by the consortium chain, they are added to the consortium chain as consensus nodes. The node admission and exit mechanism of the consortium chain controls the addition and exit of nodes, and the nodes reach an agreement through a consensus algorithm to form a trust domain. The ledger of the consortium chain is used to record the user information of the communication servers corresponding to each node that has cross-domain authentication needs. The user information includes user attributes, CA signed digital certificates and timestamps in the system where the user is located. The security storage and management of user information are ensured by the decentralized and consensus mechanisms of the blockchain, wherein the user attributes refer to user nicknames, IDs and other identifiers.

[0061] II. Cross-domain permission management Figure 2

[0062] In order to manage the user cross-domain authentication permissions more granularly, implement the life cycle process similar to the traditional CA certificate, and attach a timestamp marker to the on-chain user digital certificate, when the user information is updated or revoked, upload the new user information or content-empty user information to the blockchain network and attach the latest timestamp. When the blockchain node wants to query the information of the corresponding user, it regards the latest timestamp marked digital certificate stored on the chain as valid, and the rest as invalid, so as to realize the management operations of application, update and revocation of user cross-domain authentication permissions.

[0063] ​1. Application of cross-domain authentication permission

[0064] The administrator applies for the cross-domain authentication permission for the user with cross-domain authentication needs on the system management platform. The cross-domain authentication permission is the permission of the user to perform cross-domain authentication with which users in which communication systems in the alliance chain. The user obtaining the cross-domain authentication permission can view the corresponding cross-domain authentication permission information in the friend list.

[0065] The server, administrator and user of the cross-domain authentication permission request initiator are respectively denoted as the first communication server, the first administrator and the first user. The server, administrator and user of the cross-domain authentication permission request response are respectively denoted as the second communication server, the second administrator and the second user. The specific steps of the first user of the first communication system in the alliance chain to the second communication system to initiate the cross-domain authentication permission application with the second user are as follows:

[0066] (1) The first administrator submits the cross-domain authentication permission request information to the first communication server on the first management platform for the first user. The request information includes the second communication server and the second user information.

[0067] (2) After the first communication server confirms the identity of the first administrator, the address information of the second communication server is queried from the alliance chain, and the cross-domain authentication permission request of the first user is sent to the second communication server.

[0068] (3) After the second communication server receives the request information of the first communication server, the identity of the first communication server is first confirmed, and then the corresponding cross-domain authentication permission request information is generated and fed back to the second administrator of the second communication server.

[0069] (4) After the second administrator receives the cross-domain authentication permission request of the first user to the second user, it is decided according to the actual business needs whether to allow the first user and the second user to establish cross-domain communication, and the feedback information of allowing or not allowing to establish cross-domain communication is submitted to the second communication server on the second management platform.

[0070] (5) If the second administrator allows the two parties to establish cross-domain communication, and the second user is in the cross-domain authentication whitelist of the second communication server, the first user is added to the friend list of the second user.

[0071] (6) If the second administrator allows the two parties to establish cross-domain communication, and the second user is not in the cross-domain authentication whitelist of the second communication server, the second communication server needs to first pack the user information of the second user into a block, and after multi-party consensus, it is chained, that is, the attributes of the second user, the digital certificate signed by the CA in the system where it is located and the current blockchain system timestamp are written into the alliance chain ledger, and then the first user is added to the friend list of the second user.

[0072] (7) If the second administrator does not allow the two parties to establish cross-domain communication, the second communication server does not need to perform the operation of step (6);

[0073] (8) The second communication server feeds back the authorization situation of the second administrator to the first user's cross-domain communication request to the first communication server;

[0074] (9) The first communication server receives the authorization situation information fed back by the second communication server and parses the feedback information;

[0075] (10) If the second administrator allows the first user to establish cross-domain communication with the second user, and the first user is in the cross-domain authentication whitelist of the first communication server, the first communication server only needs to add the second user to the friend list of the first user;

[0076] (11) If the second administrator allows the first user to establish cross-domain communication with the second user, and the first user is not in the cross-domain authentication whitelist of the first communication server, the first communication server needs to first chain the user information of the first user, that is, write the attributes of the first user, the digital certificate signed by the CA in the system where it is located and the current blockchain system timestamp into the alliance chain account book, and then add the second user to the friend list of the first user;

[0077] (12) If the second administrator does not allow the two parties to establish cross-domain communication, the first communication server does not need to perform the operation;

[0078] (13) The first communication server feeds back the authorization situation of the second administrator to the first user's cross-domain communication request and the operation result of the first communication server to the first administrator and the first user.

[0079] 2. Update cross-domain authentication permission

[0080] When the first user needs to update the user information, the first administrator submits a user information update application to the first communication server on the management platform, requesting the first communication server to perform an update operation on the first user information;

[0081] The first communication server authenticates the first administrator, and after authentication, the first communication server submits a new first user information transaction to the blockchain system, that is, a new user attribute, a digital certificate signed by the CA in the system where it is located and a current blockchain system timestamp, to update the first user information on the blockchain account.

[0082] 3. Revoking the cross-domain authentication permission of the user

[0083] When the first user wants to leave the instant messaging system where it is located, the first administrator needs to submit a user information revocation request to the first communication server on the management platform;

[0084] The first communication server authenticates the first administrator, and after authentication, the first communication server submits a new user information transaction to the blockchain system, i.e., the attributes of the original user, an empty digital certificate, and the current blockchain system timestamp.

[0085] At the same time, if the first user exists in the cross-domain authentication white list of each communication server as a blockchain node, the first user needs to be deleted from the white list, and if not, no operation is needed.

[0086] 4. Revoking cross-domain authentication authority between a user and a specified user of another instant messaging system

[0087] When the first administrator wants to revoke the cross-domain communication between the first user and the specified user under another instant messaging system, the first administrator needs to submit a cross-domain authentication authority revocation request between the first user and the specified user to the first communication server on the management platform, and the first communication server submits the request transaction to the blockchain system, which is chained after multi-party consensus, and the transaction is executed by the communication server of the instant messaging system where the specified user is located. The communication server deletes the first user information from the cross-domain authentication white list.

[0088] Three, cross-domain authentication Figure 3

[0089] The first user of the first communication system in the alliance chain and the second user of the second communication system perform cross-domain two-way authentication, and the specific process is as follows:

[0090] (1) The first user initiates a cross-domain communication request to the second user to the first communication server;

[0091] (2) The first communication server verifies the identity of the first user, and after verification, the first communication server checks whether the second user exists in the cross-domain authentication white list, if the first communication server obtains the certificate Cert B of the second user marked with the latest timestamp from the alliance chain, and continues to judge whether the certificate content is empty, if the certificate content is not empty, it is sent to the first user, if the certificate content is empty, the cross-domain authentication request initiated by the first user is rejected; if there is no certificate of the second user, the cross-domain authentication request initiated by the first user is rejected;

[0092] (3) After the first user receives the certificate Cert B of the second user, the following operations are performed:

[0093] ① Extract the public key K pub_B of the second user from the certificate Cert B ;

[0094] ② Generate a random number r A ​And using the first user's private key K pri_A Encryption r A Get R A ;

[0095] ③ Generate authentication message m A m A =R A ||r A , || indicates a concatenation operation;

[0096] ④ Use the second user's public key K pub_B Encryption m A Get C A ;

[0097] ⑤ Generate cross-domain authentication message M A and M A Sent to the first communication server, M A Includes C A And the information of the second user.

[0098] (4) The first communication server receives M A Then, M A Forwarded to the second communication server;

[0099] (5) The second communication server receives the cross-domain authentication message M A Next, verify whether the first user exists in the cross-domain authentication whitelist. If it does, then verify M. A Legality; if it does not exist, then directly set M to... A Discard and return a cross-domain authentication failure message;

[0100] (6) Verify M A Legality, if M A If invalid, discard it directly and return a cross-domain authentication failure message; if M A If valid, then obtain the certificate (Cert) of the first user marked with the latest timestamp from the consortium blockchain. A And determine if the certificate content is empty. If it is not empty, then M A and Cert A Send to the second user; if empty, directly send M. A Discard and return a cross-domain authentication failure message. The validity verification method is selected by the developers according to actual needs; for example, it can be achieved by verifying the first server's authentication with M. A The correctness of M's signature is used to verify its validity. A The legitimacy of it.

[0101] (7) The second user receives M A and Cert A Then, perform the following operations:

[0102] ① Extract the encrypted authentication message C from M A A Extract the first user's public key K from the certificate Cert A pub_A ;

[0103] ② Decrypt C using the private key K pri_B A to obtain the authentication message m A , and extract r A and R from m A A ;

[0104] ③ Decrypt R using the first user's public key K pub_A A to obtain r A ', and verify the identity of the first user by determining whether r A is equal to r A '. If r A == r A ', the identity of the first user is trusted, and the second user will accept the cross-domain authentication request of the first user and continue to perform subsequent operations. If r A ≠ r A ', the identity of the first user is not trusted, and the second user directly rejects the cross-domain authentication request of the first user and returns cross-domain authentication failure information.

[0105] ④ Calculate the hash value h A of r A , generate a cross-domain authentication message M B , and send M B to the first communication server. M B contains h A and information of the first user.

[0106] ⑤ After the first communication server receives the cross-domain authentication message M B , it verifies its legality. If M B is not legal, it is discarded directly and cross-domain authentication failure information is returned. If it is legal, it is sent to the first user. The method of verifying legality is selected by the developer according to actual needs, for example, the legality of M B may be verified by verifying the correctness of the signature of M B by the second server.

[0107] (8) After the first user receives M B , the following operations are performed:

[0108] ① Extract the hash value h B from M A ; ​​​​​

[0109] ② Calculate the previously generated local random number r A hash value h A ';

[0110] ③ By judging h A with h A 'Whether they are equal is used to verify the trustworthiness of the second user's identity. If h A ==h A 'Indicates that the second user's identity is trusted, and the first user can successfully authenticate with the second user across domains, enabling cross-domain communication; if h A ≠h A This indicates that the second user's identity is untrusted, and the first user will not establish cross-domain communication with the second user, returning a cross-domain authentication failure message.

[0111] The above embodiments are merely illustrative of the technical concept of the present invention and should not be construed as limiting the scope of protection of the present invention. Any modifications made to the technical solutions based on the technical concept proposed in this invention shall fall within the scope of protection of this invention.

Claims

1. A method for cross-domain identity authentication based on a private instant messaging system of a consortium chain, characterized in that Includes the following steps: Step 1: Construct a consortium blockchain. The consortium blockchain has several consensus nodes, which are communication servers belonging to a certain domain and have been verified and authorized by the consortium blockchain. The consortium blockchain has a ledger, which is used to record user information that has cross-domain authentication requirements in the communication server corresponding to each consensus node. The user information includes user attributes, digital certificates signed by CA in the user's system, and timestamps. Step 2: The first user connected to the first communication server initiates a cross-domain authentication permission request to the second user connected to the second communication server. The second administrator corresponding to the second communication server decides whether to accept the request. If accepted, the second administrator confirms that the first user is in the second user's friend list, and the first administrator confirms that the second user is in the first user's friend list. Proceed to step three; if the second administrator does not accept, then send feedback to the second communication server; Step 3: The first user connected to the first communication server and the second user connected to the second communication server perform cross-domain two-way authentication. If the cross-domain authentication is successful, the first user and the second user establish cross-domain communication; if the cross-domain authentication fails, the first user and the second user do not establish cross-domain communication. The specific process of step two is as follows: Step A1: The first administrator corresponding to the first communication server submits cross-domain authentication permission request information to the first communication server. The cross-domain authentication permission request information includes the second communication server and the second user information. Step A2: After confirming the identity of the first administrator, the first communication server queries the address information of the second communication server from the consortium blockchain and sends the first user's cross-domain authentication permission request information to the second communication server. Step A3: After receiving the request information from the first communication server, the second communication server first confirms the identity of the first communication server, and then generates the corresponding cross-domain authentication permission request information and sends it back to the second administrator corresponding to the second communication server. Step A4: After receiving the cross-domain authentication permission request from the first user to the second user, the second administrator decides whether to allow the first user to establish cross-domain communication with the second user, and sends the information of allowing or disallowing the establishment of cross-domain communication back to the second communication server. If allowed, proceed to step A5; if not allowed, proceed to step A6. Step A5: Determine whether the second user is in the cross-domain authentication whitelist of the second communication server. If so, add the first user to the second user's friend list. If not, the second communication server first packages the second user's user information into a block, and after consensus among multiple parties, uploads it to the blockchain. This means writing the second user's attributes, the digital certificate signed by the CA in the system, and the current blockchain system timestamp into the consortium blockchain ledger, and then adding the first user to the second user's friend list. Then proceed to step A6; Step A6: The second communication server feeds back the information from the second administrator, deciding whether to allow or disallow cross-domain communication, to the first communication server. Step A7: The first communication server receives and parses the information fed back by the second communication server; If the second administrator allows cross-domain communication, proceed to step A8; If the second administrator does not allow the cross-domain communication to be established, step A9 is performed; In step A8, it is determined whether the first user is in the cross-domain authentication whitelist of the first communication server. If yes, the second user is added to the friend list of the first user. If not, the user information of the first user is first chained, i.e., the attributes of the first user, the digital certificate signed by the CA in the system where the first user is located, and the current blockchain system timestamp are written into the alliance chain ledger, and then the second user is added to the friend list of the first user. Then, step A9 is performed; In step A9, the first communication server feeds back the information of the decision of the second administrator on whether to allow or not to allow the cross-domain communication to be established and the operation result of the first communication server to the first administrator and the first user.

2. The method of claim 1, wherein: The specific process of step three is as follows: In step B1, the first user initiates a cross-domain communication request to the first communication server. Step B2, the first communication server verifies the identity of the first user, and after verification, the first communication server obtains the certificate of the second user marked with the latest timestamp and sends it to the first user ; Step B3: The first user receives the certificate from the second user. Then, based on the second user's public key Encrypted generation of cross-domain authentication messages and will Send to the first communication server, Include and cross-domain communication information, For containing random numbers The encrypted information, the cross-domain authentication information includes the information of the second user; Step B4, the first communication server receives Afterwards, forwarded to the second communication server; Step B5, the second communication server receives After, the certificate of the first user marked with the latest timestamp is obtained from the consortium chain , the and is sent to the second user; Step B6, the second user receives and Afterwards, from Extract and using the second user's private key Decryption The second user also from Extract the first user's public key and based on Decryption ,judge and Are they equal? ​​If == Then a cross-domain authentication message is generated. and will Send to the first communication server, Include hash value And the first user's information; if ≠ The second user then rejects the first user's cross-domain authentication request and returns a cross-domain authentication failure message; Step B7, the first communication server receives After that, it verifies its legality, if not legal, it is discarded, and the cross-domain authentication failure information is returned; if legal, it is sent to the first user; Step B8, the first user receives After that, the hash value is extracted from and it is judged whether it is equal to the hash value of If == , the cross-domain authentication between the first user and the second user is passed, and the cross-domain communication is established; if ≠ , the first user does not establish the cross-domain communication with the second user, and returns the cross-domain authentication failure information.​​ 3. The method of claim 2, wherein: The step B2 further includes that the first communication server verifies the identity of the first user, and after verification, the first communication server checks whether the second user is in a cross-domain authentication whitelist, if yes, the first communication server obtains a certificate of the second user marked with a latest time stamp from the alliance chain , and continues to judge whether the certificate content is empty, if not, the certificate content is sent to the first user, and if yes, the cross-domain authentication request initiated by the first user is rejected. If there is no certificate of the second user, the cross-domain authentication request initiated by the first user is rejected.

4. The method of claim 2, wherein: The specific content of step B3 is as follows: Step B31, the first user receives the second user's certificate After, the certificate The second user's public key is extracted ; Step B32, generate random number and encrypt with the first user's private key ;​​ Step B33, generating an authentication message || denotes a concatenation operation;​​​ Step B34, using the second user's public key encrypting obtaining ; Step B35, generating a cross-domain authentication message and sending it to the first communication server, containing and information of the second user.​ 5. The method of claim 2, wherein: The specific content of step B6 is as follows: Step B61, the second user receives and from extracts the public key of the first user from ;​ Step B62, use own private key Decrypt Get authentication message And extract From And ; Step B63, using the first user's public key decrypting obtaining determining whether is equal; if == , it indicates that the first user's identity is trusted, and the second user will accept the first user's cross-domain authentication request, and the process goes to step B64; if ≠ , it indicates that the first user's identity is not trusted, and the second user rejects the first user's cross-domain authentication request, and returns a cross-domain authentication failure message. Step B64, computing the hash value of the cross-domain authentication message and sending to the first communication server, containing and information of the first user.

6. The method of claim 2, wherein: In step B5, the second communication server receives After that, it is firstly verified whether the first user is in the cross-domain authentication whitelist, if not, it is discarded and the cross-domain authentication failure information is returned. ​ If yes, continue to verify the legality of the first user; if not legal, discard it and return cross-domain authentication failure information; if legal, get the certificate of the first user marked with the latest timestamp from the alliance chain , and judge whether the certificate content is empty, if not empty, send and to the second user; if empty, discard and return cross-domain authentication failure information.

7. An authentication system applying the method of claim 1, characterized by: The system comprises a plurality of communication servers as consensus nodes in the alliance chain, the plurality of communication servers belong to a certain domain, and each communication server has been verified and permitted by the alliance chain. Any of the communication servers corresponds to an administrator, which is used to decide whether to accept the cross-domain authentication permission application initiated by the user connected to another communication server. Cross-domain two-way authentication is performed between two users connected to two different communication servers. If the cross-domain authentication is passed, the two users establish cross-domain communication. If the cross-domain authentication is not passed, the two users do not establish cross-domain communication.

8. The system of claim 7, wherein: Any of the communication servers corresponds to an administrator, which is also used to submit a user information update application of the user connected to the communication server to the communication server, and the communication server performs an update operation on the user information.

9. The system of claim 7, wherein: Any of the communication servers corresponds to an administrator, which is also used to submit a cross-domain authentication permission revocation request between the user connected to the communication server and a specified user to the communication server, so as to revoke the cross-domain communication between the user connected to the communication server and the specified user.

Images