A product lifecycle-based static permission calculation method

Abstract

The application relates to a product whole life cycle static permission calculation method, which comprises the following steps: (1) establishing a static permission configuration parameter and determining an access control strategy; (2) receiving data needing to be checked for permission and extracting permission characteristic attributes; (3) finding a matching permission characteristic access control strategy in the configuration parameter in step (1); (4) calculating the permission owned by a current request participant; and (5) comparing the permission calculated in step (4) with the required permission, and confirming whether the participant has the corresponding permission of the data. The application can effectively solve the problem of different permission division in different life cycle stages in the product whole life cycle process, so that the permission of data in the product whole life cycle process can be controlled.

Description

TECHNICAL FIELD

[0001] The present application relates to a product lifecycle-based static permission calculation method, belonging to the technical field of product lifecycle management and permission control. BACKGROUND

[0002] With the increase of product complexity and the development of information technology, data management and permission control in the product lifecycle 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 product lifecycle, leading to increased risks such as data leakage and misoperation. At the same time, with the extension of the product lifecycle, data access requirements at different stages are constantly changing, requiring a flexible and efficient permission calculation method to adapt to these changes.

[0003] Currently, there are various permission management solutions on the market, but most of them focus on dynamic permission allocation, i.e., making permission judgments based on pre-set rules when users request. However, this approach may face performance bottlenecks and security risks when dealing with large-scale data and complex business logic. Therefore, it is necessary to develop a product that analyzes data access requirements at each stage of the product lifecycle in advance and formulates static permission allocation strategies to improve the efficiency and security of permission management. SUMMARY

[0004] To solve the above problems, the present application discloses a product lifecycle-based static permission calculation method, the specific technical solution of which is as follows:

[0005] A product lifecycle-based static permission calculation method, comprising the following steps:

[0006] Step (1) Establish static permission configuration parameters to determine access control strategies;

[0007] Step (2) Receive data that needs to be checked for permission and extract permission feature parameters;

[0008] Step (3) Find matching permission feature access control strategies in the static permission configuration parameters of step (1) according to the permission feature parameters of step (2);

[0009] Step (4) Calculate the permissions of the participant according to the current request;

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

[0011] Further, step (1) specifically includes:

[0012] Step (1.1) establishes a type configuration parameter set, which includes type configuration parameters and their type dependencies;

[0013] Step (1.2) establishes a life cycle configuration parameter set;

[0014] Step (1.3) establishes a domain parameter configuration set, which includes domain parameters and their dependencies;

[0015] Step (1.4) selects corresponding types, life cycles and domains according to the sets in steps (1.1), (1.2) and (1.3), and configures respective access control policies for each participant.

[0016] Further, the step (2) specifically includes extracting permission feature parameters, including type, life cycle state and domain, from data requiring permission verification, and extracting participant objects.

[0017] Further, the step (3) specifically includes matching to an adaptive access control policy according to the permission feature parameters and their dependencies, wherein the permission features of the data currently requiring permission verification satisfy the following conditions: type ∈ type configuration parameter set, domain ∈ domain parameter configuration set, and life cycle state ∈ life cycle configuration parameter set.

[0018] Further, the step (4) specifically includes:

[0019] Step (4.1) classifies the matched access control policy permissions according to participant types and permission types;

[0020] Step (4.2) combines permissions according to the results of step (4.1), specifically including:

[0021] Step (4.2.1) converts the configured access control policy permissions into a binary array, with each bit representing a permission, to obtain permissions p1, p2, p3,..., pn;

[0022] Step (4.2.2) groups the permissions in step (4.2.1) by grants, denies and absolute denies, to obtain combined user granted permissions up, denied permissions un, absolute denied permissions an, and combined group granted permissions gp, denied permissions gn, and absolute denied permissions ga;

[0023] Step (4.2.3) calculates the permissions pm owned by the participant according to the grouped classification permission data obtained in step (4.2.2), in the order of absolute denial > denial > grant, user > 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.

[0024] Further, the step (5) specifically comprises: performing operation on the participant's permission pm obtained in the step (4) and the pz to be verified to obtain result, result = pm&pz, that is, performing bit AND operation on the permission and the required permission; if result = pz, it indicates that the permission exists, otherwise, it indicates that the permission does not exist.

[0025] Further, the participant type comprises user, group, organization and role.

[0026] Further, the permission type comprises grant, deny and absolute deny.

[0027] The present application has the following beneficial effects:

[0028] The present application realizes static allocation and management of product related data access permission by analyzing and integrating information in each stage of the product life cycle from design, production, use to abandonment, and ensures the safety and compliance of information.

