A method and system for trusted access control compatible with XACML standard

Abstract

The application discloses a kind of compatible XACML standard's trusted access control method and system, belong to access control technical field, the trusted access control method conforms to the XACML standard popular in industry, adopts the policy decision point of decentralization realized by block chain technology, eliminates the mutual distrust between different organizations, guarantee the trusted of access request verification result, to realize the trusted access across organization;With the access control function conforms to the XACML standard popular in industry, the specific implementation can reuse XACML policy decision point, policy enforcement point related open source code, and the deployment access control function is low in cost;Block chain is based on the read-write separation characteristics of XACML policy decision point, with low redundancy parallel execution request verification task, make full use of the computing capacity of block chain node, reduce the request verification overhead, improve the block chain throughput.

Description

Technical Field

[0001] This invention belongs to the field of access control technology, and more specifically, relates to a trusted access control method and system compatible with the XACML standard. Background Technology

[0002] Attribute-Based Access Control (ABAC) strikes a balance between policy expressiveness and storage efficiency, and is therefore increasingly widely used. Extensible Access Control Markup Language (XACML) defines the form of access control policies / requests and validation rules, and has become the de facto standard for ABAC.

[0003] Traditional XACML architectures have all component nodes belonging to a single organization, limiting their use to internal access control. Blockchain technology can be used to build decentralized XACML architectures, enabling trusted access control for user and data interactions across organizations. However, existing architectures combining blockchain and XACML do not fully consider the characteristics of both, including the full replication of blockchain leading to significant redundant computations and the complex and time-consuming verification process of XACML policy decision points. These limitations restrict the throughput of blockchain-verified access requests, hindering practical applications. Summary of the Invention

[0004] To address the aforementioned deficiencies or improvement needs of existing technologies, this invention provides a trusted access control method and system compatible with the XACML standard. Its purpose is to utilize blockchain technology to achieve decentralized policy decision points, eliminating mutual distrust between different organizations and ensuring the trustworthiness of access request verification results. The blockchain performs low-redundancy parallel execution of request verification tasks, fully utilizing the computing power of blockchain nodes. This solves the technical problems of existing XACML being difficult to apply to cross-organizational trusted access control and the limited throughput of blockchain when running XACML policy decision points.

[0005] To achieve the above objectives, according to one aspect of the present invention, a trusted access control method compatible with the XACML standard is provided, comprising:

[0006] S1: Data-owning users use the policy management point of their first organization to decide on blockchain deployment or deletion access policies;

[0007] S2: The data access user sends an access request to the policy-determining blockchain through the policy enforcement point of their second organization;

[0008] The strategy determines that the blockchain adopts a sorting-execution separation architecture, and each blockchain node includes a sorting node and an execution node; the sorting node is used to record policy update operations and access requests; the execution node accepts the policy update operations and access requests delivered by the sorting node to maintain the access control policy set and verify access requests.

[0009] S3: The strategy determines that the blockchain operates with low redundancy and sends the verification result to the strategy execution points of the first and second organizations after verifying the access request;

[0010] S4: After receiving the reply, the policy enforcement point of the first organization forwards the verification result to the data owner user; after receiving the reply, the policy enforcement point of the second organization forwards the verification result to the data access user, so that the data access user can achieve cross-organizational access with the permission of the data owner user.

[0011] In one embodiment, the execution node receives policy update operations and access requests delivered by the sorting node to maintain the access control policy set and verify access requests, including:

[0012] For each policy update operation, the execution node updates the set of access control policies cached at its own policy decision point and saves a copy of the update operation;

[0013] For each data access request, the execution node invokes the policy decision point function to verify the access request and obtain the result;

[0014] When the execution node verifies the access request contained in the current block as a priority node, it calls the policy decision point to verify the current access control policy set. After the access request is verified, it sends the verification result to the policy execution points of the first organization and the second organization, and also sends a response message that references the access request and contains a summary of the execution result to all sorting nodes.

[0015] When the execution node verifies an access request not contained in the current block as an additional node, it rolls back its own state to the corresponding block based on the current access control policy set and the saved update operation, then verifies the access request again. After verification, it cancels the rollback. After the access request is verified, it sends a reply to the policy execution points of the first organization and the second organization.

[0016] When the blockchain system experiences bandwidth constraints, the execution node uses a message compression method to reduce the number of response messages that need to be sent, thereby saving communication resources.

[0017] In one embodiment, the execution node uses a message compression method, including:

