Cross-domain federal identity authentication method based on block chain, main chain node, branch chain node and block chain

Abstract

The invention provides a cross-domain federal identity authentication method based on a block chain, a main chain node, a branch chain node and the block chain, and the method comprises the steps: receiving an access request initiated by an entity, the request comprising an identity identifier, and the identity identifier is created by the main chain node and is globally unique; querying the validity of the identity identification from a main chain node through cross-chain communication; after the identity identification is confirmed to be valid, a smart contract is called to perform access authorization verification on the entity, and the smart contract encapsulates an access control rule of the entity; if the access authorization verification is passed, generating a resource access credential and sending the resource access credential to the entity; wherein the identity data corresponding to the identity label is stored in a storage facility associated with the current branch chain node, and the integrity of the identity label can be verified by a cryptographic certificate stored by the main chain node.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of blockchain, in particular to a cross-domain federated identity authentication method based on blockchain, a main chain node, a sub-chain node and a blockchain. BACKGROUND

[0002] With the continuous expansion of large enterprise groups and government systems, their organizational structure usually spans multiple provinces or regions. In such a cross-domain environment, how to achieve efficient, secure and compliant identity authentication and access management has become a technical problem that needs to be solved. SUMMARY

[0003] In view of the above problems, the present application provides a cross-domain federated identity authentication method based on blockchain, a main chain node, a sub-chain node and a blockchain, which at least solves one of the above problems.

[0004] According to a first aspect of the present application, a cross-domain federated identity authentication method based on blockchain is provided, the blockchain comprising a main chain node and at least one sub-chain node, comprising: receiving an access request initiated by an entity, the request comprising an identity identifier, the identity identifier being created by the main chain node and globally unique; querying the validity of the identity identifier to the main chain node through cross-chain communication; after confirming the validity of the identity identifier, calling a smart contract to verify the access authorization of the entity, wherein the smart contract encapsulates the access control rules of the entity; if the access authorization verification is passed, generating a resource access credential and sending it to the entity; wherein the identity data corresponding to the identity identifier is stored in the storage facility associated with the current sub-chain node, and the integrity of the identity identifier can be verified by the cryptographic credentials saved by the main chain node.

[0005] In some embodiments, after querying the validity of the identity identifier to the main chain node through cross-chain communication, it further comprises: receiving the permission smart contract address associated with the identity identifier returned by the main chain node; the calling a smart contract to verify the access authorization of the entity comprises: according to the permission smart contract address, calling the corresponding smart contract to verify the access authorization of the entity.

[0006] In some embodiments, the calling a smart contract to verify the access authorization of the entity comprises: receiving the zero-knowledge proof submitted by the entity, the zero-knowledge proof being used to prove that the entity satisfies the access control rules; verifying the validity of the zero-knowledge proof through the smart contract.

[0007] In some embodiments, the method further comprises: listening to a permission change event broadcasted by the main chain node through cross-chain communication; and updating the access control rules stored or accessible locally in response to the permission change event.

[0008] In some embodiments, the method further comprises: receiving a blacklist update event broadcasted by the main chain node or other sub-chain nodes through cross-chain communication; adding an identity specified in the blacklist update event to a local blacklist; and rejecting an access request when an identity in the access request is located in the local blacklist.

[0009] In some embodiments, the method further comprises: performing sequence number and timestamp checking on cross-chain communication messages to prevent replay attacks; and / or performing behavior pattern analysis on a plurality of received access requests to identify and intercept witch attacks.

[0010] According to a second aspect of the present application, a cross-domain federated identity authentication method based on a blockchain is provided, the blockchain comprising a main chain node and at least one sub-chain node, the method comprising: receiving an identity query request initiated by a sub-chain node through cross-chain communication, the request comprising an identity, the identity being created by the main chain node and globally unique; verifying the validity of the identity to obtain a verification result; returning the verification result to the sub-chain node through cross-chain communication; wherein identity data corresponding to the identity is stored in a storage facility associated with the corresponding sub-chain node, and the main chain node holds a cryptographic credential for verifying the integrity of the identity data.

