An internet of things access control system and method

Abstract

The application discloses an Internet of Things access control system and method, which simultaneously associates an edge intelligent server with an edge computing network and a blockchain network, and realizes interaction between the edge computing network and the blockchain network based on BaaS. Compared with IIoT devices, the edge intelligent server has higher computing and storage capabilities, so that the decentralized characteristics of the blockchain can be effectively utilized for Internet of Things access control in an edge computing scenario, avoiding single-point failure and high access control latency. In addition, the access control strategy is defined by a blockchain smart contract, so that safe fine-grained access control can be realized.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) technology, and in particular to an IoT access control system and method. Background Technology

[0002] Currently, extensive research has been conducted both domestically and internationally on distributed access control for edge computing in IIoT (Industrial Internet of Things) scenarios to meet requirements such as data integrity, security, consistency, and scalability. Existing technologies typically employ Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) for IoT access control. However, both of these methods rely on a central authority to verify access rights. In edge computing scenarios, most edge servers are distributed, leading to single points of failure and high latency issues with existing IoT access control methods, making them unsuitable for edge computing environments. Summary of the Invention

[0003] This invention provides an Internet of Things (IoT) access control system and method to solve the technical problem that existing technologies cannot be applied to IoT access control in edge computing scenarios.

[0004] To address the aforementioned technical problems, a first aspect of the present invention provides an Internet of Things (IoT) access control system, including an edge computing network, a blockchain network, and an edge intelligent server. The edge intelligent server is used to verify the permissions of the service request based on the access control policy defined by the preset blockchain smart contract when it receives a service request from the edge computing network, and generate an initial permission verification result. The blockchain network is used to confirm the service request based on the initial permission verification result and the blockchain smart contract, generate an access authorization token, and send it back to the edge smart server. The edge intelligence server is also used to instruct the target edge node and / or cloud server to process the service request based on the access authorization token, and to obtain the processing result of the service request.

[0005] As a preferred embodiment, the edge intelligent server, upon receiving a service request from the edge computing network, verifies the service request's permissions based on a preset access control policy defined by a blockchain smart contract, and generates an initial permission verification result, specifically including: Based on a pre-defined trusted subject information database, the request subject information carried in the service request is authenticated to obtain the authentication result; When the authentication result is successful, the service request is validated based on the access control policy to generate the initial permission validation result. When the initial permission verification result is successful, the initial permission verification result and the service request are sent to the blockchain network.

[0006] As a preferred embodiment, the edge intelligent server is used to perform permission verification on the service request based on the access control policy and generate the initial permission verification result, specifically including: Based on the access control scenario corresponding to the service request, the current access control mode is determined; wherein, the access control mode is RBAC mode and / or ABAC mode; Based on the access control policy, obtain the target access control information corresponding to the access control mode; Based on the target access control information, the service request is validated to generate the initial validation result.

[0007] As a preferred embodiment, the blockchain network is used to confirm the service request based on the initial permission verification result and the blockchain smart contract, generate an access authorization token, and send it back to the edge smart server, specifically including: Based on the initial permission verification result, the blockchain smart contract is invoked through the blockchain proxy node to perform permission matching on the service request and obtain the permission matching result. The consensus verification result is obtained by performing consensus verification on the permission matching result through blockchain miner nodes; When the consensus verification result is that the consensus verification is successful, the blockchain smart contract is invoked to generate the access authorization token based on the permission matching result, and the access authorization token is fed back to the edge smart server through the blockchain proxy node.

[0008] As a preferred embodiment, the edge intelligence server is further configured to instruct the target edge node and / or cloud server to process the service request based on the access authorization token, and obtain the processing result of the service request, specifically including: Based on the target edge node and / or the cloud server, generate a service orchestration plan corresponding to the service request; The access authorization token is sent to each of the target edge nodes and / or the cloud server corresponding to the service orchestration plan, so as to instruct each of the target edge nodes and / or the cloud server to process the service request in accordance with the service orchestration plan and obtain the processing result of the service request.

[0009] As a preferred embodiment, the edge intelligent server specifically determines the target edge node and / or the cloud server for processing the service request through the following steps: Based on the service request, determine the resource information of each target request at present; Based on a preset service repository, it is detected whether the target edge node and / or the cloud server corresponding to the target requested resource information exist in the service repository; wherein, the service repository stores the accessible resource ranges corresponding to different edge nodes and / or the accessible resource ranges corresponding to the cloud server; If they exist, then each of the target edge nodes and / or the cloud server is determined; If it does not exist, then query the target edge node or cloud server that does not store the accessible resource range that satisfies the target request resource information, and update the service repository based on the queried target edge node or cloud server.

[0010] As a preferred embodiment, the edge intelligence server is used to generate a service orchestration plan corresponding to the service request based on the target edge node and / or the cloud server, specifically including: Based on each target edge node and / or cloud server corresponding to each service sub-request in the service request, a candidate service request processing set for each service sub-request is determined. Based on preset QoS metric constraints, with the minimum service request response time as the service orchestration objective, service orchestration is performed on each of the candidate service request processing sets to determine the target edge node or cloud server that matches the service sub-request from the candidate service request processing sets. The service orchestration plan is generated based on the target edge node or cloud server matched by each of the service sub-requests.

[0011] As a preferred embodiment, the edge intelligent server is also used for: Receive registration information from users or devices to be registered and forward it to the management user terminal corresponding to the blockchain network; The blockchain network is also used for: When the registration information and access control information sent by the management user terminal are received, the registration information and access control information are deployed to the blockchain smart contract through the proxy node to update the access control policy of the blockchain smart contract; The updated access control policy of the blockchain smart contract is synchronized to the edge smart server through the proxy node.

[0012] As a preferred embodiment, the edge intelligent server is also used for: Receive service request processing information reported by each of the target edge nodes and / or the cloud server, and generate access behavior logs corresponding to the current service request based on each of the service request processing information; The access behavior log is sent to the blockchain network; The blockchain network is also used for: The access behavior log is encapsulated into blockchain transaction information by calling the blockchain smart contract through the proxy node; The blockchain transaction information is verified through consensus and stored on the blockchain by blockchain miner nodes.

[0013] A second aspect of this invention provides an Internet of Things (IoT) access control method, applying the IoT access control system as described in any of the first aspects, comprising: When the edge intelligent server receives a service request from the edge computing network, it verifies the service request's permissions based on the access control policy defined by the preset blockchain smart contract and generates an initial permission verification result. Based on the initial permission verification result and the blockchain smart contract, the blockchain network confirms the permission of the service request, generates an access authorization token, and sends it back to the edge smart server. The edge intelligence server instructs the target edge node and / or cloud server to process the service request based on the access authorization token, and obtains the processing result of the service request.