[0018] The sorting node will batch the access requests and allocate execution nodes at the batch level.

[0019] After verifying all access requests within a batch, the execution node generates a Merkle tree based on a list of all results; the execution node only needs to send one response message for all requests in the current batch, and the message contains the root value of the Merkle tree;

[0020] The response sent by the execution node to the policy execution point includes the request verification result, the Merkle tree root value, and the Merkle proof that the verification result belongs to the Merkle tree.

[0021] In one embodiment,

[0022] Each access request is verified by a subset of the priority execution nodes;

[0023] If the priority execution node fails to successfully complete the access request verification, the sorting node will assign an additional execution node for verification.

[0024] Different execution nodes can simultaneously verify multiple access requests in parallel.

[0025] In one embodiment, the sorting node reallocates additional execution node verification, including:

[0026] The sorting node tracks each submitted access request. If the tracked access request receives f+1 consistent response messages within a finite time, the access request is marked as completed in subsequent blocks; otherwise, f additional execution nodes are allocated to the access request. The corresponding allocation strategy comprehensively considers the blockchain node status to achieve load balancing of execution nodes; f represents the maximum number of potentially faulty nodes. When the total number of blockchain nodes is N, the following condition is met:

[0027] When the sorting node verifies a block, it considers an access request marked as having finished execution to be valid only if it has received f+1 consistent responses. The block is valid only if all access requests marked as having finished execution within the block are valid. The sorting node then votes on valid blocks to continue consensus.

[0028] When the sorting node submits an access request marked as completed, it sends a reply containing a summary of the execution results to the policy execution points of the first organization and the second organization.

[0029] In one embodiment, the corresponding allocation strategy comprehensively considers the blockchain node status to achieve load balancing of execution nodes, including:

[0030] The sorting node records all transactions executed by all execution nodes;

[0031] When the sorting node assigns a priority execution node to an access request, it counts the total number of requests executed by each execution node to date, sorts them in ascending order, finds the f least idle nodes, and assigns them to the request.

[0032] When the sorting node allocates additional execution nodes for a timeout request, it finds the f most idle nodes besides the priority execution nodes before this access request and allocates them to the request.

[0033] In one embodiment, when the total number of blockchain nodes is N, it can tolerate One potentially faulty node.

[0034] According to another aspect of the present invention, a trusted access control system compatible with the XACML standard is provided, comprising: a data ownership user terminal, a data access user terminal, and a policy decision blockchain terminal;

[0035] The data owner's terminal is used to determine the blockchain deployment or deletion access policy based on the input instructions of the data owner's user and with the help of the policy management point of the first organization to which it belongs;

[0036] The data access user terminal is used to send an access request to the policy decision blockchain through the policy execution point of the second organization to which the data access user belongs, based on the input instructions of the data access user.

[0037] The strategy determines the blockchain architecture, which adopts a sorting-execution separation architecture. Each blockchain node includes a sorting node and an execution node. The sorting node records policy update operations and access requests. The execution node receives the policy update operations and access requests delivered by the sorting node to maintain the access control policy set and verify the access requests. The strategy determines the blockchain to operate with low redundancy and, after verifying the access request, sends the verification result to the policy execution points of the first and second organizations. After receiving the reply, the policy execution point of the first organization forwards the verification result to the data owner user via the data owner user terminal. After receiving the reply, the policy execution point of the second organization transmits the verification result to the data access user via the data access user terminal, so that the data access user can achieve cross-organizational access with the permission of the data owner user.

[0038] In summary, compared with the prior art, the above-described technical solutions conceived by this invention can achieve the following beneficial effects:

[0039] (1) This invention provides a trusted access control method compatible with the XACML standard. It employs blockchain technology to implement decentralized policy decision points, eliminating mutual distrust between different organizations and ensuring the reliability of access request verification results, thereby achieving trusted access across organizations. The access control function conforms to the industry-standard XACML, and its implementation reuses relevant open-source code for XACML policy decision points and policy execution points, resulting in low deployment costs. Furthermore, the blockchain, based on the read-write separation characteristic of XACML policy decision points, executes request verification tasks in parallel with low redundancy, fully utilizing the computing power of blockchain nodes, reducing request verification overhead, and improving blockchain throughput.

[0040] (2) This solution provides a method for maintaining access control policy sets and verifying access requests. By using the location of the access request in the block and the policy set rollback method, the access control policy set on which the request depends can be located, and the execution node can verify the correctness of the access request according to the access control policy set.

