Static permission calculation method based on full life cycle of product

Abstract

The invention relates to a product full life cycle-based static permission calculation method, which comprises the following steps of: (1) establishing a static permission configuration parameter, and determining an access control strategy; (2) receiving data of which the permission needs to be verified, and extracting permission feature attributes; (3) finding a matching permission feature access control strategy in the configuration parameters in the step (1); (4) according to the current request participant, the authority owned by the participant is calculated; and (5) comparing the authority calculated in the step (4) with the required authority, and determining whether the participant has the corresponding authority of the data or not. According to the method, the problem of dividing different permissions in different life cycle stages in the whole life cycle process of the product can be effectively solved, so that the permissions of the data in the whole life cycle process of the product are managed and controlled.

Description

Technical Field

[0001] The present invention relates to a method for calculating static permissions based on the entire life cycle of a product, and belongs to the technical field of product life cycle management and permission control. Background Art

[0002] With the increasing complexity of products and the development of information technology, data management and permission control throughout the product life cycle have become important challenges for enterprises. Traditional permission management methods are often limited to specific stages or specific user groups, lacking comprehensive consideration of the entire product life cycle, leading to increased risks such as data leakage and misoperation. At the same time, as the product life cycle is extended, data access requirements at different stages are also constantly changing, requiring a flexible and efficient permission calculation method to adapt to these changes.

[0003] Currently, there are many permission management solutions on the market, but most of them focus on dynamic permission allocation, that is, making permission judgments based on preset rules when users request. However, this approach may face performance bottlenecks and security risks when processing large-scale data and complex business logic. Therefore, it is necessary to develop a product that can analyze data access requirements at all stages of the product life cycle in advance and formulate static permission allocation strategies to improve the efficiency and security of permission management. Summary of the invention

[0004] In order to solve the above problems, the present invention discloses a static permission calculation method based on the entire life cycle of a product, and its specific technical solution is as follows: A method for calculating static permissions based on the entire product life cycle includes the following steps: Step (1) Establish static permission configuration parameters and determine access control policies; Step (2) receiving the data that currently needs to verify the authority and extracting the authority characteristic parameters; Step (3) finding a matching permission feature access control policy in the static permission configuration parameters of step (1) according to the permission feature parameters of step (2); Step (4) Calculate the permissions that the participant has based on the current requesting participant; Step (5) compares the permissions calculated in step (4) with the permissions required by the requesting participant to confirm whether the participant has the corresponding permissions for the data.

[0005] Furthermore, the step (1) specifically includes: Step (1.1) establishing a type configuration parameter set, wherein the type configuration parameter set includes type configuration parameters and their type subordination relationships; Step (1.2) establish a set of lifecycle configuration parameters; Step (1.3) establishing a domain parameter configuration set, wherein the domain parameter configuration set includes domain parameters and their subordinate relationships; Step (1.4) selects the corresponding type, life cycle and domain according to the collections in step (1.1), step (1.2) and step (1.3), and configures the access control policy for each participant.

[0006] Furthermore, the step (2) specifically includes: extracting permission characteristic parameters from the data that needs to verify permissions, the permission characteristic parameters including type, life cycle state and domain, and extracting participant objects.

[0007] Furthermore, the step (3) specifically includes: matching the access control policy that adapts to the rules according to the permission feature parameters and their subordinate relationships, wherein the permission features of the data that currently need to verify the permissions meet the following conditions: type∈type configuration parameter set, domain∈domain parameter configuration set, life cycle state∈life cycle configuration parameter set.