[0029] The present application has remarkable progress effects in improving management efficiency, strengthening safety and compliance, promoting team collaboration and communication, reducing management cost and maintenance difficulty, and supporting decision-making and optimization.

[0030] The present application can effectively solve the problem of permission division in different life cycle stages and different BOMs in the product life cycle process, so that the permission of data in the product life cycle process is controlled. BRIEF DESCRIPTION OF DRAWINGS

[0031] Figure 1 is a flowchart of the present application. DETAILED DESCRIPTION

[0032] The present application will be further illustrated below in combination with the drawings and specific embodiments, and it should be understood that the following specific embodiments are only used to illustrate the present application and not to limit the scope of the present application.

[0033] In combination with the drawings, Figure 1 It can be seen that the present application based on product life cycle static permission calculation method comprises the following steps:

[0034] Step (1) establishes a static permission configuration parameter to determine an access control policy;

[0035] Step (1.1) establishes a type configuration parameter set, wherein the type configuration parameter set comprises type configuration parameters and type affiliation relationships;

[0036] Step (1.2) establishes a set of life cycle configuration parameters;

[0037] Step (1.3) establishes a set of domain parameter configurations, which includes domain parameters and their dependencies;

[0038] Step (1.4) configures each participant with their own access control policy according to the sets in steps (1.1), (1.2), and (1.3).

[0039] Step (2) extracts the permission feature parameters, including type, life cycle status, and domain, from the data that needs to be checked for permissions, and extracts the participant object. The permission feature parameters are specific parameters related to permissions that are transmitted with business data.

[0040] Step (3) matches the access control policy that adapts to the rules according to the permission feature parameters and their dependencies, where the permission features of the data that needs to be checked for permissions meet the following conditions: type ∈ type configuration parameter set, domain ∈ domain parameter configuration set, and life cycle status ∈ life cycle configuration parameter set.

[0041] Step (4) calculates the permissions that the current request participant has;

[0042] 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 absolute deny);

[0043] Step (4.2) merges the permissions according to the results of step (4.1), which includes:

[0044] Step (4.2.1) converts the configured access control policy permissions into a binary array, where each bit represents a permission, resulting in permissions p1, p2, p3,..., pn;

[0045] Step (4.2.2) groups the permissions in step (4.2.1) by grants, denials, and absolute denials, resulting in merged user grant permissions up, denial permissions un, and absolute denial permissions an, as well as merged group grant permissions gp, denial permissions gn, and absolute denial permissions ga;

[0046] Step (4.2.3) calculates the participant's permissions pm according to the grouped classification permission data obtained in step (4.2.2), with absolute denial greater than denial greater than grant, and user greater than group. The user's permission result obtained through calculation will be used in subsequent calculations and verifications with the required permissions. That is, the formula operation rule 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.

[0047] Step (5) compares the permission calculated in step (4) with the permission required by the request participant, and confirms whether the participant has the corresponding permission of the data.

[0048] Further, the step (5) specifically includes: performing operation on the permission pm of the participant obtained in step (4) and the pz to be verified, wherein the pz is the permission value to be verified described in step 1, to obtain result, result = pm & pz, that is, performing bit AND operation on the obtained permission and the required permission; if result = pz, it is indicated that the permission is available, otherwise, it is indicated that the permission is unavailable.

[0049] The following gives a specific application embodiment of the present application:

[0050] Taking a product whole life cycle management system (PLM) as an example, the life cycle stage and the permission setting are as follows:

[0051] 1. Product project establishment and demand management stage

[0052] Permission setting:

[0053] Project manager: has the permission of creating project, defining project scope, assigning task and approving demand.

[0054] Market and sales team: provides market demand information, has the right to view and comment on demand document, but has no direct modification right.

[0055] Product design team: receives and analyzes demand, prepares preliminary product concept design, but needs to be audited by project manager.

[0056] 2. Product design and development stage

[0057] Permission setting:

[0058] Chief designer: is responsible for overall design direction, has the right to access and modify all design documents.

[0059] Design engineer: has the permission of designing the module responsible by the design engineer according to the division of labor, and the modified design needs to be audited by the chief designer.

[0060] Quality engineer: has the right to view design document, participate in design review and propose quality improvement suggestions.

[0061] 3. Process planning and production preparation stage

[0062] Permission setting:

[0063] Process Engineer: Responsible for developing production process flow, has access to product design documents and modify process files.

[0064] Production Planner: Develops production plans based on process files, has access to relevant design and process documents.

[0065] Material Manager: Responsible for material procurement and inventory management, has access to production plans and bill of materials.