[0011] According to a third aspect of the present application, a sub-chain node of a blockchain is provided, the blockchain comprising a main chain node and at least one sub-chain node, the sub-chain node comprising: a receiving module for receiving an access request initiated by an entity, the request comprising an identity, the identity being created by the main chain node and globally unique; a querying module for querying the validity of the identity to the main chain node through cross-chain communication; a calling module for calling an intelligent contract for access authorization verification of the entity after confirming the validity of the identity, wherein the intelligent contract encapsulates the access control rules of the entity; a sending module for generating a resource access credential and sending it to the entity if the access authorization verification is passed; wherein identity data corresponding to the identity is stored in a storage facility associated with the current sub-chain node, and the integrity of the identity can be verified by a cryptographic credential held by the main chain node.

[0012] According to a fourth aspect of the present application, a main chain node of a blockchain is provided, the blockchain comprising the main chain node and at least one subchain node, the main chain node comprising: a receiving module configured to receive an identity query request initiated by a subchain node through cross-chain communication, the request comprising an identity identifier, the identity identifier being created by the main chain node and globally unique; a verifying module configured to verify validity of the identity identifier to obtain a verification result; and a returning module configured to return the verification result to the subchain node through cross-chain communication; wherein identity data corresponding to the identity identifier is stored in a storage facility associated with the corresponding subchain node, and the main chain node holds a cryptographic credential used to verify integrity of the identity data.

[0013] According to a fifth aspect of the present application, a blockchain is provided, comprising a main chain node implementing the blockchain-based cross-domain federated identity authentication method according to the first aspect, and a subchain node implementing the blockchain-based cross-domain federated identity authentication method according to the second aspect. BRIEF DESCRIPTION OF DRAWINGS

[0014] The above and other objects, features and advantages of the present application will become more apparent from the following description when taken in conjunction with the accompanying drawings, in which:

[0015] Figure 1 A flowchart of a blockchain-based cross-domain federated identity authentication method according to an embodiment of the present application is schematically shown;

[0016] Figure 2 A block diagram of a subchain node of a blockchain according to an embodiment of the present application is schematically shown;

[0017] Figure 3 A block diagram of an electronic device according to an embodiment of the present application is schematically shown. DETAILED DESCRIPTION

[0018] Hereinafter, embodiments of the present application will be described with reference to the accompanying drawings. It is to be understood, however, that the description is merely illustrative of the present application, and is in no way intended to restrict the scope of the present application. Throughout the specification, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the present application. It will be apparent, however, to one skilled in the art that the present application can be practiced without these specific details. In other instances, well-known structures and functions have not been shown or described in detail in order to avoid obscuring the application.

[0019] The terms used herein are merely used to describe specific embodiments, and are not intended to limit the present application. The terms "include" and "have" and the like used herein indicate the presence of the described features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0020] All terms used herein, including technical and scientific terms, have the meanings commonly understood by one of ordinary skill in the art, unless otherwise defined. It should be noted that the terms used herein should be interpreted as having a meaning that is consistent with the context of the specification, and should not be interpreted in an idealized or overly formal way.

[0021] In the case of using expressions similar to "at least one of A, B, and C, etc.", in general, it should be interpreted as having a meaning that is consistent with the meaning that a person skilled in the art generally understands the expression (for example, "a system having at least one of A, B, and C" should include but is not limited to a system having A alone, a system having B alone, a system having C alone, a system having both A and B, a system having both A and C, a system having both B and C, and / or a system having A, B, and C, etc.).