[0008] Furthermore, the step (4) specifically includes: Step (4.1) classifies the matched access control policy permissions according to participant type and permission type; Step (4.2) merges the permissions according to the result of step (4.1), including: Step (4.2.1) converts the configured access control policy permissions into a binary array, where each bit represents a permission, and obtains permissions p1, p2, p3...pn; Step (4.2.2) replaces step (4.2.1) by Merge the permissions of grant, deny and absolute deny separately to obtain the merged user grant permission up, deny permission un, and absolute deny permission ua, and the merged group grant permission gp, deny permission gn, and absolute deny permission ga; Step (4.2.3) is based on the grouped and classified permission data obtained in step (4.2.2), and the permission pm of the participant is calculated according to the principle that absolute denial is greater than denial and grant, and user is greater than group. , that is, group deny is greater than group grant, user grant is greater than group deny, user deny is greater than user grant, and absolute deny is greater than all others.

[0009] Furthermore, the step (5) specifically includes: performing a bitwise AND operation on the permission pm of the participant obtained by the operation in step (4) and the permission pz to be verified to obtain result, where result = pm&pz, i.e., performing a bitwise AND operation on the permission possessed and the permission required; if result = pz, it means that the permission is granted, otherwise it means that the permission is not granted.

[0010] Furthermore, the participant types include users, groups, organizations and roles.

[0011] Furthermore, the permission types include grant, deny and absolute deny.

[0012] The beneficial effects of the present invention are: The present invention realizes static allocation and management of access rights to product-related data by analyzing and integrating information at all stages of the product life cycle, from design, production, use to disposal, thereby ensuring the security and compliance of information.

[0013] The present invention has significant progressive effects in improving management efficiency, enhancing security and compliance, promoting team collaboration and communication, reducing management costs and maintenance difficulty, and supporting decision-making and optimization.

[0014] The present invention can effectively solve the problem of authority division of different BOMs at different life cycle stages during the entire product life cycle, so that the authority of data during the entire product life cycle can be managed and controlled. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 It is a schematic diagram of the process of the present invention. DETAILED DESCRIPTION

[0016] The present invention is further explained below in conjunction with the accompanying drawings and specific embodiments. It should be understood that the following specific embodiments are only used to illustrate the present invention and are not used to limit the scope of the present invention.

[0017] Combined with Figure 1 It can be seen that the static permission calculation method based on the product life cycle includes the following steps: Step (1) Establish static permission configuration parameters and determine access control policies; Step (1.1) establishing a type configuration parameter set, wherein the type configuration parameter set includes type configuration parameters and their type subordination relationships; Step (1.2) establish a set of lifecycle configuration parameters; Step (1.3) establishing a domain parameter configuration set, wherein the domain parameter configuration set includes domain parameters and their subordinate relationships; Step (1.4) selects the corresponding type, life cycle and domain according to the collections in step (1.1), step (1.2) and step (1.3), and configures the access control policy for each participant.

[0018] Step (2) extracts permission characteristic parameters from the data that needs to verify permissions, the permission characteristic parameters include type, life cycle state and domain, and extracts participant objects. Permission characteristic parameters are parameters related to permissions that are specifically described along with business data.

[0019] Step (3) matches the access control policy that adapts to the rules according to the permission feature parameters and their subordinate relationships, where the permission features of the data that currently need to verify permissions meet the following conditions: type ∈ type configuration parameter set, domain ∈ domain parameter configuration set, life cycle state ∈ life cycle configuration parameter set.

[0020] Step (4) Calculate the permissions that the participant has based on the current requesting participant; Step (4.1) classifies the matched access control policy permissions according to participant type (user, group, organization, and role) and permission type (grant, deny, and absolutely deny); Step (4.2) merges the permissions according to the result of step (4.1), including: Step (4.2.1) converts the configured access control policy permissions into a binary array, where each bit represents a permission, and obtains permissions p1, p2, p3...pn; Step (4.2.2) replaces step (4.2.1) by Merge the permissions of grant, deny and absolute deny separately to obtain the merged user grant permission up, deny permission un, and absolute deny permission ua, and the merged group grant permission gp, deny permission gn, and absolute deny permission ga; Step (4.2.3) is based on the grouped and classified permission data obtained in step (4.2.2), and the permission pm owned by the participant is calculated according to the principle that absolute denial is greater than denial and greater than grant, and user is greater than group. The result of the calculated permission of the user for this data will be calculated and verified with the required permission later. , that is, the formula operation rules are: group rejection is greater than group grant, user grant is greater than group rejection, user rejection is greater than user grant, and absolute rejection is greater than all others.

