Product data document management system and permission control method thereof

Abstract

The application discloses a product data document management system and a permission control method thereof, and belongs to the technical field of product data document management. The model of the management system is built based on a WindChill system platform. A minimization mechanism is arranged in the permission control method. Specifically, the method comprises the following steps: step 1, user personal information input and login verification; step 2, static permission allocation of the input user; and step 3, dynamic permission allocation of the user access control process of the static permission. The dynamic and static permission set is adjusted according to the business type, the granularity is maximally refined, the data resource in the whole life cycle can be prevented from being illegally rewritten, the correctness and consistency of the data are ensured, the temporary permission granting right is provided for the permission administrator, the data sharing in the maximum range of the data is ensured, the safety of the data is ensured, and the implementation effect is effectively improved.

Description

Technical Field

[0001] This invention relates to the field of product data management technology, and in particular to a product data document management system and its access control method. Background Technology

[0002] Security control technologies and authorization models in Product Data Management (PDM) systems are central to system security, significantly impacting the system's availability, usability, and security. Currently, the most classic access control models for PDM systems used by manufacturing companies both domestically and internationally include the following:

[0003] (1) Discretionary access control model

[0004] This control method is a strategy where a subject can proactively grant permissions to another subject or revoke permissions of subordinate subjects. Discretionary access control models typically use access control matrices or access control lists to store the decision-making strategies for subjects' requests to read, write, modify, and delete objects such as electronic documents and technical drawings within the system. Discretionary access control models are intuitive, easy to manage, offer flexible authorization, and facilitate data retrieval. Administrators can quickly find the permissions held by a user or the users or user groups with specific operation permissions, thus effectively managing permissions. However, its main drawbacks include low security, large amounts of data to manage, and difficulty in data maintenance.

[0005] (2) Mandatory Access Control Model

[0006] This control method determines whether a subject's operation on an object is permitted by comparing the pre-set, unchangeable security levels of the subject and object. When subject and object information is entered, the system assigns different security levels and assigns permission tags according to enterprise-defined rules; these permission tags cannot be modified by the user. The mandatory access control model offers high security, hierarchical security level management, unidirectional information flow, and effectively prevents virus attacks, providing special protection for sensitive data. However, its main drawbacks include difficulty in implementing permissions, a large workload for authorization management, administrator-only authorization, inflexible authorization, limited application scope, and unsuitability for systems with frequent permission changes.

[0007] (3) Role-based access control model

[0008] The basic idea of ​​this control method is to divide various roles according to the enterprise's organizational structure or projects. These roles have hierarchical and partial order relationships, establishing a three-dimensional system of user-role-permission, enabling indirect authorization from user to role and from role to permission. In addition to the concept of "role," this model also introduces concepts such as "session," "role inheritance," "dynamic separation of duties," and "static separation of duties." It is simple to implement, offers flexible authorization, and is highly secure. However, its main drawbacks include the inability to dynamically authorize, insufficient granularity of control, high maintenance costs, and the potential for "role explosion."

[0009] (4) Task-based access control model

[0010] The basic idea of ​​this control model is to define each node in each project and workflow within an enterprise as a task, and predefine different authorization policies for each task. At this point, permissions are in a protected state. When a task is triggered for execution, the corresponding permissions are activated and assigned to the user executing the task, thus achieving proactive access control where permissions dynamically change with the task's state. This model, when applied to workflow systems, associates permissions with tasks, offering flexible permission management and a high level of security. However, its main drawbacks include difficulty in permission management, lack of support for role-based hierarchical thinking, insufficient granularity of control, failure to consider authorization in static environments, and the fact that permissions are only activated within the task's lifecycle. Once the lifecycle ends, the user loses access to the resource and cannot view it again.

[0011] (5) Attribute-based access control model