[0041] (3) This solution provides a method for using execution node message compression, which reduces the number of response messages that need to be sent, thereby reducing the communication and computing overhead of the blockchain, further improving the performance of the blockchain, and realizing faster cross-organizational access control.

[0042] (4) This solution provides a low-redundancy operation method for blockchain. By allocating access requests to some priority execution nodes instead of all blockchain nodes, it is possible to verify requests with low redundancy and realize parallel verification of different requests on different nodes.

[0043] (5) This scheme provides an additional execution node allocation scheme. By sending response messages to the sorting node through the execution node, the sorting node can track the execution results of the priority execution node and realize the necessary additional node reallocation.

[0044] (6) The node load balancing method proposed in this invention distributes the task of verifying access requests as evenly as possible to all blockchain nodes, thereby avoiding slowing down the entire system due to the heavy task of a single node, thus further improving the performance of the blockchain and realizing faster cross-organizational access control. Attached Figure Description

[0045] Figure 1 A flowchart of a trusted access control method compatible with the XACML standard provided in an embodiment of the present invention.

[0046] Figure 2 This is a diagram illustrating the user update strategy and cross-organizational access process in one embodiment of the present invention.

[0047] Figure 3This is a diagram showing the state changes of blockchain processing access requests in one embodiment of the present invention.

[0048] Figure 4 This is a diagram illustrating the process of a blockchain client receiving a response and extracting results in one embodiment of the present invention. Detailed Implementation

[0049] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. Furthermore, the technical features involved in the various embodiments of this invention described below can be combined with each other as long as they do not conflict with each other.

[0050] This invention provides a trusted access control method compatible with the XACML standard, such as... Figure 1 , Figure 2 As shown, it includes the following steps:

[0051] S1: Data-owning users use the policy management point of their first organization to decide on blockchain deployment or deletion access policies;

[0052] S2: Data access users send access requests to the policy-determining blockchain through the policy enforcement point of their respective second organization;

[0053] S3: The strategy determines that the blockchain should operate with low redundancy and, after verifying the access request, send the verification result to the strategy execution points of the first and second organizations.

[0054] S4: After receiving the reply, the policy enforcement point of the first organization forwards the verification result to the data owner user; after receiving the reply, the policy enforcement point of the second organization forwards the verification result to the data access user, so that the data access user can achieve cross-organizational access with the permission of the data owner user.

[0055] Specifically, S1 includes:

[0056] S11. The user sends the operation in its original format, such as a comma-separated string "update policy, add, policy content", to the policy management point of the first organization.

[0057] S12. After receiving a user's access policy update operation, if the policy management point is adding a policy, it translates it into an XACML format policy and stores it locally. Then, it sends the operation and policy to the policy decision blockchain. If it is deleting a policy, it sends the operation directly to the blockchain without translation.

[0058] Specifically, S2 includes:

[0059] S21. The data access user will send the request in its original format, such as the string "access request, data identifier", to the policy management point of the second organization.

[0060] S22. Upon receiving a user's access request, the policy enforcement point translates it into an XACML format request. During this process, the policy enforcement point populates the request with attribute values, including user, resource, behavior, and environment attributes. When one or more attribute values ​​are missing locally, the policy enforcement point queries policy information points from multiple relevant organizations, and populates the missing values ​​after receiving the returned results. To ensure the trustworthiness of the attribute values, the policy information points attach a digital signature or message authentication code to the returned attribute values.

[0061] After the S23 and XACML format requests are generated, the policy execution point is sent to the policy decision blockchain.

[0062] Specifically, S3 includes: the strategy determines that the blockchain adopts a low-redundancy operation method, and after verifying the request, sends the result to the strategy execution points of the first and second organizations.

[0063] The strategy determines that the blockchain uses a low-redundancy operation method to verify requests, including:

[0064] All organizations jointly maintain a permissioned blockchain to serve as the policy decision point; this is called the policy decision blockchain. Let N be the number of organizations, then the number of blockchain nodes is also N.

[0065] The policy management point and policy execution point act as user agents, running the blockchain client protocol, broadcasting requests to the policy decision blockchain nodes, and retrieving the results upon receiving a blockchain response. The policy decision blockchain only interacts with the policy management points and policy execution points of each organization; therefore, only two types of operations exist in the block: policy update operations and access requests.

[0066] The blockchain adopts a sorting-execution separation architecture, where each blockchain node is divided into a sorting node and an execution node.