[0022] In the technical solutions of the present disclosure, the user information (including but not limited to user personal information, user image information, user transaction record information, user equipment information, such as location information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved are information and data authorized by the user or authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of related data comply with relevant laws, regulations and standards, necessary security measures are taken, do not violate public order and good customs, and provide corresponding operation portal for user to choose authorization or refusal.

[0023] In the scenario of using personal information for automated decision-making, the method, device and system provided by the embodiments of the present disclosure all provide corresponding operation portal for the user to choose to agree or refuse the automated decision-making result; if the user chooses to refuse, the expert decision-making process is entered. The expression "automated decision-making" here refers to the activity of automatically analyzing, evaluating the behavior habits, interests and hobbies, or economic, health, credit status, etc. of a person through a computer program, and making decisions. The expression "expert decision-making" here refers to the activity of making decisions by personnel who are engaged in a certain field of work, have specialized experience, knowledge and skills, and reach a certain professional level.

[0024] Figure 1 A flowchart of a blockchain-based cross-domain federated identity authentication method according to an embodiment of the present application is schematically shown.

[0025] As Figure 1 shown, the blockchain includes one main chain node and at least one sub-chain node, and the blockchain-based cross-domain federated identity authentication method is applied to the sub-chain node, including operation S110- operation S150.

[0026] In operation S110, an access request initiated by an entity is received.

[0027] According to an embodiment of the present application, the main chain node can refer to a set of nodes that undertake the core identity registration, global verification and anchoring functions in the blockchain network. It is usually deployed and maintained by the highest management authority of the system (such as the headquarters of an enterprise), and is built based on a consortium chain framework (such as Hyperledger Fabric or FISCO BCOS).

[0028] According to an embodiment of the present application, the sub-chain node can refer to a sub-blockchain node that is logically or physically affiliated to different regions or business departments, such as a chain node deployed for a Beijing branch or a Shanghai data center.

[0029] According to an embodiment of the present application, the request contains an identity, which is created by the main chain node and globally unique. In an implementation, the identity can be a decentralized identifier (DID). DID is a new type of identifier that does not rely on a centralized registration authority. Its specific format can be did:mycompany:bj_employee_1001, where mycompany is the method name and bj_employee_1001 is the unique identity code. The DID is bound to a pair of asymmetric cryptography keys (such as public and private keys based on RSA or elliptic curve), and the public key is recorded on the chain by the main chain node, while the private key is securely kept by the user himself.

[0030] In operation S120, the validity of the identity is queried from the main chain node through cross-chain communication.

[0031] According to an embodiment of the present application, the main chain and the sub-chain can be interconnected through a cross-chain communication protocol to form a federated architecture. In specific implementation, the cross-chain communication protocol can be IBC protocol, XCM cross-chain message passing scheme or relay chain-based cross-chain technology.

[0032] In operation S130, after confirming the validity of the identity, a smart contract is called to perform access authorization verification on the entity.

[0033] According to an embodiment of the present application, the smart contract can refer to a permissioned smart contract, which is a business logic encapsulated in the form of code (such as written in Solidity or Rust language), which clearly specifies which entity with which identity can access which resource when certain conditions are met.

[0034] According to an embodiment of the present application, the specific implementation of the access authorization verification can include zero-knowledge proof-based verification and zero-knowledge proof-based verification. The zero-knowledge proof-based verification can be that an entity (through its client) submits a zero-knowledge proof to the smart contract, proving that it has access to the required attribute (such as belonging to a certain department, or having a higher level than a certain level) without revealing the plaintext of the attribute. The logic for verifying the proof is pre-installed in the smart contract (for example, by calling a verification function generated by a circuit written in the Circom framework). The attribute signature-based verification can be that the entity signs a specific message using its private key to prove that it has certain attributes, and the contract authorizes by verifying the signature.

[0035] The code and state of the permission smart contract are synchronized from the main chain node to each sub-chain node through the cross-chain protocol, ensuring the consistency of the global strategy.

[0036] In operation S140, if the access authorization verification is passed, a resource access credential is generated and sent to the entity.

[0037] According to an embodiment of the present application, the resource access credential can be a credential generated by the sub-chain node after the authorization verification is passed, which is used by the entity to directly access the target system in a short period of time.

[0038] According to an embodiment of the present application, the identity data corresponding to the identity identifier is stored in a storage facility associated with the current sub-chain node, and the integrity of the identity identifier can be verified by the cryptographic credential saved by the main chain node.

[0039] To achieve data compliance, the detailed identity data of the entity (such as name, identity card number, salary details, and other sensitive information) is not stored on the chain, but is stored in a distributed storage system associated with the geographical location or logic of the sub-chain node. For example, the distributed storage system is IPFS. For example, the data of employees in Shanghai is stored in an IPFS node cluster located in Shanghai.

[0040] In some embodiments, to ensure that the offline stored data has not been tampered with, a cryptographic hash value (such as using the SHA-256 algorithm) of the data can be calculated, and the hash value is the cryptographic credential. This hash value is anchored on the headquarters main chain node. In any case where the integrity of the data needs to be verified, the hash value of the stored data can be recalculated and compared with the credential stored on the main chain node to achieve the verification.

[0041] According to the embodiment of the present application, by performing the cross-domain federated identity authentication process based on the blockchain by the subchain node, the decentralization and localization of identity verification and authorization decision are realized, and at the same time, by storing the detailed identity data in the local storage facility associated with the subchain node and only saving the cryptographic digest thereof in the main chain, the data sovereignty compliance requirement is fundamentally met, and the single point of failure and large-scale leakage risk caused by centralized data storage are eliminated.

[0042] In some embodiments of the present application, the permission smart contract address associated with the identity identifier returned by the main chain node can be received; and according to the permission smart contract address, the corresponding smart contract is called to perform access authorization verification on the entity.

[0043] The permission smart contract address can be an identifier used to uniquely identify and access a specific smart contract in the blockchain system.

[0044] According to the embodiment of the present application, after verifying the identity validity, the subchain node does not decide which contract to use by itself, but receives an explicit and authoritative calling target from the response of the main chain node. It can be ensured that no matter how the permission policy is upgraded or the contract is redeployed, the subchain node can always obtain the currently valid contract address.

[0045] According to the embodiment of the present application, according to the address calling contract, in a specific implementation, the subchain node initiates a transaction through its blockchain client to call a specific verification function of the smart contract pointed by the address. Therefore, identity verification (main chain responsibility) and permission verification (contract responsibility) can be clearly separated, and the dynamic distribution of contract addresses by the main chain realizes the flexible update and global consistency of the permission policy, avoiding the synchronization complexity and lag risk caused by the maintenance of static contract address list by the subchain node.

[0046] In some embodiments of the present application, the zero-knowledge proof submitted by the entity can be received, and the zero-knowledge proof is used to prove that the entity satisfies the access control rule; and the validity of the zero-knowledge proof is verified by the smart contract.

[0047] The zero-knowledge proof can refer to a kind of cryptographic protocol, which allows the prover (entity) to prove to the verifier (permission smart contract) that he knows a secret or satisfies a statement (for example, “my department hash value is H”), without revealing any information about the secret or statement itself to the verifier.

[0048] In a specific implementation, the proof can be generated by the entity client using local data (such as private key, attribute value) through a specific algorithm, and can be a cryptographic data package containing the result of mathematical calculation.

[0049] For example, an entity needs to prove the access control rule (e.g. "role is finance staff") to the system, it runs the proof generation algorithm locally using its private attributes. The generated proof is submitted to the permission smart contract. The smart contract encapsulates a verification algorithm paired with the proof generation algorithm inside. The contract uses the on-chain stored verification key and the public commitment corresponding to the entity's identity (e.g. the on-chain hash of its department) to compute and verify the received proof data. If the verification passes, it outputs true, indicating that the entity indeed satisfies the access control rule without revealing its specific attributes; otherwise, it outputs false.

[0050] In some embodiments of the present application, a permission change event broadcasted by the main chain node through cross-chain communication can be listened to; and in response to the permission change event, the locally stored or accessible access control rules are updated.

[0051] The permission change event can be a kind of on-chain log actively issued by the smart contract when the state of the contract changes. When the administrator calls the update function (e.g. updateRole (address entity, string newRole)) of the contract on the headquarters main chain node, the function will automatically trigger an event after successful execution, and the event contains the key information of the change, such as the target identity, the new role permission, and a timestamp.

[0052] The listening mechanism can be a cross-chain communication relay or event listener program run by each branch chain node. The program can continuously subscribe to the event log of a specific permission contract on the main chain node. Once the permission change event is captured, the relay will broadcast the event as a message to all related branch chain nodes through the reliable channel of the cross-chain communication protocol.

[0053] Updating the locally stored or accessible access control rules can be that after receiving the broadcast, the local permission policy execution component of the branch chain node will immediately act. There can be two implementation ways. Way one (contract state synchronization): directly update the permission contract state maintained locally by the branch chain, which is a mirror of the main chain contract. Way two (strategy cache update): update a high-speed strategy cache located in the memory or local database of the branch chain node.

[0054] This mechanism can ensure that any permission adjustment (e.g. employee resignation, job transfer) initiated on the headquarters main chain can be automatically synchronized to all branch chain nodes in the country within seconds or even milliseconds without manual intervention, fundamentally solving the security risk of permission recovery lag.

[0055] In some embodiments of the application, a blacklist update event broadcasted by the main chain node or other sub-chain nodes can be received through cross-chain communication; the identity specified in the blacklist update event can be added to the local blacklist; when the identity in the received access request is in the local blacklist, the access request can be rejected.

[0056] The blacklist update event can be a high-priority on-chain security announcement, similar in structure to the authority change event, which can be used to identify identities confirmed as malicious or high-risk. The event is usually issued by a risk control smart contract deployed on the main chain or any sub-chain node with risk control functions. The conditions that trigger the event can include but are not limited to: detection of abnormal device fingerprint, frequent biological authentication failure, or more than 3 login failures of the same DID within 5 minutes, etc. specific risk control rules.

[0057] In some embodiments of the application, sequence number and timestamp verification can be performed on cross-chain communication messages to prevent replay attacks; and / or behavior pattern analysis can be performed on multiple received access requests to identify and intercept witch attacks.

[0058] It can be understood that each cross-chain communication message issued by the main chain node or the sub-chain node must contain two key fields: a globally unique and increasing sequence number, and a Unix timestamp when the message is generated.

[0059] The receiving node (such as the sub-chain node when receiving the DID verification result of the main chain) can perform uniqueness verification before processing the message, checking whether the sequence number in the message is greater than the sequence number of the last valid message from the same sender recorded by the node. If it is not increasing, it is determined to be an old message replay and is rejected.

[0060] Machine learning models or pre-set rule engines (such as: more than 50 different DID requests initiated by the same IP within 1 second) can be used to analyze the above behavior data in real time. Once an abnormal pattern consistent with a witch attack is identified (i.e. a large number of seemingly independent requests are actually controlled by a single or small number of attackers), a security fuse mechanism can be automatically triggered. The mechanism can immediately freeze the access rights of the suspicious DID account and report the event, and can also link the blacklist synchronization mechanism of claim 5 to quickly isolate the threat.

[0061] The embodiments of the present disclosure further provide a cross-domain federated identity authentication method based on a blockchain, the blockchain comprising one main chain node and at least one sub-chain node, the cross-domain federated identity authentication method based on the blockchain being applied to the main chain node, and the method comprising the following steps: receiving an identity query request initiated by a sub-chain node through cross-chain communication, the request comprising an identity, the identity being created by the main chain node and globally unique; verifying validity of the identity to obtain a verification result; and returning the verification result to the sub-chain node through cross-chain communication; wherein identity data corresponding to the identity is stored in a storage facility associated with the corresponding sub-chain node, and the main chain node holds a cryptographic credential for verifying integrity of the identity data.

[0062] Based on the cross-domain federated identity authentication method based on the blockchain, the present disclosure further provides a sub-chain node of the blockchain. The following will be described in detail in combination with Figure 2 The device is described in detail.

[0063] Figure 2 The structure block diagram of the sub-chain node of the blockchain according to the embodiments of the present disclosure is schematically shown.

[0064] As Figure 2 shown, the sub-chain node of the blockchain of the embodiments comprises a receiving module 210, a querying module 220, a calling module 230 and a sending module 240.

[0065] The receiving module 210 is configured to receive an access request initiated by an entity, the request comprising an identity, the identity being created by the main chain node and globally unique. In an embodiment, the receiving module 210 can be configured to perform the operation S110 described above, and details are not repeated here.

[0066] The querying module 220 is configured to query the main chain node for validity of the identity through cross-chain communication. In an embodiment, the querying module 220 can be configured to perform the operation S120 described above, and details are not repeated here.

[0067] The calling module 230 is configured to, after confirming that the identity is valid, call a smart contract to perform access authorization verification on the entity, wherein the smart contract encapsulates access control rules of the entity. In an embodiment, the calling module 230 can be configured to perform the operation S130 described above, and details are not repeated here.

[0068] The sending module 240 is configured to, if the access authorization verification is passed, generate a resource access credential and send it to the entity. In an embodiment, the sending module 240 can be configured to perform the operation S140 described above, and details are not repeated here.

[0069] In some embodiments, after querying the main chain node for validity of the identity identifier through cross-chain communication, the method further includes: receiving an authority smart contract address associated with the identity identifier returned by the main chain node; and calling the smart contract to perform access authorization verification on the entity includes: calling a corresponding smart contract to perform access authorization verification on the entity according to the authority smart contract address.

[0070] In some embodiments, calling the smart contract to perform access authorization verification on the entity includes: receiving zero-knowledge proof submitted by the entity, the zero-knowledge proof being used to prove that the entity satisfies the access control rule; and verifying validity of the zero-knowledge proof through the smart contract.

[0071] In some embodiments, the method further includes: listening to a permission change event broadcast by the main chain node through cross-chain communication; and updating the access control rule stored or accessible locally in response to the permission change event.

[0072] In some embodiments, the method further includes: receiving a blacklist update event broadcast by the main chain node or other sub-chain nodes through cross-chain communication; adding an identity identifier specified in the blacklist update event to a local blacklist; and rejecting an access request when an identity identifier in the access request is located in the local blacklist.

[0073] In some embodiments, the method further includes: performing sequence number and timestamp checking on cross-chain communication messages to prevent replay attacks; and / or performing behavior pattern analysis on a plurality of received access requests to identify and intercept Sybil attacks.

[0074] Embodiments of the present disclosure also provide a main chain node of a blockchain, including: a receiving module configured to receive an identity query request initiated by a sub-chain node through cross-chain communication, the request containing an identity identifier, the identity identifier being created by the main chain node and globally unique; a verification module configured to verify validity of the identity identifier to obtain a verification result; and a returning module configured to return the verification result to the sub-chain node through cross-chain communication; wherein identity data corresponding to the identity identifier is stored in a storage facility associated with a corresponding sub-chain node, and the main chain node holds a cryptographic credential used to verify integrity of the identity data.

[0075] Embodiments of the present disclosure also provide a blockchain, including the main chain node of the blockchain-based cross-domain federated identity authentication method described above, and the sub-chain node of the blockchain-based cross-domain federated identity authentication method described above.

[0076] According to an embodiment of the present application, any of the receiving module 210, the querying module 220, the calling module 230, and the sending module 240 can be combined in one module, or any of them can be split into multiple modules. Alternatively, at least part of the function of one or more of these modules can be combined with at least part of the function of the other modules, and implemented in one module. According to an embodiment of the present application, at least one of the receiving module 210, the querying module 220, the calling module 230, and the sending module 240 can be at least partially implemented as a hardware circuit, such as a field programmable gate array (FPGA), a programmable logic array (PLA), a system on chip, a system on board, a system on package, an application specific integrated circuit (ASIC), or any other reasonable way of integrating or packaging a circuit, etc. or implemented by hardware or firmware, or implemented in any one of software, hardware and firmware or in a proper combination of any of them. Alternatively, at least one of the receiving module 210, the querying module 220, the calling module 230, and the sending module 240 can be at least partially implemented as a computer program module which, when executed, can perform the corresponding function.

[0077] Figure 3 A block diagram of an electronic device adapted to implement the cross-domain federated identity authentication method based on blockchain according to an embodiment of the present application is schematically shown.

[0078] As shown in Figure 3 An electronic device according to an embodiment of the present application includes a processor 401 which can perform various appropriate actions and processes according to a program stored in a read only memory (ROM) 402 or a program loaded from a storage portion 408 into a random access memory (RAM) 403. The processor 401 can include, for example, a general purpose microprocessor (such as a CPU), an instruction set processor, and / or a related chipset, and / or a special purpose microprocessor (such as an application specific integrated circuit (ASIC)), etc. The processor 401 can also include an on-board memory for cache use. The processor 401 can include a single processing unit or multiple processing units for performing different actions of the method processes according to an embodiment of the present application.

[0079] In the RAM 403, various programs and data required for the operation of the electronic device are stored. The processor 401, the ROM 402, and the RAM 403 are connected to each other via the bus 404. The processor 401 performs various operations of the method flow according to the embodiments of the present application by executing the programs in the ROM 402 and / or the RAM 403. It should be noted that the programs can also be stored in one or more memories other than the ROM 402 and the RAM 403. The processor 401 can also perform various operations of the method flow according to the embodiments of the present application by executing the programs stored in the one or more memories.

[0080] According to the embodiments of the present application, the electronic device can further include an input / output (I / O) interface 405, which is also connected to the bus 404. The electronic device can further include one or more of the following components connected to the input / output (I / O) interface 405: an input part 406 including a keyboard, a mouse, etc.; an output part 407 including a display such as a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage part 408 including a hard disk, etc.; and a communication part 409 including a network interface card such as a LAN card, a modem, etc. The communication part 409 performs communication processing via a network such as the Internet. A drive 410 is also connected to the input / output (I / O) interface 405 as necessary. A removable medium 411 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc. is mounted on the drive 410 as necessary, so that a computer program read therefrom is installed in the storage part 408 as necessary.

[0081] The present application also provides a computer readable storage medium, which can be included in the device / apparatus / system described in the above embodiments; or can exist separately without being assembled into the device / apparatus / system. The above computer readable storage medium carries one or more programs, when the one or more programs are executed, the method according to the embodiments of the present application is implemented.

[0082] According to embodiments of the present application, the computer readable storage medium can be a non-transitory computer readable storage medium, for example, can include, but is not limited to, 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), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present application, a computer readable storage medium can be any tangible medium that contains or stores a program, which can be used by or in connection with an instruction execution system, apparatus, or device. For example, according to embodiments of the present application, the computer readable storage medium can include one or more memories of the ROM 402 and / or the RAM 403 described above and / or one or more memories other than the ROM 402 and the RAM 403.