[0014] Compared to existing technologies, the beneficial effects of this invention are that by utilizing an edge intelligent server to simultaneously connect an edge computing network and a blockchain network, and by implementing interaction between the edge computing network and the blockchain network based on BaaS (Blockchain as a Service), the edge intelligent server has higher computing and storage capabilities than IIoT devices. This allows for effective utilization of the decentralized nature of blockchain for IoT access control in edge computing scenarios, avoiding single points of failure and high access control latency. Furthermore, by defining access control policies through blockchain smart contracts, secure, fine-grained access control can be achieved. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of the architecture of the Internet of Things access control system in an embodiment of the present invention; Figure 2 This is a flowchart illustrating the IoT access control method in an embodiment of the present invention. Detailed Implementation

[0016] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0017] Please see Figure 1 The first aspect of the present invention provides an Internet of Things access control system, including an edge computing network 101, a blockchain network 103, and an edge intelligent server 102; The edge intelligent server 102 is used to verify the permissions of the service request based on the access control policy defined by the preset blockchain smart contract when it receives a service request from the edge computing network 101, and generate an initial permission verification result. The blockchain network 103 is used to confirm the service request based on the initial permission verification result and the blockchain smart contract, generate an access authorization token, and send it back to the edge smart server 102. The edge intelligence server 102 is also used to instruct the target edge node and / or cloud server 104 to process the service request based on the access authorization token, and obtain the processing result of the service request.

[0018] It is worth noting that the edge computing network 101 in this embodiment consists of a sensing end and multiple edge nodes. The sensing end can be divided into three layers: a sensing layer, a network layer, and an application layer. The sensing layer is mainly responsible for data acquisition, and it can cover various sensors such as infrared sensors and radio frequency identification sensors to collect data from the physical world. The network layer is responsible for transmitting data between the sensing layer and the application layer to ensure reliable data transmission. The application layer is the interface for communication between users and IoT (Internet of Things) devices. It provides various interfaces and services, and performs simple data calculations and task processing to cope with limited resources. For some processing tasks that require higher computing and storage capabilities, they will be migrated to edge nodes for processing. Each edge node has a QoS (Quality of Service) configuration file to store information about its service capabilities, such as service processing performance, response latency, and supported service request concurrency, etc. This embodiment does not make specific limitations here. It is worth noting that edge nodes receive lightweight service requests for local resources on the edge side initiated by industrial IoT devices or data consumers at the sensing end. For example, after completing physical world data collection, various sensors or terminal devices at the sensing end may initiate lightweight data processing requests (such as data cleaning, simple aggregation, local threshold judgment, etc.) due to their limited computing or storage capabilities, as well as local linkage and interaction requests between devices (such as local command interaction between sensing devices and execution devices in an industrial production line). Additionally, data consumers may initiate access requests for IIoT data or services that have been synchronized to the local storage of the edge node. These requests do not require calling cloud server 104 or other edge node resources; the edge node can complete the response locally, such as querying the real-time data collected by the device that has been cached on the edge side or calling the basic service interfaces deployed locally on the edge side. These service requests do not require service orchestration processing by the edge intelligence server 102; instead, they are directly received and processed by local edge nodes, aligning with the core characteristics of edge computing: proximity to the terminal, low latency, and high real-time performance. Global service requests that require cross-edge node access, access to cloud resources, or involve complex permission verification are forwarded from the sensing end or edge node to the edge intelligence server 102. After processing lightweight service requests initiated by industrial IoT devices or data consumers at the sensing end locally, the edge node directly feeds back the processing result to the requesting industrial IoT device or data consumer, achieving real-time local response at the edge. If the edge node finds that a service request exceeds its processing capacity (e.g., requiring complex model calculations or large-capacity storage), it forwards the corresponding service request and preliminary processing results to the edge intelligence server 102. The edge intelligence server 102 then schedules the cloud server 104 or other edge nodes to complete subsequent processing and finally sends the final processing result back to the service request initiator.

[0019] Furthermore, considering the limited computing and storage capabilities of IIoT devices, this embodiment sets up an edge intelligent server 102. The Server (EIS) is a server with strong computing and storage capabilities. It is connected to both the edge computing network 101 and the blockchain network 103. When it receives a service request from the edge computing network 101 (such as a sensing end or edge node), it uses the access control policy defined by the blockchain smart contract to detect whether the subject initiating the service request has the corresponding access permissions. This enables rapid verification at the edge. Specifically, the access permission verification includes: whether the access subject is a registered node, whether the service request operation conforms to the basic QoS rules of the edge, whether the target requested resource is within the allowed access resource range of the edge computing network 101, and whether the access permissions of the access subject match the initiated service request. This generates an initial permission verification result, which can directly verify the credibility of the access subject's identity at the edge and complete the initial permission allocation. This forms the basis for subsequent permission confirmation by the blockchain network 103 without requiring full node consensus on the blockchain network 103 side. This effectively reduces the latency of access control, aligns with the low latency and high real-time characteristics of edge computing, and meets the real-time access requirements of IIoT scenarios.

[0020] Furthermore, the blockchain network 103 provides a service layer and integrates with a typical IoT architecture, which includes multiple different types of blockchain nodes, such as ordinary nodes used as sensor interfaces or connections for end devices to maintain the integrity of the IoT; agent nodes, which are the owners of blockchain smart contracts and are responsible for deploying blockchain smart contracts; and multiple miner nodes for forming a peer-to-peer network, which implement the core network of the blockchain, namely verifying transactions and mining transactions into blocks. Edge intelligent server 102 sends the initial permission verification result to blockchain network 103 through the gateway of blockchain network 103. The gateway can convert the CoAP (Constrained Application Protocol) encoded information of edge computing network 101 based on REST (Representational State Transfer) architecture into JSON-RPC (Stateless Lightweight Remote Procedure Call Protocol based on JSON format) information that blockchain network 103 can recognize. After receiving the initial permission verification result, since the identity information of the access subject has been verified on the edge side and the initial permission allocation has been completed, blockchain network 103 can directly perform permission matching on the service request again based on the confirmed authorization scope and the access control policy defined in the blockchain smart contract, realizing seamless connection between edge side authorization and blockchain network 103 side confirmation. Finally, blockchain network 103 generates an access authorization token based on the confirmed permissions and feeds it back to edge intelligent server 102. The access authorization token indicates the access subject's identity information, target requested resource information, authorization permissions, validity period and other information.

[0021] Understandably, blockchain smart contracts are code based on the blockchain that describes complex logic and can serve as implementations of contract-based automated protocols. Their programmability enables fine-grained access control.

[0022] After receiving the access authorization token, the edge intelligent server 102 synchronously sends it to each target edge node and / or cloud server 104 that needs to process the service request, so that the target edge node and / or cloud server 104 can grant access to the target resources to the access subject, complete real-time interaction such as data collection, reading, and operation, and finally obtain the processing result of the service request. Then, the processing result is sent back to the edge node that sent the service request, and the edge node feeds back the processing result to the access subject.

