Access control policy generation method, access control decision method and device

Abstract

This application provides an access control policy generation method, an access control decision method, and an apparatus. The access control policy generation method includes: obtaining a first access control policy defined using an Extensible Access Control Markup Language (Extreme Access Control Markup Language); the first access control policy includes first content and second content; the first content is related to a base policy, and the second content is independent of the base policy; extracting a base policy tag from the first content; and generating a second access control policy based on the base policy tag. The access control decision method includes: obtaining an access request and attribute information; invoking the corresponding access control policy based on the access request; obtaining the access policy according to the access control policy generation method described above; performing an access control decision based on the attribute information and the access control policy to obtain an access control decision result; and returning the uploaded data corresponding to the access request based on the access control decision result.

Description

Technical Field

[0001] This application relates to the field of access control technology, and in particular to an access control policy generation method, access control decision method and device. Background Technology

[0002] Due to its advantages of immutability, transparency, traceability, and the trusted computation capabilities of smart contracts, blockchain technology has become a primary choice for users to share data. With the increasing demand for data sharing across organizations, departments, and businesses, cross-chain access technology has emerged as a response.

[0003] To address the issue of differing access control policies across different blockchains during cross-chain access, related technologies construct an access control chain using a relay chain or collaborative chain, outside of the individual user-established blockchains, to store the access control policies of each blockchain. Specifically, these technologies typically utilize the eXtensible Access Control Markup Language (XACML) to define access control policies. However, XACML suffers from language redundancy and high storage requirements. Summary of the Invention

[0004] In view of this, the purpose of this application is to propose an access control policy generation method, an access control decision method, and an apparatus.

[0005] To achieve the above objectives, this application provides an access control policy generation method, comprising:

[0006] Obtain a first access control policy defined using an Extensible Access Control Markup Language; the first access control policy includes a first content and a second content; the first content is related to the base policy, and the second content is unrelated to the base policy;

[0007] Extract the basic strategy tags of the basic strategy from the first content;

[0008] A second access control policy is generated based on the basic policy label.

[0009] Optionally, the basic strategy label includes a first target label and a rule label; the rule label includes a second target label;

[0010] The second access control policy includes a policy data field;

[0011] The step of generating a second access control policy based on the basic policy label includes:

[0012] Based on the first target label and the second target label, the first sub-data field is obtained;

[0013] Based on the rule label, the second sub-data field is obtained;

[0014] Based on the first sub-data field and the second sub-data field, the policy data field of the second access control policy is obtained.

[0015] Optionally, obtaining the first sub-data field based on the first target label and the second target label includes:

[0016] Based on the attribute values ​​of the first target tag and the second target tag, the header of the first sub-data field is obtained;

[0017] Extract the predicate sub-tags of both the first target tag and the second target tag;

[0018] Based on the attribute name of the predicate sub-tag, the data field of the first sub-data field is obtained;

[0019] The first sub-data field is formed based on the header and data fields of the first sub-data field.

[0020] Optionally, the step of obtaining the data field of the first sub-data field based on the predicate sub-label includes:

[0021] In response to determining that the attribute name of the predicate sub-tag meets the preset conditions, the attribute name of the predicate sub-tag is converted into a combination of a string and preset symbols;

[0022] The combination of the string and the preset symbol is used as the data field of the first sub-data field.

[0023] Optionally, obtaining the second sub-data field based on the rule label includes:

[0024] Based on the attribute values ​​of the rule tags, determine the functional functions corresponding to the rule tags, as well as the usage conditions and combined conditions;

[0025] Based on the function, the usage conditions, and the combination conditions, the second sub-data field is obtained through a preset conversion rule.

[0026] Optionally, the second access control policy further includes a policy header; the policy header includes a policy identifier and a combination algorithm identifier.

[0027] The method for generating the strategy header includes:

[0028] The policy identifier code is obtained based on the identifier code of the basic policy label;

[0029] The combined algorithm identifier code is obtained based on the attribute values ​​of the rule tags.

[0030] Optionally, the policy header information may also include a user identifier code;

[0031] The method for generating the user identification code includes:

[0032] Obtain the user information corresponding to the first access control policy;