[0083] Embodiments of the present application also include a computer program product, which includes a computer program containing program codes for executing the methods shown in the flowcharts. When the computer program product is run in a computer system, the program codes are used to make the computer system implement the blockchain-based cross-domain federated identity authentication method provided by the embodiments of the present application.

[0084] The above-described functions defined in the system / device / apparatus of the embodiments of the present application are performed when the computer program is executed by the processor 401. According to embodiments of the present application, the system, device, module, unit, etc. described above can be implemented by computer program modules.

[0085] In one embodiment, the computer program can rely on tangible storage media such as optical storage media, magnetic storage media, etc. In another embodiment, the computer program can also be transmitted, distributed, and downloaded in the form of a signal on a network medium, and be downloaded and installed through the communication part 409, and / or installed from the detachable medium 411. The program codes contained in the computer program can be transmitted by any suitable network medium, including but not limited to wireless, wired, etc., or any suitable combination of the foregoing.

[0086] In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 409, and / or installed from the detachable medium 411. When the computer program is executed by the processor 401, the above-described functions defined in the system of the embodiments of the present application are performed. According to embodiments of the present application, the system, device, apparatus, module, unit, etc. described above can be implemented by computer program modules.

[0087] According to an embodiment of the present application, program code for implementing the computer programs provided by embodiments of the present application can be written in any combination of one or more programming languages, and specifically, can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages include, but are not limited to, Java, C++, python, "C" language, or similar programming languages. Program code can execute entirely on a user's computing device, partly on a user's device, partly on a remote computing device, or entirely on a remote computing device or server. In the latter scenario, the remote computing device can be connected to the user's computing device through any kind of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computing device, such as through the Internet using an Internet Service Provider.