[0023] It is worth noting that the cloud server 104 has the strongest computing and storage capabilities compared to IIoT devices and edge nodes. In order to complete tasks that the sensing end cannot handle, edge nodes are used to share the processing pressure of the cloud server 104. However, for some tasks that require larger model computing or service storage, or for cases where the requested target resources are only stored on the cloud server 104, the edge nodes cannot handle them. Therefore, the cloud server 104 needs to handle the corresponding service requests. The cloud server 104's application provides various services, and cloud computing technology can be used to manage, schedule, integrate, and optimize various resources distributed on the network.

[0024] The IoT access control system provided in this embodiment of the invention utilizes an edge intelligent server 102 to simultaneously connect an edge computing network 101 and a blockchain network 103, and realizes the interaction between the edge computing network 101 and the blockchain network 103 based on BaaS. Compared with IIoT devices, the edge intelligent server 102 has higher computing and storage capabilities, thereby effectively utilizing the decentralized characteristics of blockchain for IoT access control in edge computing scenarios, avoiding single point of failure and high access control latency. In addition, by defining access control policies through blockchain smart contracts, secure fine-grained access control can be achieved.

[0025] As a preferred embodiment, the edge intelligent server 102, upon receiving a service request from the edge computing network 101, verifies the service request's permissions based on a preset access control policy defined by a blockchain smart contract, and generates an initial permission verification result, specifically including: Based on a pre-defined trusted subject information database, the request subject information carried in the service request is authenticated to obtain the authentication result; When the authentication result is successful, the service request is validated based on the access control policy to generate the initial permission validation result. When the initial permission verification result is successful, the initial permission verification result and the service request are sent to the blockchain network 103.

[0026] Specifically, the edge intelligent server 102 in this embodiment can be further configured with a request manager to perform permission verification on service requests. When a requesting subject initiates a service request, it must attach requesting subject information, such as subject identity identifier (unique ID / blockchain account address), device / user attribute information (such as device type, user role, access location), access credentials (edge-side temporary token / on-chain lightweight credential digest), etc. After receiving the service request, the request manager extracts the above requesting subject information to form an authentication verification dataset. Then, a trusted entity information database is used to match registered entities for identity verification. This database is synchronously updated by blockchain network 103 and contains core data such as the identity identifier, attribute information, legal access range, and valid credential information of all currently registered users / devices. The dimensions of identity verification include: identity identifier matching: verifying whether the requesting entity ID / blockchain account address is a registered legal identifier; attribute information matching: verifying whether the requesting entity's device type, user role, and other attributes are consistent with the registration information and have not been tampered with or forged; access legality matching: verifying whether the access location and access network of the requesting entity are within its registered legal access range; and credential validity matching: verifying whether the access credential attached to the requesting entity is within its validity period and whether the credential digest is consistent with the credential information synchronized on the blockchain side.

[0027] If the authentication result is successful, the service request is marked as a "trusted request," and the request subject information and service request content are standardized and encapsulated before proceeding to the subsequent permission verification stage. If the authentication result is unsuccessful, the service request is directly rejected and the reason for the authentication failure is returned. At the same time, the failure record is synchronized to the SLA (Service Level Agreement) monitor for subsequent abnormal access behavior analysis.

[0028] Furthermore, during the permission verification phase, since the access control policies in the blockchain smart contract are already synchronized locally, permission verification for service requests can be performed directly. First, the service request content is extracted, including the target service type (e.g., data access, device control, task computation), target request resource information (e.g., a certain type of IIoT data stored on the edge node, control permissions for a certain device), and request operation type (e.g., read, write, modify, execute), clarifying the specific permission requirements of the requesting subject. Then, based on the access control policy, it is verified whether the permissions of the requesting subject match the service request content. If the access control policy matches, temporary edge-side access permissions are allocated to the service request, and permission markers (including authorization scope, operation permissions, validity period, etc.) are added. If the access control policy does not match, the service request is directly rejected, and the reason for permission verification failure is returned. Simultaneously, the authorization rejection record is synchronized to the SLA monitor and the blockchain smart contract for on-chain permission auditing.

[0029] Furthermore, when the initial permission verification result is that the permission verification is successful, the initial permission verification result and service request can be summarized into an edge-side permission verification digest and sent to the blockchain network 103.

[0030] As a preferred embodiment, the edge intelligent server 102 is used to perform permission verification on the service request based on the access control policy and generate the initial permission verification result, specifically including: Based on the access control scenario corresponding to the service request, the current access control mode is determined; wherein, the access control mode is RBAC mode and / or ABAC mode; Based on the access control policy, obtain the target access control information corresponding to the access control mode; Based on the target access control information, the service request is validated to generate the initial validation result.

[0031] Specifically, the access control modes in this embodiment include RBAC mode, ABAC mode, and a hybrid mode of RBAC and ABAC modes. It can be understood that when deploying blockchain smart contracts, the management user defines access control policies (including access control lists, attribute predicates, access rules, etc.) under these access control modes. Among them, the RBAC-based model... Represented as a quadruple The elements represent users, roles, permissions, and sessions, respectively; this is an ABAC-based model. Represented as a quadruple The elements represent the subject, object, permission, and environment, respectively. To ensure compatibility with RBAC and ABAC schemas, [the following will be implemented]. and As a basic model, entities and their attributes, behaviors, other events, and other elements can be extended to adapt to a wider range of scenarios. On the other hand, the basic elements of both are defined in the access control policy, and corresponding authorizations are obtained in the blockchain smart contract by executing different options, thereby achieving fine-grained access control. and The entities, relationships, and behaviors are described as follows: Attribute A is a triple These represent the attribute name, value, and range of values, respectively. After creating a resource object, you need to set the attributes of that resource object; The attribute predicate AP is a triple. ,in It is an operator that restricts the range of attribute values, forming the attribute strategy expression of the resource object; An Access Control List (ACL) consists of two parts: a role list and an attribute policy list. The role list records the roles that are allowed to access the resource, and the attribute policy expression of the resource, respectively. The rules are Here, ID stands for identity identifier; Tgt is the target object, Tgt∈{resource, subject, operation, environment}, which allows the rule engine to perform more precise matching of service requests to ensure the security and reliability of access control; Eff is the effect expression, which defines the effect after the access control rule is executed, such as allowing or denying access; the condition expression C defines the conditions of the access control rule, such as restricting specific time, location, role, attribute, etc., which is a Boolean expression; OE and AE are the obligation expression and the suggestion expression, respectively, which define the additional actions that need to be performed after the access control rule is executed and the suggestions given before or after the access control rule is executed. The core element strategy P is . In other words, the attribute predicate AP implements operations on the attribute set A, with the values ​​of "allow" and "deny" representing allowing and denying authorization, respectively. ID stands for identity identifier. For a set of rules, RC is the rule combination algorithm; Top Elements It contains multiple strategies or other sets of strategies, among which It refers to the policy set, and PC stands for Policy Combination Algorithm. These elements form a hierarchical relationship between rules, policies, and policy sets.