[0033] Based on the user information, a user identification code is obtained; the user identification code is a symbol sequence used to uniquely identify the corresponding user.

[0034] Optionally, the method further includes:

[0035] The second access control policy is uploaded to the access control chain; the access control chain is used to store the access control policy and the corresponding uploaded data.

[0036] Based on the same inventive concept, this application also provides an access control decision method, including:

[0037] Obtain access requests and attribute information;

[0038] The corresponding access control policy is invoked based on the access request; the access policy is obtained according to the access control policy generation method described in any of the above-mentioned items.

[0039] Based on the attribute information and the access control policy, an access control decision is made to obtain the access control decision result.

[0040] The upload data corresponding to the access request is returned based on the access control decision result.

[0041] Based on the same inventive concept, this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, it implements the access control policy generation method or access control decision method as described in any of the above claims.

[0042] By using the above method, only the rule information and target information in the access control policy are stored, reducing the memory occupied by the access control policy, thereby further reducing the storage burden of the access control system and improving the working efficiency of the access control system. Attached Figure Description

[0043] To more clearly illustrate the technical solutions in this application or related technologies, the drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0044] Figure 1 This is a flowchart illustrating an access control policy generation method according to one or more embodiments of this application;

[0045] Figure 2 This is a flowchart illustrating an access control decision method according to one or more embodiments of this application;

[0046] Figure 3 This is a schematic diagram of the structure of a first access control policy according to one or more embodiments of this application;

[0047] Figure 4 This is a schematic diagram illustrating the structure of a storage-efficient access control strategy for one or more embodiments of this application;

[0048] Figure 5 This is a schematic diagram of the conversion algorithm for the target data field in one or more embodiments of this application;

[0049] Figure 6 This is a schematic diagram of the conversion algorithm for rule data fields in one or more embodiments of this application;

[0050] Figure 7 This is a schematic diagram of the cross-chain access control system of one or more embodiments of this application;

[0051] Figure 8 This is a schematic diagram of the hardware structure of an electronic device according to one or more embodiments of this application. Detailed Implementation

[0052] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with specific embodiments and the accompanying drawings.

[0053] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this application should have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms "first," "second," and similar terms used in the embodiments of this application do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed after the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are only used to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0054] As described in the background section, with the increasing demand for data sharing across organizations, departments, and businesses, how to achieve cross-chain access between isolated blockchain systems has become an urgent problem to be solved.

[0055] Access control within blockchain systems is typically implemented using methods such as role-based access control, token-based access control, and attribute-based access control. Some blockchain systems also employ smart contracts for further restrictions to ensure security. Combining the immutability, transparency, and traceability of blockchain ledgers with the trusted computation advantages of smart contracts, these methods can achieve secure and effective access control within the blockchain. However, different blockchain systems may reside in different security domains, and the existing access control schemes cannot meet the information sharing requirements of such systems.

[0056] Therefore, related technologies propose constructing a control access chain architecture and using control access policies to determine whether to authorize a user.

[0057] Related technologies propose constructing a control access chain architecture based on a cross-chain mechanism using a relay chain or a collaborative chain. Specifically, this architecture uses the relay chain or collaborative chain as the access control chain. Data uploaders use cross-chain nodes to call the smart contracts of the relay chain or collaborative chain to upload data and smart contracts, while data requesters use cross-chain nodes to call the relay chain or collaborative chain to request and retrieve data.

[0058] During cross-chain access using the aforementioned cross-chain access control architecture, the access control chain obtains information provided by the user and determines whether it complies with the cross-chain access control policy. If it does, the requested data is provided to the user. XACML is typically used to define access control policies. However, this language suffers from redundancy and high storage consumption.

[0059] Therefore, this application proposes an access control policy generation method, which converts the access control policy defined using XACML into a storage-efficient access control policy (HES) that occupies less memory by using preset conversion rules and mapping rules, thereby reducing the storage pressure on the control access chain and improving system efficiency.

[0060] The technical solutions of one or more embodiments of this application will be described in detail below through specific examples.

[0061] refer to Figure 1 The access control policy generation method of one or more embodiments of this application includes the following steps:

[0062] Step S101: Obtain a first access control policy defined using an Extensible Access Control Markup Language; the first access control policy includes a first content and a second content; the first content is related to the basic policy, and the second content is unrelated to the basic policy.

[0063] The structure of the first access control policy defined using Extensible Access Control Markup Language is as follows: Figure 3 As shown, a first access control policy contains a base policy (PolicySet) tag, which covers at least one base policy (Policy) tag and a corresponding target (Target) tag; the attribute name of each policy tag can be the unique identifier (PolicyId) of the policy or the rule combination algorithm (RuleCombiningAlgId), and it contains at least one rule (Rule) tag; the attribute name of each rule tag can be the unique identifier (RuleId) of the rule or the authorization result (RuleEffect) of the policy, and the attribute value can be a permit statement (Permit) or a denial statement (Deny), and it contains an effect (Effect) attribute. Each PolicySet, Policy, and Rule tag always contains a Target tag, and the attribute name of the Target tag can be the unique identifier (TargetId) of the target, used to describe the subject, behavior, resource, and environmental information and their constraints.

[0064] In some embodiments, the main meanings and functions of the above labels are shown in the table below.

[0065]

[0066] Step S102: Extract the basic strategy tags of the basic strategy from the first content.

[0067] In implementing this application, the applicant discovered that access control policies defined using Extensible Access Control Markup Language (XML) contain Java package name information and XML tags and closing tags. This information is not essential for access control itself, but it occupies a large amount of storage space, resulting in a waste of storage space.

[0068] Therefore, the applicant proposes a storage-efficient access control policy (HES), which extracts the necessary information from the above access control policy, namely the information related to identifying the subject and object, logical predicate, attribute and attribute value, and constructs a new access control policy file to reduce memory occupation.

[0069] In this step, the necessary content related to the basic policy is extracted from the access control policy defined using the Extensible Access Control Markup Language; that is, the basic policy tag of the basic policy is extracted.

[0070] Step S103: Generate a second access control policy based on the above basic policy tags.

[0071] In some embodiments, the structure of HES is as follows: Figure 4 As shown. Specifically, in some embodiments, the second access control policy mentioned above includes a policy data field.

[0072] In some embodiments, the above policy data field describes the specific content of the HES policy.

[0073] In implementing this application, the applicant discovered that the smallest unit acceptable for a policy decision point in an access control policy defined using an extensible access control markup language is the basic policy.

[0074] In some embodiments, the basic policy label of the first access control policy includes a first target label and a rule label; the rule label includes a second target label; and the second access control policy includes a policy data field.

[0075] In some embodiments, generating a second access control policy based on the basic policy label includes: obtaining a first sub-data field based on the first target label and the second target label; obtaining a second sub-data field based on the rule label; and obtaining a policy data field of the second access control policy based on the first sub-data field and the second sub-data field.

[0076] In some embodiments, the policy data fields described above include a Target field and a Rule field. In some embodiments, the Target field includes a Target header and a Target data field. In some embodiments, the Target header includes a target identifier (target_id) to distinguish each subject, and a target maximum dimension (target_length) as an offset to describe its range. In some embodiments, the Target data field is used to describe the target tag content.

[0077] In some embodiments, the tag value of the Target tag, the type and description of the tag attribute set sub-tags are shown in the following table:

[0078]

[0079] In some embodiments, the Rule field includes a Rule header and a Rule data field. In some embodiments, the Rule header includes a rule identifier (rule_id) to distinguish each rule; a rule effect (rule_effect) to represent the two fixed values ​​of permit and deny for each effect label; and a maximum rule length (rule_length) to describe its range as an offset. In some embodiments, the rule data field describes the original policy content.

[0080] In some embodiments, the tag value of the rule tag, the type and description of the tag attribute set sub-tags are shown in the following table:

[0081]

[0082]

[0083] The target tag and rule tag are converted separately because their content and function differ, and their conversion rules are distinct. The target tag defines the applicability of a policy; a target can be declared by the constructor of a policy element, or it can be calculated by intersecting or unioning the target tags within a rule tag. The rule tag is used to describe the predicate information of resource-related attributes and rules.