[0088] The flow diagrams and the block diagrams in the drawings are illustrations of architectures, functionalities, and operations of possible implementations 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 procedure, or a part of code, which comprises one or more executable instructions for implementing the specified logical functions. 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 in the reverse order, depending on the functionality involved. It is also noted that each block in the block diagrams or flow diagrams, and combinations of blocks in the block diagrams or flow diagrams, can be implemented by dedicated hardware-based systems that perform the specified functions or operations, or by combinations of dedicated hardware and computer instructions.

[0089] Those skilled in the art will understand that features recited in the various embodiments of the present application can be combined and / or integrated in a variety of ways, even if such combinations or integrations are not expressly noted in the present application. In particular, features recited in the various embodiments of the present application can be combined and / or integrated in a variety of ways without departing from the spirit and teachings of the present application. All such combinations and / or integrations are within the scope of the present application.

Claims

1. A blockchain-based cross-domain federated identity authentication method, characterized in that, The blockchain comprises a main chain node and at least one subchain node, comprising: receiving an access request initiated by an entity, the request comprising an identity, the identity being created by the main chain node and globally unique; querying the validity of the identity to the main chain node through cross-chain communication; after confirming the validity of the identity, calling a smart contract to verify the access authorization of the entity, wherein the smart contract encapsulates the access control rules of the entity; if the access authorization verification is passed, generating a resource access credential and sending it to the entity; wherein the identity data corresponding to the identity is stored in the storage facility associated with the current subchain node, and the integrity of the identity can be verified by the cryptographic credentials saved by the main chain node.