[0066] 4. Production Manufacturing and Quality Control Phase

[0067] Permission Settings:

[0068] Production Line Worker: Performs production operations according to production plans, has access to documents and instructions related to current production tasks.

[0069] Quality Inspector: Responsible for product quality inspection, has access to product inspection standards and inspection records.

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

[0071] The present application can analyze the data access requirements of each stage of the product life cycle in advance, develop a static permission allocation strategy, and thus manage the permissions of the data well.

[0072] The above respectively correspond to the permission characteristic domain, type, life cycle stage and participant, and form a static permission configuration system through the setting of access control strategies. When the 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 the conclusion of whether to have the permission is obtained through the operation.

[0073] For example, if Zhang San belongs to the product design team in the team, according to the above configuration, Zhang San will have the permission to view the data of the "demand" type in the life cycle stage of "product establishment", at this time if Zhang San wants to view the data of the "demand" type through the system, the system will get the allowed result, if Zhang San wants to add a demand data in the system, the system will get the result of refusal. If Zhang San is added to the role of "project manager", Zhang San will get the result of permission merging, he can not only view the demand but also has other data permissions of the project manager. Take another example of refusal, assume 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, the "production supervisor" role has the permission to modify, when Li Si belongs to both "quality inspector" and "production supervisor" roles, he will have the permission of refusal and allowance of the "product inspection standard" type data, at this time according to the principle of refusal greater than grant, the result calculated for Li Si is still refusal.

[0074] Those skilled in the art can understand that, unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. It should also be understood that terms such as those defined in a general dictionary should be understood to have a meaning consistent with the meaning in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless defined as such.

[0075] With the above ideal embodiments according to the present application as the inspiration, through the above description, relevant personnel can definitely make various changes and modifications without deviating from the scope of the technical idea of the present application. The technical scope of the present application is not limited to the content in the specification, and must be determined according to the scope of the claims.

Claims

1. A product lifecycle-based static permission calculation method, characterized in that, The method comprises the following steps: Step (1) establishing static permission configuration parameters, determining access control policies, specifically including: Step (1.1) establishing a type configuration parameter set, the type configuration parameter set including type configuration parameters and type dependencies; Step (1.2) establishing a life cycle configuration parameter set; Step (1.3) establishing a domain parameter configuration set, the domain parameter configuration set including domain parameters and dependencies; Step (1.4) selecting corresponding types, life cycles and domains according to the sets in steps (1.1), (1.2) and (1.3), and configuring respective access control policies for each participant; Step (2) receiving data requiring permission verification, extracting permission characteristic parameters, specifically including: extracting permission characteristic parameters from the data requiring permission verification, the permission characteristic parameters including types, life cycle states and domains, and extracting participant objects; Step (3) finding a matching permission characteristic access control policy in the static permission configuration parameters of step (1) according to the permission characteristic parameters of step (2), specifically including: matching an adaptive access control policy according to the permission characteristic parameters and their dependencies, wherein the permission characteristics of the data requiring permission verification meet the following conditions: type ∈ type configuration parameter set, domain ∈ domain parameter configuration set, and life cycle state ∈ life cycle configuration parameter set; Step (4) calculating the permissions owned by the participant according to the current request participant, specifically including: Step (4.1) classifying the matched access control policy permissions according to participant types and permission types; The participant types include users, groups, organizations and roles; The permission types include grant, deny and absolute deny; Step (4.2) merging the permissions according to the results of step (4.1), specifically including: Step (4.2.1) converting the configured access control policy permissions into a binary array, each bit representing a permission, obtaining permissions p1, p2, p3, …, pn; Step (4.2.2) will be performed by passing step (4.2.1). The three groups of permissions, which are distinguished as grant, deny, and absolute deny, are merged to obtain the merged user grant permission up, deny permission un, and absolute deny permission an, as well as the merged group grant permission gp, deny permission gn, and absolute deny permission ga. Step (4.2.3) calculates the permissions pm that the participant has from the group classification permissions data obtained from step (4.2.2) according to the rule of absolute deny greater than deny greater than grant, user greater than group, to obtain i.e. group deny greater than group grant, user grant greater than group deny, user deny greater than user grant, and absolute deny greater than all others; Step (5) comparing the permissions calculated in step (4) with the permissions required by the request participant to confirm whether the participant has the corresponding permissions of the data, specifically including: performing a bit AND operation on the permissions pm owned by the participant and the permissions pz requiring verification to obtain result, result = pm & pz; if result = pz, it means that the participant has the permissions, otherwise, it means that the participant does not have the permissions.

Images