[0032] The key to the IoT access control system proposed in this invention is the permission carried by the blockchain smart contract. Access control policies and operations are defined in the blockchain smart contract and triggered by blockchain transactions to achieve fine-grained access control. For example, the attributes and methods of the blockchain smart contract are described in Table 1 below, where "+", "#", and "-" are based on UML descriptions and represent public, protected, and private, respectively.

[0033] Table 1. Attributes and Methods of Blockchain Smart Contracts

[0034] In addition to the entities defined above, the basic set also includes user sets, role sets, operation sets, object sets, and session sets. Relationships between entities and events, such as those between subjects, objects, and permissions; user role assignment; role-permission binding; and token-event relationships, can all be established through operations and other methods within blockchain smart contracts. The relationships between entities and events are as follows: Attribute-Policy Assignment: Object-property-strategy assignment: Methods that are already mapped to user attribute policy sets: Methods that are already mapped to the object property strategy set: .

[0035] When determining the current access control mode, this embodiment makes a judgment based on the access control scenario corresponding to the current service request. It is understood that the access control scenario in this embodiment is determined by the request subject attributes, the requested resource type, resource granularity requirements, and environmental conditions. For example, when the request subject has a fixed role type, stable permissions, or is in a scenario of unified management of batch devices / users, the RBAC mode is selected. This mode is suitable for the permission allocation of administrators, fixed maintenance personnel, and batches of similar IIoT devices. When the attributes of the request subject or request object are dynamically changing, require fine-grained authorization, the device has dynamic access characteristics, or is subject to multi-dimensional environmental condition restrictions (time, location, device status, environmental parameters), the ABAC mode is selected. This mode is suitable for scenarios of dynamically accessed edge devices, temporary access devices / users, on-demand authorization, and highly flexible access control. When the access control scenario involves both fixed role management and complex access requirements with dynamic attribute verification, a hybrid mode of RBAC and ABAC is selected.

[0036] Furthermore, for permission verification based on RBAC mode, the default permission list corresponding to the role in the target access control information corresponding to the RBAC mode is matched according to the registered role of the requesting subject, and it is verified whether the role has the basic permissions to access the target requested service / resource and perform the corresponding operation; for permission verification based on ABAC mode, the attributes of the requesting subject's device / user (such as device computing power, user's department, access time) and the attributes of the target requested service / resource (such as resource importance level, service access scope) are combined with the attribute policy expression in the target access control information corresponding to the ABAC mode to verify whether the attributes of the requesting subject meet the access conditions of the target requested service / resource.

[0037] As a preferred embodiment, the blockchain network 103 is used to confirm the service request based on the initial permission verification result and the blockchain smart contract, generate an access authorization token, and send it back to the edge smart server 102, specifically including: Based on the initial permission verification result, the blockchain smart contract is invoked through the blockchain proxy node to perform permission matching on the service request and obtain the permission matching result. The consensus verification result is obtained by performing consensus verification on the permission matching result through blockchain miner nodes; When the consensus verification result is that the consensus verification is successful, the blockchain smart contract is invoked to generate the access authorization token based on the permission matching result, and the access authorization token is fed back to the edge smart server 102 through the blockchain proxy node.

[0038] Specifically, in this embodiment, the initial permission verification result and service request are submitted to the blockchain smart contract through a blockchain proxy node. The blockchain smart contract then calls its own checkP verification method to further match the ACL, attribute policies, access rules, etc., stored on the chain within the authorization scope indicated by the initial permission verification result, thus achieving precise matching of subject-object-permission. Preferably, it can also further determine whether the role / attribute of the requesting subject meets the resource access requirements based on access control policies in RBAC and / or ABAC modes, thereby improving access control security and ultimately obtaining the permission matching result.

[0039] Furthermore, the consensus verification of the permission matching result is carried out by blockchain miner nodes to ensure the decentralization and immutability of the permission determination, so as to obtain the consensus verification result.

[0040] Furthermore, the blockchain smart contract is invoked to generate an access authorization token corresponding to the permission matching result based on the consensus verification result that has passed the consensus verification. After the access authorization token is stored on the blockchain, it is sent back to the edge smart server 102 through the proxy node and the blockchain network 103 gateway. If the consensus verification fails, an access denial message is generated and sent back to the edge smart server 102 through the proxy node and the blockchain network 103 gateway.

[0041] As a preferred embodiment, the edge intelligence server 102 is further configured to instruct the target edge node and / or cloud server 104 to process the service request based on the access authorization token, and obtain the processing result of the service request, specifically including: Based on the target edge node and / or the cloud server 104, generate a service orchestration plan corresponding to the service request; The access authorization token is sent to each of the target edge nodes and / or the cloud server 104 corresponding to the service orchestration plan, so as to instruct each of the target edge nodes and / or the cloud server 104 to process the service request in accordance with the service orchestration plan and obtain the processing result of the service request.

[0042] Specifically, in this embodiment, the edge intelligent server 102 can perform service orchestration by setting a service allocator. It is worth noting that since a service request may include multiple parallel service sub-requests, and a service sub-request may be processed by multiple target edge nodes, or by at least one target edge node and cloud server 104, the quality of service achieved by different target edge nodes or cloud servers 104 is not the same. Therefore, this embodiment needs to allocate the optimal target edge node or cloud server 104 for processing each service sub-request while meeting QoS requirements, thereby realizing service orchestration of service requests, generating a service orchestration plan, and constructing a workflow that meets the required QoS requirements. Furthermore, the edge intelligent server 102 may also include a workflow engine, which is used to create a workflow execution thread on the allocated target edge node and / or cloud server 104 to meet the corresponding service request. After receiving the access authorization token, the access authorization token is sent to each target edge node and / or cloud server 104 corresponding to the service orchestration plan, so that these target edge nodes and / or cloud servers 104 open access permissions to the target requested resources to the access subject, complete real-time interaction such as data collection, reading, and operation, and thus obtain the processing result of the service request.

[0043] As a preferred embodiment, the edge intelligent server 102 specifically determines the target edge node and / or the cloud server 104 for processing the service request through the following steps: Based on the service request, determine the resource information of each target request at present; Based on a preset service repository, it is detected whether the target edge node and / or the cloud server 104 corresponding to the target requested resource information exist in the service repository; wherein, the service repository stores the accessible resource ranges corresponding to different edge nodes and / or the accessible resource ranges corresponding to the cloud server 104. If they exist, then each of the target edge nodes and / or the cloud server 104 is determined; If it does not exist, then query the target edge node or cloud server 104 that does not store the accessible resource range that satisfies the target request resource information, and update the service repository based on the queried target edge node or cloud server 104.