[0084] However, both target tags and rule tags consist of three parts: attribute values, tag attributes, and sub-tags. Therefore, this application transforms the aforementioned first access control policy based on this characteristic.

[0085] In some embodiments, obtaining the first sub-data field based on the first target label and the second target label includes: obtaining the header of the first sub-data field based on the attribute values ​​of the first target label and the second target label; extracting the predicate sub-labels of the first target label and the second target label; obtaining the data field of the first sub-data field based on the attribute names of the predicate sub-labels; and assembling the first sub-data field based on the header and the data field of the first sub-data field.

[0086] In the first access control policy, the attribute items of the Target tag are determined by the attribute name and attribute value. In some embodiments, the Target tag further includes three predicate sub-tags: check if the object satisfies all Match (AllOf), check if the object satisfies at least one Match (AnyOf), and match the string with the regular expression (Match).

[0087] In some embodiments, the target_id tag in the HES structure is extracted from the attribute value of the target identifier (TargetId) in the first access control policy.

[0088] In some embodiments, the Target data field in the HES structure is obtained by converting the three predicate sub-tags described above using a preset conversion algorithm. In some embodiments, it can be obtained through, for example... Figure 5 The transformation algorithm transforms the access control policy. The target_length in the HES structure is also generated accordingly.

[0089] In some embodiments, obtaining the data field of the first sub-data field based on the attribute name of the predicate sub-tag includes: in response to determining that the attribute name of the predicate sub-tag meets a preset condition, converting the attribute name of the predicate sub-tag into a combination of a string and a preset symbol; and using the combination of the string and the preset symbol as the data field of the first sub-data field.

[0090] A Policy consists of three parts: a Rule Combining algorithm, several Rule tags, and a Target tag. In some embodiments, the Target tag corresponding to the Policy tag only needs to extract its attributes and values, while Rule Combining needs to extract the attributes, values, and the corresponding combination relationships to generate the policy combination rules in the HSE policy.

[0091] In some embodiments, the correspondence between the Rule Combining algorithm in the first access control policy and the HES policy is shown in the table below.

[0092]

[0093] In some embodiments, the first access control policy mentioned above further includes a function identifier (FunctionId) attribute, and the conversion rules between the attribute value of the FunctionId attribute and the HES policy predicate are shown in the table below.

[0094]

[0095] In some embodiments, the rule_id tag in the HES structure is extracted from the ruleId attribute value in the first access control policy. The rule_effect tag and the rule_length tag are generated accordingly.

[0096] In some embodiments, obtaining the second sub-data field based on the rule label includes: determining the function, usage conditions, and combination conditions corresponding to the rule label based on the attribute value of the rule label; and obtaining the second sub-data field based on the function, usage conditions, and combination conditions through a preset conversion rule.

[0097] In some embodiments, Rule data fields can be accessed through methods such as... Figure 6 The conversion algorithm converts the access control policy.

[0098] In some embodiments, the second access control policy further includes a policy header. In some embodiments, the policy header includes a policy identifier and a combination algorithm identifier; the method for generating the policy header includes: obtaining the policy identifier based on the identifier of the basic policy tag; and obtaining the combination algorithm identifier based on the attribute value of the rule tag.

[0099] In some embodiments, the policy header information further includes a user identifier. The method for generating the user identifier includes: obtaining user information corresponding to the first access control policy; obtaining a user identifier based on the user information; and using the user identifier as a symbol sequence to uniquely identify the corresponding user.

[0100] In some embodiments, the policy header describes basic policy information. In some embodiments, the policy header consists of a basic policy identifier (policy_id) and a basic policy combination algorithm (policy_alg). The policy_id distinguishes each policy, and the policy_alg describes the algorithm for combining rules. In some embodiments, the policy header also includes a business identifier (company_id). The company_id distinguishes businesses between different chains. In some embodiments, the company_id can be manually set. In some embodiments, the business identifier can be an identifier corresponding to a company name or a business name. Different setting methods, as long as they achieve the corresponding purpose, will not affect the scope of protection of this invention.