[0012] The basic idea of ​​this model is to pre-describe each user, resource, and session environment in the access control system using "attributes." Then, authorization rules are predefined based on user attributes, resource attributes, and environment attributes. When a user requests access to a resource, the system searches for the corresponding policy set based on the current user, resource, and environment attribute set and determines whether the access request is allowed. This achieves dynamic access control based on fine-grained attributes. It offers good authorization dynamism, fine-grained control, simple implementation, and strong policy scalability. However, its main drawbacks include difficulties in attribute extraction and maintenance, and an excessive number of attributes leading to "rule explosion."

[0013] The shortcomings of the above five control models can be summarized as follows:

[0014] Discretionary access control model: low security and difficult data maintenance;

[0015] Mandatory access control model: difficult to implement, low activity;

[0016] Role-based access control model: cannot dynamically authorize access, and the control granularity is not fine enough;

[0017] Task-based access control model: insufficient control granularity and unsatisfactory static authorization;

[0018] Attribute-based access control models suffer from delayed authorization decisions and complex policy formulation. Summary of the Invention

[0019] The technical problem to be solved by the present invention is to provide a product data document management system and its access control method, which effectively solves the current situation where the security control strategy is inconsistent with the business and the system implementation success rate is low when enterprises import PDM.

[0020] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows:

[0021] A product data document management system includes a permission module, an attribute module, a workflow, a storage pool, a lifecycle state, and permission categories. The management system model is built on the WindChill system platform. Workflow, storage pool, permission categories, and lifecycle states are mutually mapped. The system permission control method includes a minimization mechanism to avoid conflicts between delegated attributes or other temporary permissions and the original role.

[0022] A further improvement of the technical solution of the present invention is that: the permission module includes an authorizing set and an access permission set block;

[0023] The authorized user set is a combination of enterprise users and role divisions. Based on valid user characteristic identifiers, it realizes static attribute permission matching between users and roles. At the same time, it can load dynamic attributes of data resources to realize automatic assignment of permissions for process tasks and automatic granting of temporary permissions for delegated tasks. The authorized user set includes a subject set.

[0024] The subject set refers to roles associated with organizational structure and projects within the enterprise;

[0025] The access permission set is a collection of all subject-related domains in the system, and also serves as a characteristic identifier for access permissions. It includes authorization algorithms and verification mechanisms for all stored data resources, processes, and program files.

[0026] A further improvement to the technical solution of the present invention is that the attribute module includes user attributes, resource attributes, and environment attributes;

[0027] The user attributes are used to describe the attributes of all registered users in the enterprise product data document management system;

[0028] The resource attributes are used to describe the attributes of the object; the environment attributes are used to describe the attributes of the environment in which the current access request session is located.

[0029] A further improvement of the technical solution of the present invention is that the user attributes, the resource attributes, and the environment attributes serve as the basis for formulating verification strategies and making authorization decisions.

[0030] A method for access control in a product data document management system, specifically including the following steps:

[0031] Step 1: User personal information entry and login verification;

[0032] Step 2: Assign static permissions to the entered users;

[0033] Step 3: Dynamic permission allocation for users with static permissions in the access control process.

[0034] A further improvement to the technical solution of this invention lies in the following steps: Step 1, user personal information entry and login verification, specifically includes the following steps:

[0035] Step 1.1 The system administrator enters the user's personal information into the user attributes of the user data unit;

[0036] Step 1.2 Develop a verification strategy based on user attributes, resource attributes, and environment attributes;

[0037] Step 1.3 The verification strategy combines username and password verification to effectively block unauthorized users.

[0038] A further improvement to the technical solution of this invention lies in the following: In step 2, the user static permission allocation algorithm is as follows:

[0039] User A's static attribute permission set is {(A, q1), (A, q2), ..., (A, qi)};

[0040] The team members of product container D have M roles set, and the static role permission set is {(D, m1), (D, m2), ..., (D, mj)};

[0041] The set of permissions associated with user A's assigned role in product container D is as follows:

[0042] {DKq1 1, DKq1 2, DKq1 3…, DKq1 m1}