[0021] Step (5) compares the permissions calculated in step (4) with the permissions required by the requesting participant to confirm whether the participant has the corresponding permissions for the data.

[0022] Furthermore, the step (5) specifically includes: calculating the permission pm of the participant obtained by the calculation in step (4) and pz to be verified, where pz is the permission value to be verified described in step 1, and obtaining result, result = pm&pz, that is, performing a bitwise AND operation on the permission possessed and the required permission; if result = pz, it means that the permission is granted, otherwise it means that the permission is not granted.

[0023] A specific application embodiment of the present invention is given below: Taking the product lifecycle management system (PLM) as an example, the lifecycle stages and permissions are set as follows: 1. Product project establishment and demand management stage Permission settings: Project Manager: Has the authority to create projects, define project scope, assign tasks, and approve requirements.

[0024] Marketing and Sales Team: Provide market demand information and have the right to review and comment on demand documents, but not the right to directly modify them.

[0025] Product Design Team: Receive and analyze requirements and prepare preliminary product concept designs, subject to review by the project manager.

[0026] 2. Product design and development stage Permission settings: Chief Designer: Responsible for the overall design direction and has the right to access and modify all design documents.

[0027] Design Engineer: Based on the division of labor, they have the authority to design their own modules, and any modifications must be reviewed by the chief designer.

[0028] Quality Engineer: Has the right to review design documents, participate in design reviews, and make suggestions for quality improvements.

[0029] 3. Process planning and production preparation stage Permission settings: Process Engineer: Responsible for developing the production process flow, with the right to access product design documents and modify process files.

[0030] Production planner: Develop production plans based on process documents and have the right to review relevant design and process documents.

[0031] Material management personnel: responsible for material procurement and inventory management, and has the right to view production plans and bills of materials.

[0032] 4. Manufacturing and quality control stage Permission settings: Production line workers: perform production operations according to the production plan and have access to documents and instructions related to the current production task.

[0033] Quality Inspector: Responsible for product quality inspection and has the right to review product inspection standards and inspection records.

[0034] Production Supervisor: Monitors production progress and quality and has access to all production-related documents and data.

[0035] The present invention can formulate a static permission allocation strategy by pre-analyzing the data access requirements at each stage of the product life cycle, thereby effectively managing the data permissions.

[0036] The above correspond to the permission feature domain, type, life cycle stage and participants respectively, and form a static permission configuration system through the setting of access control policies. When a participant initiates a corresponding permission application, the permission characteristics of the access object and the visitor information are extracted through the permission calculation method, and calculations are performed to finally obtain a conclusion on whether the permission is possessed.

[0037] For example, Zhang San belongs to the product design team in the team. According to the above configuration, Zhang San will have the permission to view data of the "demand" type in the life cycle stage of "product project establishment". At this time, if Zhang San wants to view a certain "demand" type of data through the system, the system will get a result of permission. If Zhang San wants to add a new demand data in the system, the system will get a result of rejection. If Zhang San is added to the role of "project manager", Zhang San will get the result of permission merging. In addition to being able to view the demand, he can also have other data permissions that the project manager has. Take another example of rejection. Assuming that in order to prevent the "quality inspector" role from tampering with the inspection standard, the "quality inspector" is not allowed to modify the data of the "product inspection standard" type, and the "production supervisor" role has the permission to modify. When Li Si belongs to both the "quality inspector" and "production supervisor" roles, he will have both the policy permissions of denying and allowing the data of the "product inspection standard" type. At this time, according to the principle of denying more than granting, the result calculated for Li Si is still a rejection.