[0101] In some embodiments, the access control policy generation method further includes: uploading the second access control policy to the access control chain; the access control chain is used to store the access control policy and the corresponding uploaded data.

[0102] Based on the same inventive concept, corresponding to the access control policy generation method of any of the above embodiments, this application also provides an access control decision method, see reference. Figure 2 It includes the following steps:

[0103] Step S201: Obtain access request and attribute information.

[0104] In some embodiments, in this step, the access request and attribute information sent by the associated business chain are first obtained through the access control chain.

[0105] Step S202: Invoke the corresponding access control policy according to the above access request; the above access policy is obtained according to any one of the above access control policy generation methods.

[0106] In some embodiments, the access control policy described above is a policy pre-stored on the access control chain. In some embodiments, the access control policy can be invoked based on the attribute information described above.

[0107] Step S203: Make access control decisions based on the above attribute information and the above access control policies, and obtain the access control decision results.

[0108] In some embodiments, the access control policy contains a large amount of rule information and target information. The access control chain determines whether to approve the access request based on the matching relationship between the attribute information and the access control policy.

[0109] Step S204: Return the uploaded data corresponding to the access request based on the access control decision result.

[0110] In some embodiments, if the access control decision result is "permit", it means that the attribute of the business chain can access the data corresponding to the access request, and therefore the uploaded data corresponding to the access request is returned. In some embodiments, if the access control decision result is "deny", it means that the attribute of the business chain does not meet the data access conditions, and therefore a request failure message is returned.

[0111] The aforementioned access control policy generation method and access control decision method can be applied to the cross-chain access control system application scenario.

[0112] First, let's explain the cross-chain access control system. As mentioned above, with the increasing demand for data sharing between different blockchain systems, related technologies have proposed cross-chain access control schemes.

[0113] Various cross-chain access control schemes have been proposed in related technologies, including: constructing an access control chain using a relay chain / collaborative chain cross-chain mechanism; using a consortium blockchain as the access control chain; using a collaborative chain as the access control chain; using an inter-domain blockchain access control model; and using an enterprise chain or industry chain as the access control chain. Each of these methods has its advantages and disadvantages, and all have been applied in real-world scenarios. Specifically, cross-chain access control uses a relay chain / collaborative chain cross-chain mechanism to construct the access control chain, sharing information about subjects and objects in different security domains through blockchain ledgers and smart contracts for access control decisions. Using a consortium blockchain as the access control chain involves connecting IoT nodes to the channel for transactions, which are then notarized by the access control chain. This scheme has extremely high throughput in the context of large-scale IoT access control requests, but requires IoT devices to be online in real time, making it unsuitable for access control in non-IoT scenarios. A cross-chain access control strategy based on a collaborative chain involves cross-chain nodes calling the collaborative chain's smart contracts to implement data uploads and requests. This scheme requires uploading the service owner's data to the collaborative chain, which poses data security risks when applied in real-world scenarios. The blockchain inter-domain access control model uses public-key cryptography to encrypt access control records, protecting their privacy and security. However, it lacks a standardized access control architecture and therefore its practicality needs improvement. A cross-chain access control scheme employing collaboration between enterprise and industry chains supports multi-level access control, but its access control permissions only extend to the enterprise level, requiring further granularity.

[0114] Meanwhile, related technologies have proposed various permission design models. These include discretionary access control permission design models, mandatory access control permission design models, role-based access control permission design models, and attribute-based permission verification design models.

[0115] Regardless of the method or permission design model used, the underlying logic of the aforementioned cross-chain access control architecture is the same: to build a cross-chain access control chain independently outside of each user's independent blockchain system, and to connect the functional nodes of each system through the cross-chain access control chain. When uploading or requesting data, users only need to send the data or request to the cross-chain access control chain according to the preset rules.

[0116] Therefore, for a cross-chain access control system designed based on the aforementioned underlying logic, the data upload method and access control decision method proposed in this application can utilize the HES (Hardware Execution System) with a smaller memory footprint to store user-uploaded strategies, thereby achieving more efficient data upload and access control decisions. Different cross-chain access control systems will not affect the scope of protection of this invention.