[0043] {DKq2 1, DKq2 2, DKq2 3…, DKq2 m2}

[0044] ...

[0045] {DKqi 1, DKqi 2, DKqi 3…, DKqi mj}

[0046] After assigning roles to user A, the system iterates through the set of mapping permission relationships and outputs the corresponding permission matrix list, which is A's static permissions.

[0047] A further improvement of the technical solution of the present invention is that: in step 3, during the dynamic permission allocation process of the user access control process, the product data document management system grants permissions based on user role settings and does not actively create temporary delegated roles. However, the authorization mechanism makes authorization decisions based on user attributes, resource attributes and environmental attributes, so as to realize the automatic assignment of permissions for tasks in the workflow and the automatic granting of temporary permissions.

[0048] A further improvement to the technical solution of this invention lies in the following: the dynamic permission allocation algorithm for the user access control process is as follows:

[0049] The system sets a temporary access control policy set {Object1, Object2, ..., Objectx};

[0050] When user A receives a workflow task, the system checks whether user A has workflow task permissions by looking at user A's permission matrix list. If so, the dynamic permission allocation algorithm is terminated; otherwise, a temporary delegate attribute is automatically loaded for user A, and the system's access control policy Object is retrieved based on the delegate attribute, thereby granting dynamic permissions.

[0051] A further improvement of the technical solution of the present invention is that: in step 3, during the dynamic permission allocation process of the user access control process, the permission administrator has the right to grant temporary permissions.

[0052] The technological advancements achieved by this invention due to the adoption of the above technical solutions are as follows:

[0053] 1. This invention can achieve confidentiality control, ensure that data resources are not illegally accessed, and that unauthorized users and departments have no right to view the data information stored separately in the system, thus ensuring the security of the system.

[0054] 2. This invention can achieve integrity control, ensuring that data resources are not illegally rewritten throughout their entire lifecycle, especially during workflow approval processes, and will not be tampered with. It has complete historical data preservation and traceability functions, ensuring the correctness and compatibility of the data.

[0055] 3. This invention enables personalized control, allowing access to limited technical drawings and documents according to the roles of various technical personnel in the product development process within the enterprise. The access administrator has the function of granting temporary permissions, ensuring data security while maximizing data sharing.

[0056] 4. This invention enables access to limited technical drawings and documents according to the roles of various technical personnel in the product development process within an enterprise. The access administrator has the function of granting temporary permissions, ensuring data security while maximizing data sharing.

[0057] 5. The dynamic and static permission sets of this invention should be adjusted according to the business type, and the granularity should be as fine as possible to improve the implementation effect and better meet the current business management model and confidentiality requirements of enterprises. Attached Figure Description

[0058] Figure 1 This is a diagram of a product data document management system according to the present invention;

[0059] Figure 2 This is a flowchart of the access control method in this invention;

[0060] Figure 3 This is a schematic diagram of user personal information entry in this invention;

[0061] Figure 4 This is a schematic diagram of access control in this invention. Detailed Implementation

[0062] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments:

[0063] With the rapid development of science and technology, product updates are happening at an increasingly faster pace, and enterprises are placing increasingly higher demands on product delivery times and equipment quality. Therefore, the use of Product Management (PDM) systems to manage electronic documents such as product specifications, structures, drawings, and process procedures, as well as related processes and changes during product development and production, is becoming increasingly common. Its significant role in shortening product development time, improving development efficiency, and enhancing equipment consistency and reliability has been widely recognized by enterprises. However, PDM systems inevitably store and manage a large amount of sensitive data. If this information is leaked or stolen, it can cause irreparable losses to the enterprise. Therefore, it is essential to strengthen the security management of data within PDM systems.

[0064] like Figure 1 As shown, a product data document management system includes a permission module, an attribute module, a workflow (task), a storage pool (domain, document), a lifecycle status, and permission categories.

[0065] The permission module includes a set of authorized persons and a set of access permissions.