[0044] Specifically, in order to determine the target edge nodes and / or cloud servers 104 corresponding to the service request, this embodiment first needs to clarify the target request resource information currently required by the requesting subject based on the service request. Further, based on the available edge nodes in the service repository and the accessible resource range corresponding to the cloud server 104, it is determined whether the aforementioned target request resource information is available. If a target edge node and / or cloud server 104 corresponding to the target requested resource information exists, it means that these target edge nodes and / or cloud servers 104 can handle the corresponding service request. If no target edge node and / or cloud server 104 corresponding to the target requested resource information exists, it is possible that some edge nodes or cloud servers 104 have not registered for service with the edge intelligent server 102. Therefore, it is necessary to query the service repository in the edge computing network 101 for target edge nodes whose accessible resource range meets the target requested resource information, or query the service repository for cloud servers whose accessible resource range meets the target requested resource information. After the query is completed, in order to be able to directly query the corresponding target edge node or cloud server 104 from the service repository during the next service discovery to improve access control efficiency, this embodiment updates the service repository based on the queried target edge node or cloud server 104.

[0045] It is worth noting that this embodiment continuously updates the service repository by receiving service registration information from edge nodes and cloud server 104. Edge nodes in the edge computing network 101 and cloud server 104, which provides service capabilities to the edge in cloud-edge collaboration scenarios, have the ability to provide specific IoT services and are service providers in the edge computing environment. They need to expose their service capabilities to the outside world through service registration for scheduling by the request manager in edge intelligent server 102. The service repository serves as a unified storage carrier for service information in the edge computing environment and centrally manages service registration information. The registration content is consistent with the maintenance content of the service repository and includes at least: basic service information: unique identifier of the service, service name, IP address or port of the node providing the service, and service type (such as data processing, resource access, device control, etc.); service capability information: QoS-related information such as service processing performance, response latency, and supported concurrency, matching the QoS configuration file of the edge node; service attribute information: applicable scenarios of the service, accessible resource range, call permission requirements, service lifecycle (creation time, effective duration, update time, etc.); and service cost information: computing, storage, and network resource costs required for service calls, providing a basis for service orchestration and allocation. When an edge node or cloud server 104 is deployed in an IoT environment and has the capability to provide services, it will proactively send a service registration request to the edge intelligent server 102, carrying the complete service registration information mentioned above. When the service capabilities of the edge node or cloud server 104 change (such as performance improvement / degradation, addition / deletion of service types, or end of service lifecycle), the corresponding node will proactively initiate a service information update request to the edge intelligent server 102. The edge intelligent server 102 will synchronously update the corresponding service information in the service repository to ensure the real-time nature and accuracy of the stored service information.

[0046] As a preferred embodiment, the edge intelligence server 102 is used to generate a service orchestration plan corresponding to the service request based on the target edge node and / or the cloud server 104, specifically including: Based on each target edge node and / or cloud server 104 corresponding to each service sub-request in the service request, a candidate service request processing set for each service sub-request is determined. Based on preset QoS indicator constraints, with the minimum service request response time as the service orchestration objective, service orchestration is performed on each of the candidate service request processing sets to determine the target edge node or cloud server 104 that matches the service sub-request from the candidate service request processing sets. The service orchestration plan is generated based on the target edge node or cloud server 104 matched by each of the service sub-requests.

[0047] Specifically, assuming the set of edge nodes is used To indicate, is by A collection of edge nodes. Cloud server 104. To indicate. Unit services. ,in and These represent the services provided by the units. Input and output, This represents an operation on the service, that is, input. Later generated The operation process. This represents the Quality of Service (QoS) vector. This indicates the maximum number of requests per unit of service that a specific edge node or cloud server 104 can provide. All service sub-requests of a service request are represented by... express, The number of service sub-requests received. Service flow is a service system design and activity adopted to improve customer satisfaction; therefore, to achieve a service system with higher QoS, the service flow allocation problem must be optimized. The logical grouping of service representative operations, the Abstract Composite Service Workflow (ACSW), is the required service category, used... Indicates a response to a service request. The QoS value of a composite service depends on the QoS values ​​of its component services and the composite model used in the service orchestration plan. Represents an abstract service, indicating the operations required to implement the i-th phase in ACSW. It can represent a single unit service, a set of conditionally accessed unit services, or a set of unit services called concurrently. This can be achieved through an arrangement of the Feasible Selection Set (FSS), denoted as... ;in , This indicates that processing is performed at the edge nodes. This indicates that on cloud server 104 The above processes the issue, and by default, the cloud server will be 104. Viewed as a whole, the edge nodes or cloud servers providing services within the feasible selection set are determined based on a candidate service request processing set for each service sub-request. This candidate service request processing set includes all candidate edge nodes and / or cloud servers capable of handling the current service sub-request. The Concrete Composite Service Workflow (CCSW) is an instantiation of an abstract composite service. To indicate, the representative will Unit services in Assigned to service workflow ,Right now The QoS metrics in this embodiment include: (1) Network availability metrics : indicates service The probability of network access is the percentage of times when a user needs to use the network and the network is functioning correctly. , This represents the period for observing network conditions, while Representative services exist Total available time within seconds. Availability affects network utilization; higher network availability results in higher QoS.

[0048] (2) Service reliability indicators : Indicates the service The probability of receiving a correct response within the maximum tolerable timeframe when a request is made. , This indicates the number of times a correct response was received within the maximum tolerable timeframe. This represents the total number of service calls. Reliability affects throughput; higher network reliability results in higher QoS.

[0049] (3) Cost indicators : Indicates that the service requester invokes the service. The fees that need to be paid. In an IIoT environment, users need lower costs to achieve higher profits; therefore, the lower the fees, the higher the QoS.

[0050] (4) Service response time : Represents a service request The total time from sending the data to processing it and returning a response. , Representative services The time it was processed and These represent the time it takes to send the service request and the time it takes to return the service request processing result, respectively. In an IIoT environment, service requests from IoT devices need to receive real-time responses; therefore, the shorter the response time, the higher the QoS.

[0051] Understandably, the purpose of service orchestration is to find the optimal combination of service workflows, that is, to obtain the service flow instance with the minimum latency (CCSW) from the service flows that satisfy the maximum number of service requests. To achieve service orchestration of the candidate service request processing set, this embodiment proposes an incremental similarity matching service orchestration algorithm and a greedy multi-matching service orchestration algorithm.