[0117] The following describes in detail one or more specific embodiments of the above-mentioned access control policy generation method and access control decision method, using an attribute-based permission verification permission model and a cross-chain access control system that uses a relay chain as the access control chain.

[0118] First, the aforementioned cross-chain access control system will be explained. For example... Figure 7 As shown, this system is based on a relay chain architecture, where cross-chain nodes elected by each independent blockchain form an access control chain. At least one access control policy is defined based on XACML. These cross-chain nodes, acting as smart points, are responsible for collecting information such as attributes and policies, and calling smart contracts to perform the access control decision-making process, thereby meeting the complex, flexible, and fine-grained cross-chain access control needs in real-world scenarios.

[0119] The above-mentioned functional points can be classified into Attribute Management Points (AM), Policy Management Points (PAP), Policy Information Points (PIP), Policy Decision Points (PDP), and Policy Execution Points (PEP) according to their functions, as shown in the table below.

[0120]

[0121] by Figure 7 As illustrated, the business chains consist of server nodes maintained or hosted by individual companies, enterprises, or other organizations, with data isolated from each other. The access control chain comprises cross-chain nodes elected by each business chain, and its public ledger is visible to all business chains. Therefore, information needed for access control, such as access control policies, relevant participant attribute information, and access control decision results, can be shared through the public ledger. Smart contracts can represent the access control architecture built upon access control policies defined in XACML or other languages, executing various processes of cross-chain access control.

[0122] Attribute management points are used to upload, update, and delete subject attributes, object attributes, and environment attributes. They correspond to the attribute management contract in the access control chain. When subject, object, or resource attributes related to cross-chain access need to be added, modified, or deleted in various business chains, the attribute management contract is invoked to operate on the public ledger on the access control chain. Policy management points are used to upload, update, and delete access control policies. They correspond to the policy management contract on the access control chain. Policy information points provide the necessary subject, object, and environment information for access control decisions. They correspond to the information collection contract in the access control chain. Upon receiving a cross-chain access control request, they parse the request to obtain attributes such as the initiator, the accessed object, and environment information, use the corresponding cross-chain node to obtain the relevant attributes, and pass them to the policy decision point. The policy decision point combines the data transmitted by the policy information point with the access control policy to make a decision on the access control result. It corresponds to the policy decision contract in the access control chain, executes the policy, and uploads the result to the access control chain. The policy execution point executes the corresponding request based on the decision result of the policy decision point. The policy execution contract of the corresponding access control chain is specifically invoked by the cross-chain node of the corresponding chain, and the call result is returned to the requester along the call chain. Whether to put the result on the chain is determined according to the needs.

[0123] In some embodiments, the process of a data uploader (DO, Data Owner) uploading data through the above system may include the following steps:

[0124] First, in response to determining that the uploaded data contains an access control policy defined using an Extensible Access Control Markup Language, a target access control policy is generated using the access control policy generation method described in any of the above.

[0125] In some embodiments, the uploaded data may include data that needs to be saved or shared.

[0126] In some embodiments, a data uploader can upload data that needs to be saved or shared to the cloud, and use the data summary and address of the data shared to the cloud as the uploaded data. In some embodiments, when the data owner uploads the above-mentioned uploaded data to the business chain, it needs to call the data upload contract to upload the data information DATAINFO to the business chain. In some embodiments, DATAINFO = (Chain id Data id Data url Sign DO ). Among them, Chain id Represents a unique identifier for the business chain, Data id This represents a unique identifier for the data, with the prefix being the identifier of the business chain to which it belongs. url Indicates the data address, Sign DOThe signature of the service owner.

[0127] In addition to uploading the data to the business chain, access control policies also need to be uploaded. These access control policies can be defined using XACML.

[0128] In response to the determination that the uploaded data contains an access control policy defined using Extensible Access Control Markup Language, a target access control policy is generated using the access control policy generation method described in any of the preceding steps. The policy generation method is as described in steps S101-S102, and will not be repeated here.

[0129] Then, the uploaded data and the target access control policy are uploaded to the access control chain; the access control chain is used to store all the access control policies mentioned above.

[0130] After receiving or converting the access control policy, the business chain uploads the access control policy to the access control chain through the cross-chain node of the business chain.