[0066] Authorizer set: Integrating enterprise users and role division, and based on valid user characteristic identifiers, it realizes static attribute permission matching between users and roles. At the same time, it can load dynamic attributes of data resources to realize automatic assignment of permissions for process tasks and automatic granting of temporary permissions for delegated tasks, ensuring fine-grained and flexible extensibility of access permissions. The authorizer set includes the subject set.

[0067] Subject set: The components of the authorized person set roles, which are generally related to the organizational structure and projects in the enterprise. In our enterprise, the roles in the PDM system are divided into system administrator, project manager, overall designer, experimental process engineer, machining process engineer, and various professional designers, etc.

[0068] The attribute module includes access permission sets, user attributes, resource attributes, and environment attributes.

[0069] Access Permission Set: The collection of all subject-related domains in the system, which also serves as a characteristic identifier for access permissions, similar to a software license file. It includes the authorization algorithms and verification mechanisms for all stored data resources, processes, programs, and other files.

[0070] The attribute module includes user attributes, resource attributes, and environment attributes.

[0071] User attributes: These describe the attributes of all registered users in the enterprise PDM system, including username, full name, email address, postal address, phone number, organization, etc.

[0072] Resource attributes: These describe the properties of an object. For example, a data document may have attributes such as data identifier, format, file size, creator, and version number, while a task may have attributes such as task status, task executor, and the project to which the task belongs.

[0073] Environment attributes: These describe the environment in which the current access request session takes place, such as date, time, IP address, and network security level. They work in conjunction with user attributes and object attributes to formulate policies and make authorization decisions.

[0074] A product data document management system model is built based on the WindChill system platform, such as... Figure 1 As shown, workflows (tasks), storage pools (domains, documents), permission categories, and lifecycle states are mapped to each other. The system permission control has a minimization mechanism to avoid conflicts between delegated attributes or other temporary permissions and the original roles, thus ensuring operability.

[0075] In the Windchill system, a domain differs from an internet domain. It is a management area used to define a set of management policies, such as access control, indexing, and notifications. When the Windchill system is deployed and installed, the root, / System, / User, and / Default domains are initially defined in the site context. These domains cannot be moved or deleted, but other domains can be defined in their context and associated with the root domain. Alternatively, domains can be nested by defining them as subdomains of another domain, thus achieving a "hierarchical structure" of domains first, and then defining the policies at each level of that structure.

[0076] like Figure 2 As shown, a method for access control in a product data document management system includes the following steps:

[0077] Step 1, User Personal Information Entry and Login Verification, specifically includes the following steps:

[0078] Step 1.1 The system administrator enters the user's personal information into the user attributes of the user data unit;

[0079] like Figure 3 As shown, the user unit includes user attributes and authentication strategies.

[0080] Step 1.2 Develop a verification strategy based on user attributes, resource attributes, and environment attributes;

[0081] Step 1.3 The verification strategy combines username and password verification to effectively block unauthorized users.

[0082] If the login is successful, the corresponding permissions are loaded; if the login fails, an error message will pop up, and the user will be prompted to re-enter their username and password.

[0083] Step 2: Assign static permissions to the entered users;

[0084] The product data document management system supports automatic loading of permissions based on user static attributes. This means that users are grouped into subject groups based on their attributes, and user-role static attribute permissions are matched according to resource and environment attributes. It also supports classifying users into roles based on the enterprise's organizational structure and project function attributes, allowing users to participate in various project teams with multiple identities and achieving differentiated user access permission management.

[0085] The specific algorithm for assigning static user permissions is as follows:

[0086] User A's static attribute permission set is {(A, q1), (A, q2), ..., (A, qi)};

[0087] The team members of product container D have M roles set, and the static role permission set is {(D, m1), (D, m2), ..., (D, mj)};

[0088] The set of permissions associated with user A's assigned role in product container D is as follows:

[0089] {DKq1 1, DKq1 2, DKq1 3…, DKq1 m1}