[0038] It will be understood by those skilled in the art that, unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as generally understood by those skilled in the art to which this application belongs. It should also be understood that terms such as those defined in common dictionaries should be understood to have meanings consistent with the meanings in the context of the prior art, and will not be interpreted with idealized or overly formal meanings unless defined as herein.

[0039] Based on the above ideal embodiments of the present invention, the relevant staff can make various changes and modifications without departing from the technical concept of the present invention through the above description. The technical scope of the present invention is not limited to the contents of the specification, and its technical scope must be determined according to the scope of the claims.

Claims

1. A static permission calculation method based on the entire product life cycle, characterized in that: The following steps are involved: Step (1) Establish static permission configuration parameters and determine access control policies; Step (2) receiving the data that currently needs to verify the authority and extracting the authority characteristic parameters; Step (3) finding a matching permission feature access control policy in the static permission configuration parameters of step (1) according to the permission feature parameters of step (2); Step (4) Calculate the permissions that the participant has based on the current requesting participant; Step (5) compares the permissions calculated in step (4) with the permissions required by the requesting participant to confirm whether the participant has the corresponding permissions for the data.

2. The method for calculating static permissions based on the entire product life cycle according to claim 1 is characterized in that: The step (1) specifically includes: Step (1.1) establishing a type configuration parameter set, wherein the type configuration parameter set includes type configuration parameters and their type subordination relationships; Step (1.2) establish a set of lifecycle configuration parameters; Step (1.3) establishing a domain parameter configuration set, wherein the domain parameter configuration set includes domain parameters and their subordinate relationships; Step (1.4) selects the corresponding type, life cycle and domain according to the collections in step (1.1), step (1.2) and step (1.3), and configures the access control policy for each participant.

3. The method for calculating static permissions based on the entire product life cycle according to claim 1 is characterized in that: The step (2) specifically includes: extracting permission characteristic parameters from the data that needs to verify permissions, the permission characteristic parameters including type, life cycle state and domain, and extracting participant objects.

4. The method for calculating static permissions based on the entire product life cycle according to claim 1 is characterized in that: The step (3) specifically includes: matching the access control policy adapted to the rule according to the permission characteristic parameters and their subordinate relationships, wherein the permission characteristics of the data currently requiring permission verification meet the following conditions: type∈type configuration parameter set, domain∈domain parameter configuration set, life cycle state∈life cycle configuration parameter set.

5. The method for calculating static permissions based on the entire product life cycle according to claim 1 is characterized in that: The step (4) specifically includes: Step (4.1) classifies the matched access control policy permissions according to participant type and permission type; Step (4.2) merges the permissions according to the result of step (4.1), including: Step (4.2.1) converts the configured access control policy permissions into a binary array, where each bit represents a permission, and obtains permissions p1, p2, p3...pn; Step (4.2.2) replaces step (4.2.1) by Merge the three group permissions of grant, deny and absolute deny to obtain the merged user grant permission up, deny permission un, absolute deny permission ua, and the merged group grant permission gp, deny permission gn, absolute deny permission ga; Step (4.2.3) is based on the grouped and classified permission data obtained in step (4.2.2), and the permission pm of the participant is calculated according to the principle that absolute denial is greater than denial and grant, and user is greater than group. , that is, group deny is greater than group grant, user grant is greater than group deny, user deny is greater than user grant, and absolute deny is greater than all others.

6. The method for calculating static permissions based on the entire product life cycle according to claim 5 is characterized in that: The step (5) specifically includes: performing a bitwise AND operation on the permission pm of the participant obtained by the operation in step (4) and the permission pz to be verified to obtain result, result = pm & pz, that is, performing a bitwise AND operation on the permission possessed and the permission required; if result = pz, it means that the permission is granted, otherwise it means that the permission is not granted.

7. The method for calculating static permissions based on the entire product life cycle according to claim 5 is characterized in that: The participant types include users, groups, organizations, and roles.

8. The method for calculating static permissions based on the entire product life cycle according to claim 5 is characterized in that: The permission types include grant, deny, and absolute deny.

Images