[0052] For the incremental similarity matching service orchestration algorithm, incremental similarity matching is first introduced, which is mainly used to calculate the similarity of objects when the attribute set changes incrementally. Therefore, the unit service... Assigned to request Represented as similarity matching pairs Then the matching pair is The similarity between It can be represented as: ; in The attribute k representing QoS comprises four attributes: network availability, service reliability, cost, and service response time. , Indicates in the selection At that time, for attributes The preference weights, where During service orchestration, for each service sub-request and the services provided by each candidate edge node and / or cloud server 104 in the candidate service request processing set, it is verified whether they meet the local QoS indicator constraints. If they do, a matching pair is generated and added to the priority queue (sorted from high to low similarity). If the priority queue is not empty, the following steps are executed in a loop: the matching pair with the highest similarity is taken from the head of the priority queue. If the remaining service processing capacity of the candidate edge node or cloud server 104 is sufficient and the corresponding service sub-request has not yet been service orchestrated, the matching pair is taken as the final service orchestration result of the service sub-request. If the remaining service processing capacity of the candidate edge node or cloud server 104 is insufficient, but the corresponding service sub-request has not yet been service orchestrated, the service processing time is extended to meet the requirements of the remaining service processing capacity. It is then checked whether the adjusted candidate edge node or cloud server 104 still meets the QoS indicator constraints of the service request. If it does, it is put back into the priority queue to wait for the next round of processing. If it does not meet the requirements, the matching pair is discarded directly.

[0053] Since the goal of service orchestration is to minimize service request response time, the weight of the service response time metric is set to be the highest among all QoS attribute values.

[0054] For the greedy multi-match service orchestration algorithm, this embodiment quantifies the total QoS index value of each candidate edge node and / or cloud server 104 in the candidate service request processing set for processing the corresponding service sub-request. In addition, it also quantifies the QoS index requirement value corresponding to each service sub-request and processes it to obtain the normalized total QoS index requirement value. During the service orchestration process, the service sub-request is inserted into the request priority queue in descending order of the normalized total QoS index requirement value, and the candidate edge node and / or cloud server 104 in the candidate service request processing set is inserted into the service priority queue in descending order of the total QoS index value. If the priority queue is not empty, the following steps are executed cyclically: The highest-priority service sub-request is retrieved from the request priority queue; the highest-priority candidate edge node or cloud server 104 is retrieved from the service priority queue; the remaining service processing capacity of the retrieved candidate edge node or cloud server 104 is checked to ensure it is sufficient to process the retrieved service sub-request; the service provided by the retrieved candidate edge node or cloud server 104 is checked to ensure it meets QoS constraints; and the retrieved service sub-request has not been service orchestrated. If all conditions are met, the candidate edge node or cloud server 104 is paired with the service sub-request, and this is considered the service orchestration result for the service sub-request. If the remaining service processing capacity of the candidate edge node or cloud server 104 is insufficient, but the corresponding service sub-request has not yet been service orchestrated, the service processing time is extended to meet the remaining service processing capacity requirements. The adjusted candidate edge node or cloud server 104 is checked to ensure it still meets the QoS constraints of the service request. If it does, it is returned to the service priority queue to await the next round of processing; otherwise, the pair is discarded.

[0055] Based on the above service orchestration process, it is possible to determine the target edge node or cloud server 104 matched by each service sub-request, and the overall QoS is optimal.

[0056] As a preferred embodiment, the edge intelligent server 102 is further used for: Receive registration information from users or devices to be registered and forward it to the management user terminal corresponding to the blockchain network 103; The blockchain network 103 is also used for: When the registration information and access control information sent by the management user terminal are received, the registration information and access control information are deployed to the blockchain smart contract through the proxy node to update the access control policy of the blockchain smart contract; The updated access control policy of the blockchain smart contract is synchronized to the edge smart server 102 through the proxy node.

[0057] Specifically, IIoT devices, data owners, and data consumers in the edge computing network 101 can submit registration applications to the edge intelligent server 102 to complete user or device registration. The registration application carries registration information including identity information, device attributes, and resource attributes. After performing preliminary verification of this registration information, the edge intelligent server 102 sends it to the management user terminal. This is because the management user is the only entity that can interact with the blockchain smart contract, ensuring the security of the blockchain smart contract.

[0058] Furthermore, based on the registration information, the administrator defines access control information for the registered object in RBAC, ABAC, or a hybrid mode, including access control lists, attribute predicates, and access rules. This information, combined with the registration information, is then sent to the blockchain network 103. The blockchain network 103 then deploys the registration information and its corresponding access control information to the blockchain smart contract through proxy nodes. The proxy nodes, as the owners of the blockchain smart contract, complete the initial deployment and on-chain synchronization of the blockchain smart contract. Simultaneously, they map the address of the blockchain smart contract to "IP:Port" format and send it back to the edge intelligent server 102. This enables the edge intelligent server 102 to synchronize the updated access control policy of the blockchain smart contract, thus achieving the integration of the blockchain access control policy with the edge computing network 101.

[0059] As a preferred embodiment, the edge intelligent server 102 is further used for: Receive service request processing information reported by each of the target edge nodes and / or the cloud server 104, and generate access behavior logs corresponding to the current service request based on each of the service request processing information; The access behavior log is sent to the blockchain network 103; The blockchain network 103 is also used for: The access behavior log is encapsulated into blockchain transaction information by calling the blockchain smart contract through the proxy node; The blockchain transaction information is verified through consensus and stored on the blockchain by blockchain miner nodes.

[0060] Specifically, during the processing of service requests by various target edge nodes and / or cloud servers 104, the edge intelligent server 102 in this embodiment monitors the entire resource access process through an SLA monitor, detecting in real time whether the service level complies with the SLA agreement. If access anomalies, expired access authorization tokens, or SLA violations occur, a fault recovery mechanism is immediately triggered, suspending access and providing feedback to the accessing entity. Each target edge node and / or cloud server 104 reports service request processing information during resource access to the edge intelligent server 102. This service request processing information includes access time, operation content, and service request processing results. After summarizing this service request processing information, the edge intelligent server 102 forms an access behavior log and sends it to the blockchain network 103. The access behavior log includes access time, operation content, service request processing results, access authorization tokens, and SLA monitoring information.

[0061] Blockchain network 103 encapsulates access behavior logs into blockchain transaction information by calling blockchain smart contracts through proxy nodes. Then, blockchain miner nodes perform consensus verification and on-chain storage processing on the blockchain transaction information to write the access record into the blockchain block, achieving tamper-proof access information throughout the entire chain. Authorized entities such as management users and data owners can initiate information query requests through edge smart server 102 or directly to the blockchain smart contract, calling the query method of the blockchain smart contract to query the access records, access authorization tokens, access control policy execution information, etc. stored on the chain, to achieve full-chain auditing of access behavior. At the same time, edge smart server 102 can optimize service orchestration algorithms and QoS configuration of edge nodes based on access records, and blockchain management users can adjust access control policies in blockchain smart contracts based on access records, achieving dynamic optimization of access control policies.