[0090] {DKq2 1, DKq2 2, DKq2 3…, DKq2 m2}

[0091] ...

[0092] {DKqi 1, DKqi 2, DKqi 3…, DKqi mj}

[0093] After assigning roles to user A, the system iterates through the set of mapping permission relationships and outputs the corresponding permission matrix list, which is A's static permissions.

[0094] Step 3: Dynamic permission allocation for the user access control process that obtains static permissions;

[0095] like Figure 4 As shown, in a permission control method for a product data document management system, access control refers to the system's ability to protect and deny access to various data resources in an information system when faced with unauthorized operational threats, using predetermined control rules and policies. This protects the security and integrity of data resources. Only authorized users who have correctly submitted and verified their identity to the system are allowed to access specific system data resources in the storage pool, thereby ensuring that the system is used within a legal scope. A standard access control system includes four elements: subject, object, permission, and decision policy.

[0096] In this context, the subject is the initiator of the access session, generally referring to all valid users, including all employees in the enterprise who are currently employed and have entered into the PDM system; the object is the bearer of the access session, typically referring to passive entities in the system storage pool such as electronic documents, controls, code, records, tables, database tables, and programs that can accept access requests; permission is a specific operation performed on the object in the workflow, such as editing a document, viewing a technical specification, deleting a model, or changing the BOM structure; and the decision policy is a set of access constraint rules that act as a bridge connecting the subject and the object, specifying whether the subject is allowed to operate on the object.

[0097] This product's data document management system grants permissions based on user role settings and does not actively create temporary delegated roles. However, the authorization mechanism makes authorization decisions based on user attributes, resource attributes, and environment attributes, realizing automatic assignment of permissions for tasks in the workflow and automatic granting of temporary permissions. This completes the dynamic permission allocation of the user access control process, ensuring the fine-grainedness and flexible scalability of access control policies.

[0098] The dynamic permission allocation algorithm for the user access control process is as follows:

[0099] The system sets a temporary access control policy set {Object1, Object2, ..., Objectx}, and the set elements include subjects (users and roles), time limits (status), operations, etc.

[0100] When user A receives a workflow task, the system checks user A's permission matrix to see if A has the necessary permissions for the workflow task. If so, the dynamic permission allocation algorithm terminates. If not, a temporary delegate attribute is automatically loaded for user A, and the system retrieves the access control policy Object set by the system based on the delegate attribute, thereby granting dynamic permissions.

[0101] In this product's data and document management system, the permissions administrator has the right to grant temporary permissions. Example

[0102] Example 1: User A is an illegal user of the system (including cases of not being registered or having an incorrect password).

[0103] Operation 1: User A enters the error message into the system login interface and clicks login;

[0104] Operation 2: The system enables the verification policy, checks the "username", "password" and other related information in the "user data unit". If no match is found, a login failure message will be displayed.

[0105] Operation 3: Return to the login window.