[0131] In some embodiments, the process of a data user (DU) making a data request through the above system may include the following steps:

[0132] First, obtain the access request and attribute information.

[0133] In some embodiments, access requests and attribute information are first obtained through cross-chain nodes connected by the business chain and the access control chain. In some embodiments, the attribute information includes subject attributes, object attributes, and environment attributes.

[0134] Then, the access control policy is invoked according to the access request; the access policy is generated according to the access control policy generation method described in any one of the above.

[0135] In some embodiments, the above access request is parsed by a cross-chain node according to the following formula:

[0136] REQUEST = (Company id Data id User id Action, Sign DU ,Request id ), where Company id Dataid represents the unique identifier of the business to which the data requester belongs, while User represents the unique identifier of the requested data. id The unique identifier represents the requester; Action represents the requested action, such as read / write / delete; Sign represents the requester's unique identifier. DU Indicates the signature of the requester, Requestid An identifier code that indicates the requested action.

[0137] Secondly, access control decisions are made based on the aforementioned attribute information and access control policies to obtain the access control decision results.

[0138] In some embodiments, after parsing the access request, the policy information contract is invoked to obtain the subject attribute, object attribute, and environment attribute, and these attributes are sent to the policy decision point as the parameter PARAM. In some embodiments, PARAM = (Poli cycontnet Attr env Attr sub Attr obj Action, Request id ), where Policy contnet Indicates the strategy content, Attr env Attr represents an environment attribute. sub Attr represents the main attribute. obj Represents object attributes, Action represents operation, Request represents object attributes. id Indicates the request ID.

[0139] In some embodiments, the policy decision point determines whether the acquired attribute information complies with the access control policy requirements based on the access control policy, and generates a control policy result. In some embodiments, the control policy result RES = (User id PDP (Attr) env Attr sub Attr obj Poicy content ), Request id ), where User id Attr represents the user identifier. env Attr represents an environment attribute. sub Attr represents the main attribute. obj Indicates object attributes, Policy contnet Indicates the strategy content, Request id Indicates the request ID.

[0140] Finally, based on the access control decision results, the data corresponding to the access request is returned.

[0141] In some embodiments, after receiving the control policy result, the policy execution point may return a permission-unauthorized message based on the result, or query the uploaded data stored on the corresponding business chain through a cross-chain node and return it to the data requester along the chain.

[0142] It should be noted that the method in this embodiment can be executed by a single device, such as a computer or server. The method can also be applied in a distributed scenario, where multiple devices cooperate to complete the task. In such a distributed scenario, one of these devices may execute only one or more steps of the method in this embodiment, and the multiple devices will interact with each other to complete the method described.

[0143] It should be noted that the above description describes some embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in a different order than that shown in the above embodiments and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0144] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, in implementing this application, the functions of each module can be implemented in one or more software and / or hardware.

[0145] The apparatus described above is used to implement the corresponding access control policy generation method in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0146] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this application also 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 program to implement the access control policy generation method described in any of the above embodiments.

[0147] Figure 8 This embodiment illustrates a more specific hardware structure of an electronic device, which may include a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, memory 1020, input / output interface 1030, and communication interface 1040 are interconnected internally via the bus 1050.

[0148] The processor 1010 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.

[0149] The memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1020 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented by software or firmware, the relevant program code is stored in the memory 1020 and is called and executed by the processor 1010.

[0150] The input / output interface 1030 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components within the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touchscreens, microphones, various sensors, etc., while output devices may include displays, speakers, vibrators, indicator lights, etc.

[0151] The communication interface 1040 is used to connect a communication module (not shown in the figure) to enable communication between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0152] Bus 1050 includes a pathway for transmitting information between various components of the device, such as processor 1010, memory 1020, input / output interface 1030, and communication interface 1040.

[0153] It should be noted that although the above-described device only shows the processor 1010, memory 1020, input / output interface 1030, communication interface 1040, and bus 1050, in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the embodiments of this specification, and not necessarily all the components shown in the figures.