[0067] All sorting nodes run a Byzantine fault-tolerant consensus protocol to record policy update operations and access requests, and submit them to the execution nodes for further processing. The blockchain can tolerate no more than [a certain number of] [faults]. The system maintains state consistency by considering potential Byzantine nodes. Execution nodes accept operations and requests submitted by sorting nodes to maintain the policy decision point policy set and verification requests. Each request is verified by only f+1 priority execution nodes. If low-redundancy verification fails, another f additional execution nodes will be assigned to verify it; different requests can be verified simultaneously on different execution nodes in the blockchain system.

[0068] In one embodiment, the blockchain execution node operation method includes:

[0069] For any operation, verify the digital signature or message verification code it contains. If it is invalid, discard the operation; otherwise, continue with the following process.

[0070] For each policy update operation, the execution node updates the cached policy set at its own policy decision point and saves a copy of the update operation;

[0071] For each data access request, the execution node calls the policy decision point function to verify the request and obtain the result res. When the execution node is the priority node to verify the access request contained in the current block, it directly calls the policy decision point to verify according to the current policy set; when the execution node is the additional node to verify the request contained in an earlier block, it rolls back its own state to the corresponding block based on the current policy set and the saved update operations, then verifies the request, and cancels the rollback after verification.

[0072] After the request is verified, a response is sent to the client in the following format:<REPLY,hash(res),res> Furthermore, if it is a priority execution node, it also needs to send a response message to all sorting nodes, referencing the request and containing a summary of the execution results, in the form of...<ECHO,hash(res)> When bandwidth is limited in a blockchain system, message compression technology can be used to reduce the number of response messages that need to be sent, thus saving communication resources.

[0073] In one embodiment, the blockchain sorting node operation method includes:

[0074] After the ordering node executes the consensus protocol and submits a block, it processes each request within that block. For example... Figure 3 As shown, access requests are divided into four states: unsorted, sorted, responded to, and re-executed.

[0075] All access requests sent by clients to the blockchain are unordered. Once a block is committed through the consensus process, all requests contained within it become ordered. The ordering nodes start a timer for each ordered request. If a tracked access request receives f+1 response messages referencing the request and with the same digest before the timer expires, the ordering node marks the request as responded in a subsequent block; otherwise, the ordering node marks it as needing further execution and allocates f additional execution nodes for the request in a subsequent block. The specific allocation strategy can take into account the execution node situation to achieve load balancing.

[0076] When the ordering node verifies the legality of a block, it considers a request marked as responded to be valid only if it has received f+1 consistent responses. The block is valid only if all requests marked as responded to within the block are valid. The ordering node then continues the consensus process for the valid block. Otherwise, the current consensus ends, triggering a view change in the consensus protocol and replacing the ordering leader node.

[0077] When a sorting node submits a request marked as responded, it sends a reply to the user in the form of...<REPLY,hash(res)> This includes the hash value of the execution result res, hash(res).

[0078] In one embodiment, the method for performing node message compression specifically includes:

[0079] The sorting node divides access requests into batches, with a fixed number of requests in each batch, such as 8, 16, 32, etc., and allocates execution nodes at the batch level.

[0080] After the execution node verifies all access requests within a batch, it generates a Merkle tree from the list of all results to obtain the root value of the Merkle tree. The execution node only needs to send one response message for all requests within the batch, and the message contains the root value mrB.

[0081] The response format sent by the execution node to the policy execution point client is as follows:<REPLY,hash(res),res,mrB,proof> It includes the request verification result res, the Merkle tree root mrB, and the Merkle proof proof indicating that the result belongs to the Merkle tree.

[0082] Furthermore, when the execution node uses the message compression method, the sorting node sends a reply to the user in the following form:<REPLY,mrB> That is, hash(res) is replaced with mrB.

[0083] In one embodiment, the node load balancing method specifically includes:

[0084] The sorting node records all transactions executed by all execution nodes in the system, and its specific value is updated each time a block is committed.

[0085] When a sorting node creates a block, it assigns execution nodes to access requests. First, it counts the total number of requests executed by each execution node to date, then sorts them in ascending order and identifies the f least busy nodes, assigning them to the request. Furthermore, if additional execution nodes are assigned to timed-out requests, the priority execution nodes preceding that request must be skipped.

[0086] In one embodiment, the sorting node is reassigned to additional execution node verification, including:

[0087] The sorting node tracks each submitted access request. If the tracked access request receives f+1 consistent response messages within a finite time, the access request in the subsequent block is marked as completed. Otherwise, f additional execution nodes are allocated to the access request. The corresponding allocation strategy takes into account the state of the blockchain nodes to achieve load balancing of the execution nodes. f represents the maximum number of potentially faulty nodes.

[0088] When the sorting node verifies a block, it considers an access request marked as having finished execution to be valid only if it has received f+1 consistent responses. The block is valid only if all access requests marked as having finished execution within the block are valid. The sorting node then votes on valid blocks to continue the consensus process.

[0089] When a sorting node submits an access request marked as completed, it sends a reply containing a summary of the execution results to the policy enforcement points of the first and second organizations.

[0090] Specifically, S4 includes: after receiving a response, the policy execution point extracts the result and forwards it to the user, and the user completes cross-organizational access based on the result.

[0091] The blockchain client extracts the results after receiving the response, including:

[0092] like Figure 4 As shown, after receiving responses from 2f+1 blockchain nodes, the client begins retrieving the results. First, it checks if the contained mrB values ​​are consistent. Second, it checks if the Merkle proof in responses containing non-null results is correct. Finally, it obtains the result, which is the verification result of the access request.

[0093] Taking a verification result of "access allowed" as an example, the remaining steps of S4 specifically include:

[0094] S41. The first organizational policy execution point sends a notification to the data owner user, announcing the upcoming access request;

[0095] S42. The second organizational policy enforcement point sends a notification to the data access user that their request has been verified.

[0096] S43. The data access user requests access from the data owner;

[0097] S44. The data owner grants access to the data and sends the data to the data access user.

[0098] This invention also provides a trusted access control system compatible with the XACML standard, comprising: a data ownership user terminal, a data access user terminal, and a policy decision blockchain terminal;

[0099] The data-owning user terminal is used to determine the blockchain deployment or deletion access policy based on the input instructions of the data-owning user and with the help of the policy management point of the first organization to which it belongs;

[0100] The data access user terminal is used to send access requests to the policy-determining blockchain through the policy execution point of the second organization to which the data access user belongs, based on the input instructions of the data access user.

[0101] The policy-determining blockchain adopts a sorting-execution separation architecture, with each blockchain node including a sorting node and an execution node. The sorting node records policy update operations and access requests. The execution node receives policy update operations and access requests from the sorting node to maintain the access control policy set and verify access requests. The policy-determining blockchain operates with low redundancy and, after verifying the access request, sends the verification result to the policy execution points of the first and second organizations. Upon receiving the response, the policy execution point of the first organization forwards the verification result to the data owner user via the data owner's terminal. Upon receiving the response, the policy execution point of the second organization transmits the verification result to the data access user via the data access user's terminal, enabling the data access user to achieve cross-organizational access with the permission of the data owner user.

[0102] In summary, this invention proposes a trusted access control method and system compatible with the XACML standard. The access control method adopted conforms to the industry-standard XACML, and its implementation reuses existing open-source code related to XACML policy decision points and policy execution points, resulting in low deployment costs for access control functionality. The use of blockchain technology to implement decentralized policy decision points eliminates distrust between different organizations, ensuring the reliability of access request verification results and thus enabling cross-organizational data access. Furthermore, the policy decision blockchain proposed in this invention employs a low-redundancy operation method, verifying access requests in parallel, improving blockchain performance, and thereby achieving efficient cross-organizational access control.

[0103] Those skilled in the art will readily understand that the above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A trusted access control method compatible with the XACML standard, characterized in that, include: S1: Data-owning users use the policy management point of their first organization to decide on blockchain deployment or deletion access policies; S2: Data access users send access requests to the policy decision blockchain through the policy enforcement point of their respective second organization; wherein, the policy decision blockchain adopts a sorting-execution separation architecture, and each blockchain node includes a sorting node and an execution node; the sorting node is used to record policy update operations and access requests; the execution node accepts the policy update operations and access requests delivered by the sorting node to maintain the access control policy set and verify access requests; S3: The strategy determines that the blockchain operates with low redundancy and sends the verification result to the strategy execution points of the first and second organizations after verifying the access request; S4: After receiving the response, the policy enforcement point of the first organization forwards the verification result to the data owner user; after receiving the response, the policy enforcement point of the second organization forwards the verification result to the data access user, so that the data access user can achieve cross-organizational access with the permission of the data owner user. Each access request is verified by a subset of the priority execution nodes; If the priority execution node fails to successfully complete the access request verification, the sorting node tracks each submitted access request. If the tracked access request is resolved within a limited time... f+1 A consistent response message is received, and the access request in subsequent blocks is marked as completed; otherwise, an allocation is made for the access request. f An additional execution node is allocated using a strategy that comprehensively considers the state of blockchain nodes to achieve load balancing of the execution nodes. Indicates the maximum number of potentially faulty nodes; When the sorting node verifies a block, for access requests marked as having finished execution, it only checks if it has already received such requests. f+1 A block is considered valid only when all access requests marked as completed are valid. The sorting nodes continue to reach consensus by voting on valid blocks. When a sorting node submits an access request marked as completed, it sends a reply containing a summary of the execution results to the policy execution points of the first and second organizations. Different execution nodes can simultaneously verify multiple access requests in parallel.