[0106] Example 2: User A is a legitimate user of the system, and his role in product container D is set as "Visitor" (Visitor's permissions are only "Browse", and he has no right to open, edit, modify, move, download, etc. of files).

[0107] Operation 1: User A enters the information into the system login interface and clicks login;

[0108] Operation 2: The system enables the verification policy, checks the "username", "password" and other related information in the "user data unit", finds the matching item and logs in successfully, and loads the corresponding permissions according to user A's administrative position, professional title level and other attributes;

[0109] Operation 3: User A enters product container D. The system iterates through the mapping permission relationship set and only finds the permission value corresponding to the role as "DKq2 3".

[0110] {DKq1 1, DKq1 2, DKq1 3…, DKq1 m1}

[0111] {DKq2 1, DKq2 2, DKq2 3…, DKq2 m2}

[0112] ...

[0113] {DKqi 1, DKqi 2, DKqi 3…, DKqi mj}

[0114] (Assuming DKq2 3 represents browsing), that is, only grant it "browse" permission;

[0115] Operation 4: User A can browse files in product container D without any obstacles, but when performing operations such as "open, edit, modify, move, download", the system will be blocked because the relevant mapped permissions have not been found.

[0116] Operation 5: User A obtains permissions such as "open, edit, modify, move, and download".

[0117] 5.1 User A does not change their "role"

[0118] ① User A directly requests the system administrator to grant "open, edit, modify, move, and download" permissions for files in product container D;

[0119] ② If the system administrator determines through business judgment that user A's request can be approved, then the system administrator will open the permission matrix list of user A in product container D, set temporary permissions, and grant the request permission; the temporary permissions can be revoked at any time.

[0120] {DKq1 1, DKq1 2, DKq1 3…, DKq1 m1}

[0121] {DKq2 1, DKq2 2, DKq2 3…, DKq2 m2}

[0122] ...

[0123] {DKqi 1, DKqi 2, DKqi 3…, DKqi mj}

[0124] 5.2 User A changes "role"

[0125] ① User A can directly apply to the system administrator or the "project leader" of product container D to change their corresponding role in order to obtain permissions such as "open, edit, modify, move, and download";

[0126] ② If the system administrator or the "project leader" of product container D determines through business judgment that user A's request can be approved, then user A will be moved directly from the "visitor" role queue to the "design engineer" role queue, thereby automatically changing the permission set corresponding to A, and then its permission matrix will be automatically updated.

[0127] Example 3: The comprehensive authorization mechanism of "hierarchical domain personalized authorization + static and dynamic integrated authorization" ensures data security.

[0128] Example background:

[0129] 1. Create a separate folder W within the product container. Folder W is the "storage pool". According to business definitions, folder W can only store component drawings and related technical documents designed by the company's major product engineers. Other assemblies, small parts, and standard parts can only be stored in other folders within the system.

[0130] 2. To ensure data security, business regulations stipulate that engineers from different disciplines cannot freely view component drawings and related technical documents designed by other engineers without prior approval or review.

[0131] Scenario 1: User A is a "major component engineer". The product drawings designed by User A need to be countersigned by User B, who is a "system engineer". During the countersigning process, the drawings are not open to other "system engineers" except User B.

[0132] Operation 1: The administrator or project manager sets personalized permissions for folder W at different levels, setting only the "Major Component Engineer" role to have permissions such as "Full Control (All), Browse, Read, Download, Modify, Modify Content, Modify Identifier, Modify Security Label, Create by Move, Set Status, Revision, Create New View Version, Change Domain, Change Context, Delete" for this folder, while other engineers only have "Browse" permissions;

[0133] Operation 2: User A initiates a co-signing workflow Object1 for a product drawing and selects User B at the co-signing process node;

[0134] Operation 3: When user B receives the workflow task, the system determines that user B, as an "assembly engineer," does not have permission to read the subject in the Object1 task and needs to dynamically delegate permissions temporarily. At this time, the system will traverse the access rules according to the subject set and grant range authorization to user B.

[0135] Operation 4: Workflow Object1 and storage pool folder W are mutually mapped, and their "access control rules" will vary depending on the lifecycle status of the technical document. In the "countersigning" process, only user B needs to obtain "read" permission; all other permissions are blocked.

[0136] Scenario 2: User C, whose role is "small component engineer", needs to temporarily borrow a product drawing created by user A, whose role is "large component engineer", when designing a product drawing.

[0137] The operation is the same as operation 5 in Example 2.

[0138] Scenario 3: Original user A's role was "Large Component Engineer". Later, due to a job adjustment, user A was responsible for the design of standard components and the role was changed to "Standard Component Engineer".

[0139] Operation 1: After a user role changes, the system administrator or project manager should promptly adjust the corresponding role in the product container;

[0140] Operation 2: The system retains the corresponding static permissions for the "creator" of resources and environments in "Resources and Environment Attributes", that is, the creator is permanently visible to the tasks he / she initiated in the work task area;

[0141] Operation 3: User A, under the current role, can only view the folder corresponding to "Standard Parts". Files in the original "Folder W" that were not created by the user have been blocked according to the "minimum permissions" principle set in the policy, ensuring data security.

[0142] In summary, this invention employs a dynamic and static permission set adjusted based on business type, maximizing granularity to ensure that data resources are not illegally rewritten throughout their entire lifecycle, especially during workflow approval processes, preventing tampering. It also features complete historical data preservation and traceability, guaranteeing data accuracy and compatibility. Furthermore, it allows for the review of limited technical drawings and documents according to the roles of various technical personnel in the enterprise's product development process. Permission administrators have the right to grant temporary permissions, ensuring data security while maximizing data sharing, effectively improving implementation results.

Claims

1. A product data document management system, comprising a permission module, an attribute module, a workflow, a storage pool, a lifecycle status, and permission categories, characterized in that: The management system model is built on the WindChill system platform, with workflows, storage pools, permission categories, and lifecycle states mapping to each other; The access control method of the product data document management system specifically includes the following steps: Step 1: User personal information entry and login verification; Step 2: Assign static permissions to the entered users; Step 3: Dynamic permission allocation for the user access control process that obtains static permissions; The system permission control method includes a minimization mechanism to avoid conflicts between delegated attributes or other temporary permissions and the original role. The minimization mechanism is as follows: during the dynamic permission allocation process of user access control, the product data document management system grants permissions based on user role settings and does not actively create temporary delegated roles. However, the authorization mechanism makes authorization decisions based on user attributes, resource attributes, and environmental attributes, thereby realizing automatic assignment of permissions for tasks in the workflow and automatic granting of temporary permissions. The dynamic permission allocation algorithm for the user access control process is as follows: The system sets a temporary access control policy set {Object1, Object2, ..., Objectx}, where the set elements include the subject, time limit, and operation. When user A receives a workflow task, the system checks whether user A has workflow task permissions by looking at user A's permission matrix list. If so, the dynamic permission allocation algorithm is terminated; otherwise, a temporary delegate attribute is automatically loaded for user A, and the access control policy Object set by the system is retrieved based on the delegate attribute, thereby realizing the granting of dynamic permissions. During the dynamic permission allocation process of user access control, the permission administrator has the right to grant temporary permissions.

2. The product data document management system according to claim 1, characterized in that: The permission module includes a set of authorized users and a set of access permissions. The authorized user set is a combination of enterprise users and role division. Based on the effective user feature identifier, it realizes the static attribute permission matching of user-role. At the same time, it can load the dynamic attributes of data resources to realize the automatic assignment of permissions for process tasks and the automatic granting of temporary permissions for delegated tasks. The set of authorized persons includes the set of subjects; The subject set refers to roles associated with organizational structure and projects within the enterprise; The access permission set is a collection of all subject-related domains in the system, and also serves as a characteristic identifier for access permissions. It includes authorization algorithms and verification mechanisms for all stored data resources, processes, and program files.

3. The product data document management system according to claim 1, characterized in that: The attribute module includes user attributes, resource attributes, and environment attributes; The user attributes are used to describe the attributes of all registered users in the enterprise product data document management system; The resource attributes are used to describe the attributes of the object; the environment attributes are used to describe the attributes of the environment in which the current access request session is located.

4. A product data document management system according to claim 3, characterized in that: The user attributes, resource attributes, and environment attributes serve as the basis for formulating verification strategies and making authorization decisions.

5. A product data document management system according to claim 1, characterized in that: Step 1, which involves user personal information entry and login verification, specifically includes the following steps: Step 1.1 The system administrator enters the user's personal information into the user attributes of the user data unit; Step 1.2 Develop a verification strategy based on user attributes, resource attributes, and environment attributes; Step 1.3 The verification strategy combines username and password verification to effectively block unauthorized users.

Images