[0154] The electronic devices described above are used to implement the corresponding access control policy generation method, data upload method, and access control decision method in any of the foregoing embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0155] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of this application (including the claims) is limited to these examples; within the framework of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of the embodiments of this application as described above, which are not provided in the details for the sake of brevity.

[0156] Additionally, to simplify the description and discussion, and to avoid obscuring the embodiments of this application, the well-known power / ground connections to integrated circuit (IC) chips and other components may or may not be shown in the provided drawings. Furthermore, the apparatus may be shown in block diagram form to avoid obscuring the embodiments of this application, and this also takes into account the fact that the details of the implementation of these block diagram apparatuses are highly dependent on the platform on which the embodiments of this application will be implemented (i.e., these details should be fully understood by those skilled in the art). While specific details (e.g., circuits) have been set forth to describe exemplary embodiments of this application, it will be apparent to those skilled in the art that the embodiments of this application can be implemented without these specific details or with variations thereof. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0157] Although this application has been described in conjunction with specific embodiments thereof, many substitutions, modifications, and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may be used with the embodiments discussed.

[0158] The embodiments of this application are intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the embodiments of this application should be included within the protection scope of this application.

Claims

1. A method for generating access control policies, characterized in that, include: Obtain a first access control policy defined using an Extensible Access Control Markup Language; the first access control policy includes a first content and a second content; the first content is related to the base policy, and the second content is unrelated to the base policy; Extract the basic strategy tags from the first content, wherein the basic strategy tags include a first target tag and a rule tag; the rule tags include a second target tag. Based on the basic policy label, a second access control policy is generated, the second access control policy including a policy data field; The step of generating a second access control policy based on the basic policy label includes: Based on the first target label and the second target label, the first sub-data field is obtained; Based on the rule label, the second sub-data field is obtained; Based on the first sub-data field and the second sub-data field, the policy data field of the second access control policy is obtained.

2. The access control policy generation method according to claim 1, characterized in that, The step of obtaining the first sub-data field based on the first target label and the second target label includes: Based on the attribute values ​​of the first target tag and the second target tag, the header of the first sub-data field is obtained; Extract the predicate sub-tags of both the first target tag and the second target tag; Based on the attribute name of the predicate sub-tag, the data field of the first sub-data field is obtained; The first sub-data field is formed by combining the header and data fields of the first sub-data field.

3. The access control policy generation method according to claim 2, characterized in that, The data fields for obtaining the first sub-data field based on the predicate sub-label include: In response to determining that the attribute name of the predicate sub-tag meets the preset conditions, the attribute name of the predicate sub-tag is converted into a combination of a string and preset symbols; The combination of the string and the preset symbol is used as the data field of the first sub-data field.

4. The access control policy generation method according to claim 1, characterized in that, The step of obtaining the second sub-data field based on the rule label includes: Based on the attribute values ​​of the rule tags, determine the functional functions corresponding to the rule tags, as well as the usage conditions and combined conditions; Based on the function, the usage conditions, and the combination conditions, the second sub-data field is obtained through a preset conversion rule.

5. The access control policy generation method according to claim 1, characterized in that, The second access control policy also includes a policy header; the policy header includes a policy identifier and a combination algorithm identifier. The method for generating the strategy header includes: The policy identifier code is obtained based on the identifier code of the basic policy label; The combined algorithm identifier code is obtained based on the attribute values ​​of the rule tags.

6. The access control policy generation method according to claim 5, characterized in that, The policy header also includes a user identifier code; The method for generating the user identification code includes: Obtain the user information corresponding to the first access control policy; Based on the user information, a user identification code is obtained; the user identification code is a symbol sequence used to uniquely identify the corresponding user.

7. The access control policy generation method according to claim 1, characterized in that, The method further includes: The second access control policy is uploaded to the access control chain; the access control chain is used to store the access control policy and the corresponding uploaded data.

8. An access control decision method, characterized in that, include: Obtain access requests and attribute information; The corresponding access control policy is invoked based on the access request; The access control policy is obtained by the access control policy generation method according to any one of claims 1-7; Based on the attribute information and the access control policy, an access control decision is made to obtain the access control decision result; The upload data corresponding to the access request is returned based on the access control decision result.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the method as described in any one of claims 1 to 7.

Images