2. The trusted access control method compatible with the XACML standard as described in claim 1, characterized in that, The execution node receives policy update operations and access requests delivered by the sorting node to maintain the access control policy set and verify access requests, including: For each policy update operation, the execution node updates the set of access control policies cached at its own policy decision point and saves a copy of the update operation; For each data access request, the execution node invokes the policy decision point function to verify the access request and obtain the result; When the execution node verifies the access request contained in the current block as a priority node, it calls the policy decision point to verify the current access control policy set. After the access request is verified, it sends the verification result to the policy execution points of the first organization and the second organization, and also sends a response message that references the access request and contains a summary of the execution result to all sorting nodes. When the execution node verifies an access request not contained in the current block as an additional node, it rolls back its own state to the corresponding block based on the current access control policy set and the saved update operations, then verifies the access request again, and cancels the rollback after verification. After the access request is verified, it sends a reply to the policy execution points of the first organization and the second organization. When the blockchain system bandwidth is tight, the execution node uses a message compression method to reduce the number of response messages to be sent and save communication resources.

3. The trusted access control method compatible with the XACML standard as described in claim 2, characterized in that, The execution node uses a message compression method, including: The sorting node will batch the access requests and allocate execution nodes at the batch level. After verifying all access requests within a batch, the execution node generates a Merkle tree based on a list of all results; the execution node only needs to send one response message for all requests in the current batch, and the message contains the root value of the Merkle tree; The response sent by the execution node to the policy execution point includes the request verification result, the Merkle tree root value, and the Merkle proof that the verification result belongs to the Merkle tree.

4. The trusted access control method compatible with the XACML standard as described in claim 1, characterized in that, The corresponding allocation strategy comprehensively considers the blockchain node status to achieve load balancing of execution nodes, including: The sorting node records all transactions executed by all execution nodes; When assigning priority execution nodes to access requests, the sorting node counts the total number of requests executed by each execution node to date, sorts them in ascending order, and identifies the least busy node. One node is assigned to this request; When allocating additional execution nodes for timeout requests, the sorting node finds the least idle node besides the priority execution node preceding the current access request. A node is assigned to the access request.

5. The trusted access control method compatible with the XACML standard as described in claim 1, characterized in that, When the blockchain master node is At that time, it was able to tolerate One potentially faulty node.

6. A trusted access control system compatible with the XACML standard, characterized in that, The trusted access control method for implementing any one of claims 1-5, which is compatible with the XACML standard, includes: a data ownership user terminal, a data access user terminal, and a policy decision blockchain terminal; The data owner's terminal is used to determine the blockchain deployment or deletion access policy based on the input instructions of the data owner's user and with the help of the policy management point of the first organization to which it belongs; The data access user terminal is used to send an access request to the policy decision blockchain through the policy execution point of the second organization to which the data access user belongs, based on the input instructions of the data access user. The strategy determines the blockchain architecture, which adopts a sorting-execution separation architecture. Each blockchain node includes a sorting node and an execution node. The sorting node records policy update operations and access requests. The execution node receives the policy update operations and access requests delivered by the sorting node to maintain the access control policy set and verify the access requests. The strategy determines the blockchain to operate with low redundancy and, after verifying the access request, sends the verification result to the policy execution points of the first and second organizations. After receiving the reply, the policy execution point of the first organization forwards the verification result to the data owner user via the data owner user terminal. After receiving the reply, the policy execution point of the second organization transmits the verification result to the data access user via the data access user terminal, so that the data access user can achieve cross-organizational access with the permission of the data owner user.

Images