[0062] It is worth noting that after completing the access control process such as identity authentication and permission verification, the edge intelligent server 102 in this embodiment generates an access control transaction information and sends it to the blockchain network 103. The miner nodes in the blockchain network 103 verify, package, and broadcast the various access control transaction information to all nodes in the network, and finally ensure data consistency through the consensus mechanism.

[0063] Furthermore, the blockchain smart contract in this embodiment can also provide the ability to automatically transfer, transmit, delegate, and revoke access permissions, that is, the legal transfer of access permissions between users, devices, and edge nodes; as well as the issuance, revocation, and renewal of temporary permissions; as well as permission transmission and identity proxy based on access authorization tokens; and the automatic on-chain execution and evidence storage of actions such as permission changes and authorization revocations. These processes are automatically completed by the blockchain smart contract, and are tamper-proof and auditable throughout, ensuring the security of permission flow in the edge environment.

[0064] Please see Figure 2 The second aspect of this invention provides an Internet of Things (IoT) access control method, which applies the IoT access control system described in any embodiment of the first aspect, and includes the following steps S1 to S3: Step S1: When the edge intelligent server receives a service request from the edge computing network, it verifies the service request based on the access control policy defined by the preset blockchain smart contract and generates an initial permission verification result. Step S2: Based on the initial permission verification result and the blockchain smart contract, the blockchain network confirms the permission of the service request, generates an access authorization token, and sends it back to the edge smart server. Step S3: The edge intelligent server instructs the target edge node and / or cloud server to process the service request based on the access authorization token, and obtains the processing result of the service request.

[0065] As a preferred embodiment, when the edge intelligent server receives a service request from the edge computing network, it verifies the service request's permissions based on the access control policy defined by the preset blockchain smart contract and generates an initial permission verification result, specifically including: Based on a pre-defined trusted subject information database, the request subject information carried in the service request is authenticated to obtain the authentication result; When the authentication result is successful, the service request is validated based on the access control policy to generate the initial permission validation result. When the initial permission verification result is successful, the initial permission verification result and the service request are sent to the blockchain network.

[0066] As a preferred embodiment, the step of verifying the service request based on the access control policy and generating the initial permission verification result specifically includes: Based on the access control scenario corresponding to the service request, the current access control mode is determined; wherein, the access control mode is RBAC mode and / or ABAC mode; Based on the access control policy, obtain the target access control information corresponding to the access control mode; Based on the target access control information, the service request is validated to generate the initial validation result.

[0067] As a preferred embodiment, the step of confirming the service request's permissions through the blockchain network based on the initial permission verification result and the blockchain smart contract, generating an access authorization token, and feeding it back to the edge smart server specifically includes: Based on the initial permission verification result, the blockchain smart contract is invoked through the blockchain proxy node to perform permission matching on the service request and obtain the permission matching result. The consensus verification result is obtained by performing consensus verification on the permission matching result through blockchain miner nodes; When the consensus verification result is that the consensus verification is successful, the blockchain smart contract is invoked to generate the access authorization token based on the permission matching result, and the access authorization token is fed back to the edge smart server through the blockchain proxy node.

[0068] As a preferred embodiment, the step of instructing the target edge node and / or cloud server to process the service request based on the access authorization token by the edge intelligent server, and obtaining the processing result of the service request, specifically includes: Based on the target edge node and / or the cloud server, generate a service orchestration plan corresponding to the service request; The access authorization token is sent to each of the target edge nodes and / or the cloud server corresponding to the service orchestration plan, so as to instruct each of the target edge nodes and / or the cloud server to process the service request in accordance with the service orchestration plan and obtain the processing result of the service request.

[0069] As a preferred embodiment, the method specifically uses the edge intelligent server to determine the target edge node and / or the cloud server for processing the service request through the following steps: Based on the service request, determine the resource information of each target request at present; Based on a preset service repository, it is detected whether the target edge node and / or the cloud server corresponding to the target requested resource information exist in the service repository; wherein, the service repository stores the accessible resource ranges corresponding to different edge nodes and / or the accessible resource ranges corresponding to the cloud server; If they exist, then each of the target edge nodes and / or the cloud server is determined; If it does not exist, then query the target edge node or cloud server that does not store the accessible resource range that satisfies the target request resource information, and update the service repository based on the queried target edge node or cloud server.

[0070] As a preferred embodiment, generating a service orchestration plan corresponding to the service request based on the target edge node and / or the cloud server specifically includes: Based on each target edge node and / or cloud server corresponding to each service sub-request in the service request, a candidate service request processing set for each service sub-request is determined. Based on preset QoS metric constraints, with the minimum service request response time as the service orchestration objective, service orchestration is performed on each of the candidate service request processing sets to determine the target edge node or cloud server that matches the service sub-request from the candidate service request processing sets. The service orchestration plan is generated based on the target edge node or cloud server matched by each of the service sub-requests.

[0071] As a preferred embodiment, the method further performs the following steps through the edge intelligence server: Receive registration information from users or devices to be registered and forward it to the management user terminal corresponding to the blockchain network; The method also performs the following steps through the blockchain network: When the registration information and access control information sent by the management user terminal are received, the registration information and access control information are deployed to the blockchain smart contract through the proxy node to update the access control policy of the blockchain smart contract; The updated access control policy of the blockchain smart contract is synchronized to the edge smart server through the proxy node.

[0072] As a preferred embodiment, the method further performs the following steps through the edge intelligence server: Receive service request processing information reported by each of the target edge nodes and / or the cloud server, and generate access behavior logs corresponding to the current service request based on each of the service request processing information; The access behavior log is sent to the blockchain network; The blockchain network is also used for: The access behavior log is encapsulated into blockchain transaction information by calling the blockchain smart contract through the proxy node; The blockchain transaction information is verified through consensus and stored on the blockchain by blockchain miner nodes.

[0073] The IoT access control method provided in this invention utilizes an edge intelligent server to simultaneously connect an edge computing network and a blockchain network, and implements interaction between the edge computing network and the blockchain network based on BaaS. Compared with IIoT devices, the edge intelligent server has higher computing and storage capabilities, thereby effectively utilizing the decentralized characteristics of blockchain for IoT access control in edge computing scenarios, avoiding single point of failure and high access control latency. In addition, by defining access control policies through blockchain smart contracts, secure fine-grained access control can be achieved.

[0074] A third aspect of the present invention provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the Internet of Things access control method described in any embodiment of the second aspect.

[0075] For example, the computer program may be divided into one or more modules / units, which are stored in the memory and executed by the processor to complete the present invention. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in the electronic device.