2. The method of claim 1, wherein, After querying the validity of the identity to the main chain node through cross-chain communication, further comprising: receiving the permission smart contract address associated with the identity returned by the main chain node; the calling a smart contract to verify the access authorization of the entity comprises: according to the permission smart contract address, calling the corresponding smart contract to verify the access authorization of the entity.

3. The method according to claim 1 or 2, characterized in that, The calling a smart contract to verify the access authorization of the entity comprises: receiving zero-knowledge proof submitted by the entity, the zero-knowledge proof being used to prove that the entity satisfies the access control rules; verifying the validity of the zero-knowledge proof through the smart contract.

4. The method of claim 1, wherein, The method further comprises: listening to the permission change event broadcast by the main chain node through cross-chain communication; in response to the permission change event, updating the access control rules stored or accessible locally.

5. The method of claim 1, wherein, The method further comprises: receiving a blacklist update event broadcast by the main chain node or other subchain nodes through cross-chain communication; adding the identity specified in the blacklist update event to the local blacklist; when the identity in the received access request is in the local blacklist, rejecting the access request.

6. The method of claim 1, wherein, The method further comprises: sequence number and timestamp checking on cross-chain communication messages to prevent replay attacks; and / or, behavioral pattern analysis on multiple received access requests to identify and intercept witch attacks. 7.A blockchain-based cross-domain federated identity authentication method, characterized in that, The blockchain comprises a main chain node and at least one subchain node, comprising: receiving an identity query request initiated by a subchain node through cross-chain communication, the request comprising an identity, the identity being created by the main chain node and globally unique; verifying the validity of the identity to obtain a verification result; returning the verification result to the subchain node through cross-chain communication; wherein the identity data corresponding to the identity is stored in the storage facility associated with the corresponding subchain node, and the main chain node saves the cryptographic credentials for verifying the integrity of the identity data. 8.A subchain node of a blockchain, characterized in that, The blockchain comprises a main chain node and at least one subchain node, the subchain node comprising: a receiving module for receiving an access request initiated by an entity, the request comprising an identity, the identity being created by the main chain node and globally unique; The query module is configured to query the validity of the identity identifier through cross-chain communication to the main chain node; The calling module is configured to call a smart contract to perform access authorization verification on the entity after confirming that the identity identifier is valid, wherein the smart contract encapsulates access control rules of the entity; The sending module is configured to generate a resource access credential and send it to the entity if the access authorization verification is passed. Identity data corresponding to the identity identifier is stored in a storage facility associated with the current sub-chain node, and the integrity of the identity identifier can be verified by a cryptographic credential saved by the main chain node. 9.A main chain node of a blockchain, characterized in that, The blockchain includes the main chain node and at least one sub-chain node, and the main chain node includes: The receiving module is configured to receive an identity query request initiated by a sub-chain node through cross-chain communication, the request including an identity identifier, the identity identifier being created by the main chain node and globally unique; The verification module is configured to verify the validity of the identity identifier to obtain a verification result; The returning module is configured to return the verification result to the sub-chain node through cross-chain communication; Identity data corresponding to the identity identifier is stored in a storage facility associated with the corresponding sub-chain node, and the main chain node saves a cryptographic credential for verifying the integrity of the identity data.

10. A blockchain, characterized in that, The main chain node includes the main chain node and at least one sub-chain node, and the main chain node includes: The receiving module is configured to receive an identity query request initiated by a sub-chain node through cross-chain communication, the request including an identity identifier, the identity identifier being created by the main chain node and globally unique; The verification module is configured to verify the validity of the identity identifier to obtain a verification result; The returning module is configured to return the verification result to the sub-chain node through cross-chain communication; Identity data corresponding to the identity identifier is stored in a storage facility associated with the corresponding sub-chain node, and the main chain node saves a cryptographic credential for verifying the integrity of the identity data. The main chain node includes the main chain node and at least one sub-chain node, and the main chain node includes: The receiving module is configured to receive an identity query request initiated by a sub-chain node through cross-chain communication, the request including an identity identifier, the identity identifier being created by the main chain node and globally unique; The verification module is configured to verify the validity of the identity identifier to obtain a verification result; The returning module is configured to return the verification result to the sub-chain node through cross-chain communication; Identity data corresponding to the identity identifier is stored in a storage facility associated with the corresponding sub-chain node, and the main chain node saves a cryptographic credential for verifying the integrity of the identity data.

Images