[0076] The electronic device may include, but is not limited to, a processor and a memory. Those skilled in the art will understand that the schematic diagram is merely an example of an electronic device and does not constitute a limitation on the electronic device. It may include more or fewer components than illustrated, or combine certain components, or different components. For example, the electronic device may also include input / output devices, network access devices, buses, etc.

[0077] The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor. The processor is the control center of the electronic device, connecting various parts of the electronic device through various interfaces and lines.

[0078] The memory can be used to store the computer programs and / or modules. The processor implements various functions of the electronic device by running or executing the computer programs and / or modules stored in the memory and by calling data stored in the memory. The memory may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the mobile phone (such as audio data, phonebook, etc.). In addition, the memory may include high-speed random access memory, and may also include non-volatile memory, such as hard disk, memory, plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0079] A fourth aspect of the present invention provides a computer-readable storage medium comprising a stored computer program, wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to perform the Internet of Things access control method according to any embodiment of the second aspect.

[0080] A fifth aspect of the present invention provides a computer program product, including a computer program / instructions, wherein when the computer program / instructions are executed by a processor, they implement the steps of the Internet of Things access control method described in any embodiment of the second aspect.

[0081] Wherein, if the modules / units integrated in the electronic device are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of the present invention can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0082] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. An Internet of Things (IoT) access control system, characterized in that, This includes edge computing networks, blockchain networks, and edge intelligent servers; The edge intelligent server is used to verify the permissions of the service request based on the access control policy defined by the preset blockchain smart contract when it receives a service request from the edge computing network, and generate an initial permission verification result. The blockchain network is used to confirm the service request based on the initial permission verification result and the blockchain smart contract, generate an access authorization token, and send it back to the edge smart server. The edge intelligence server is also used to instruct the target edge node and / or cloud server to process the service request based on the access authorization token, and to obtain the processing result of the service request.

2. The Internet of Things access control system as described in claim 1, characterized in that, The edge intelligent server, upon receiving a service request from the edge computing network, verifies the service request's permissions based on a preset access control policy defined by a blockchain smart contract, and generates an initial permission verification result, specifically including: Based on a pre-defined trusted subject information database, the request subject information carried in the service request is authenticated to obtain the authentication result; When the authentication result is successful, the service request is validated based on the access control policy to generate the initial permission validation result. When the initial permission verification result is successful, the initial permission verification result and the service request are sent to the blockchain network.

3. The Internet of Things access control system as described in claim 2, characterized in that, The edge intelligent server is used to perform permission verification on the service request based on the access control policy and generate the initial permission verification result, specifically including: Based on the access control scenario corresponding to the service request, the current access control mode is determined; wherein, the access control mode is RBAC mode and / or ABAC mode; Based on the access control policy, obtain the target access control information corresponding to the access control mode; Based on the target access control information, the service request is validated to generate the initial validation result.

4. The Internet of Things access control system as described in claim 1, characterized in that, The blockchain network is used to confirm the service request based on the initial permission verification result and the blockchain smart contract, generate an access authorization token, and send it back to the edge smart server, specifically including: Based on the initial permission verification result, the blockchain smart contract is invoked through the blockchain proxy node to perform permission matching on the service request and obtain the permission matching result. The consensus verification result is obtained by performing consensus verification on the permission matching result through blockchain miner nodes; When the consensus verification result is that the consensus verification is successful, the blockchain smart contract is invoked to generate the access authorization token based on the permission matching result, and the access authorization token is fed back to the edge smart server through the blockchain proxy node.

5. The Internet of Things access control system as described in claim 1, characterized in that, The edge intelligence server is also used to instruct the target edge node and / or cloud server to process the service request based on the access authorization token, and to obtain the processing result of the service request, specifically including: Based on the target edge node and / or the cloud server, generate a service orchestration plan corresponding to the service request; The access authorization token is sent to each of the target edge nodes and / or the cloud server corresponding to the service orchestration plan, so as to instruct each of the target edge nodes and / or the cloud server to process the service request in accordance with the service orchestration plan and obtain the processing result of the service request.

6. The Internet of Things access control system as described in claim 5, characterized in that, The edge intelligent server specifically determines the target edge node and / or the cloud server for processing the service request through the following steps: Based on the service request, determine the resource information of each target request at present; Based on a preset service repository, it is detected whether the target edge node and / or the cloud server corresponding to the target requested resource information exist in the service repository; wherein, the service repository stores the accessible resource ranges corresponding to different edge nodes and / or the accessible resource ranges corresponding to the cloud server; If they exist, then each of the target edge nodes and / or the cloud server is determined; If it does not exist, then query the target edge node or cloud server that does not store the accessible resource range that satisfies the target request resource information, and update the service repository based on the queried target edge node or cloud server.

7. The Internet of Things access control system as described in claim 5, characterized in that, The edge intelligence server is used to generate a service orchestration plan corresponding to the service request based on the target edge node and / or the cloud server, specifically including: Based on each target edge node and / or cloud server corresponding to each service sub-request in the service request, a candidate service request processing set for each service sub-request is determined. Based on preset QoS metric constraints, with the minimum service request response time as the service orchestration objective, service orchestration is performed on each of the candidate service request processing sets to determine the target edge node or cloud server that matches the service sub-request from the candidate service request processing sets. The service orchestration plan is generated based on the target edge node or cloud server matched by each of the service sub-requests.

8. The Internet of Things access control system as described in claim 1, characterized in that, The edge intelligence server is also used for: Receive registration information from users or devices to be registered and forward it to the management user terminal corresponding to the blockchain network; The blockchain network is also used for: When the registration information and access control information sent by the management user terminal are received, the registration information and access control information are deployed to the blockchain smart contract through the proxy node to update the access control policy of the blockchain smart contract; The updated access control policy of the blockchain smart contract is synchronized to the edge smart server through the proxy node.

9. The Internet of Things access control system as described in claim 1, characterized in that, The edge intelligence server is also used for: Receive service request processing information reported by each of the target edge nodes and / or the cloud server, and generate access behavior logs corresponding to the current service request based on each of the service request processing information; The access behavior log is sent to the blockchain network; The blockchain network is also used for: The access behavior log is encapsulated into blockchain transaction information by calling the blockchain smart contract through the proxy node; The blockchain transaction information is verified through consensus and stored on the blockchain by blockchain miner nodes.

10. An Internet of Things (IoT) access control method, characterized in that, The application of the Internet of Things access control system as described in any one of claims 1 to 9 includes: When the edge intelligent server receives a service request from the edge computing network, it verifies the service request's permissions based on the access control policy defined by the preset blockchain smart contract and generates an initial permission verification result. Based on the initial permission verification result and the blockchain smart contract, the blockchain network confirms the permission of the service request, generates an access authorization token, and sends it back to the edge smart server. The edge intelligence server instructs the target edge node and / or cloud server to process the service request based on the access authorization token, and obtains the processing result of the service request.

Images