A search platform object level data permission management method for a non-uniform permission system and multi-source data

Abstract

The application discloses a search platform object-level data permission management method for a non-uniform permission system and multi-source data, which sequentially comprises classification of multi-source data collectable by a search platform, establishment of search platform permission data standard specification, multi-source data permission requirement analysis, data source permission data processing, search platform target permission data processing, search platform target permission data collection, search platform knowledge production, search platform user permission configuration and personnel authentication in a search request; the method solves the problem that a permission model based on RBAC in the prior art cannot adapt to object-level data permission management requirements in a non-uniform permission system and a multi-data-source enterprise search platform, realizes compatibility of data permission management of different data sources, different permission systems and differentiated organization mechanisms, and the granularity of search platform data permission management reaches the object level.

Description

Technical Field

[0001] This invention belongs to the field of data permission management technology, and in particular relates to an object-level data permission management method for search platforms with non-unified permission systems and multi-source data. Background Technology

[0002] Enterprise production and operation activities are often accompanied by strict data access control. Search platforms that only manage object-level data permissions through roles can lead to an uncontrollable number of roles, making it difficult for system administrators to effectively manage the large number of roles generated by numerous data sources through manual or technical means. Different business systems generate different permission systems in actual business operations, and the same person may assume different responsibilities in different business systems and exist in different organizations, possibly even a virtual organization unique to a particular system. The original data and data permissions of data sources are constantly changing with business development. This requires search platforms that collect this multi-source data to synchronize these changes in a timely manner and respond to them with their own permission management capabilities, which also places higher demands on the permission management of search platforms. For permission management of multi-source data within a single search platform under a non-unified permission system, existing technical solutions mostly use simple RBAC permission models to implement access control. These technologies are usually based on role control to determine whether a certain type of user has access to a certain type of data, which has the following drawbacks:

[0003] 1. Traditional access control on search platforms is coarse-grained, resulting in significant discrepancies with actual access control management of data sources. This patent provides an object-level access control capability that enables a one-stop unified enterprise search application to meet granular access control requirements with an acceptable management workload, achieving a access control experience largely consistent with the data source.

[0004] 2. Inability to support complex organizational structures across multiple data sources. Existing search platform permission systems are based on only a single organizational structure. The unique organizational structures under different data sources can easily lead to management chaos and high maintenance costs for a single organizational structure. This patent addresses this by using automated scripts to accommodate the diverse data permission management requirements of different organizational structures across various data sources.

[0005] 3. Weak ability to detect updates to data permissions at the object level of the data source. Existing search platforms' permission management granularity and methods differ to some extent from the actual data permissions of the data source, and the complexity of permission updates increases significantly with the number and volume of data sources connected to the platform. This patent achieves periodic updates of permission data by automatically collecting the latest permission data through periodic tasks.

[0006] Therefore, it is necessary to design an object-level data permission management method for search platforms with non-uniform permission systems and multi-source data to solve the above problems. Summary of the Invention

[0007] The technical problem to be solved by the present invention is to provide a method for object-level data permission management in search platforms with non-unified permission systems and multi-source data. This method aims to solve the problem that the permission model based on RBAC used in the prior art cannot meet the requirements of object-level data permission management in enterprise search platforms with non-unified permission systems and multiple data sources.

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

[0009] A method for object-level data permission management in a search platform with non-uniform permission systems and multi-source data includes the following steps:

[0010] S1, classifying multi-source data that can be collected by the search platform:

[0011] Based on data characteristics and data relationships, the multi-source data that the search platform can collect is classified into non-relational data and relational data. Non-relational data includes structured data and unstructured data, while relational data includes structured and unstructured relational data, and unstructured and unstructured relational data.

[0012] S2, establishes standard specifications for search platform permission data:

[0013] Establish object-level data permission standards for the search platform and a data source permission logic relationship collection table;

[0014] S3, Analysis of Multi-Source Data Access Requirements:

[0015] Analyze the data in the data source that has search requirements and its original data permissions. Referring to the data type of S1, divide the business data scope of the data source to be connected to the search platform, as well as the data classification and knowledge definition corresponding to the business data.

[0016] For the business data to be integrated into the search platform, refer to S2 and organize the data source data permission logic relationship collection table according to the knowledge definition;

[0017] S4, Data source permission data processing:

[0018] Based on the knowledge definitions outlined in S3 and the corresponding data source permission logic relationship collection table, primary object-level permission data is periodically generated using data processing tools;

[0019] S5, Search Platform Target Permission Data Processing:

[0020] The data processing component processes and integrates the primary object-level permission data of the data source formed by S4 to form the target object-level permission data of the data source. The target object-level permission data of the data source conforms to the object-level data permission standard of the search platform in S2.

[0021] S6, the search platform collects target permission data:

[0022] Based on the knowledge definition formed by S3, the corresponding knowledge categories are configured on the search platform management terminal, and the corresponding periodic data collection tasks are configured for each knowledge category to periodically collect the target permission data produced by the big data platform to the search platform.

[0023] S7, a search platform for knowledge production;

[0024] S8, Search Platform User Permission Configuration;

[0025] S9, User authentication in search requests:

[0026] The authentication process in the search request process is divided into two stages: query scope determination and object-level data permission determination.

[0027] Preferably, in step S1, the structured data includes transaction data, which is generated in business processes and represents records of business events, and is logically expressed and implemented in a two-dimensional table structure.

[0028] Unstructured data refers to data that does not have a predefined model or is not organized in a predefined way. In search platforms, it mainly includes document data, image data, and video data. The main formats of document data are TXT, WORD, EXCEL, PDF, and PPT; the main formats of image data are JPG, PNG, PSD, AI, CRD, TIF, SVG, WEBP, and HEIC; and the main formats of video data are MP4, FLV, AVI, and WMV.

[0029] Related data refers to the relationship between a single piece of data and its direct or indirect related data, representing the business logic connection between different data. In search platforms, related data mainly consists of structured and unstructured related data, and unstructured and unstructured related data. A single piece of data can be associated with one or more related pieces of data.

[0030] Preferably, in step S2, the search platform object-level permission standards include business data permission standards and personnel permission standards;

[0031] The business data permission standard includes seven necessary fields: business primary key, knowledge code, permission scenario 1, permission scenario 2, permission scenario 3, permission scenario 4, and permission scenario 5. The personnel permission standard includes six necessary fields: user account, knowledge code, permission scenario 1, permission scenario 2, permission scenario 3, and permission scenario 4.

[0032] The data source permission logic relationship collection table includes a personnel organization relationship table, a data permission logic table, and a personnel permission logic table; the personnel organization relationship table includes an organization table and a user table; organizations include physical organizations and virtual organizations, and the organization table includes organization primary key, organization code, organization name, organization type, and organization path; the user table includes user account, organization code, and organization path;

[0033] The data permission logic table includes a business organization table and a business permission association table; the business organization table includes a business primary key, organization code, and organization path; the business permission association table includes a business primary key, knowledge code, permission scenario 1, permission scenario 2, permission scenario 3, permission scenario 4, and permission scenario 5.

[0034] The personnel permission logic table includes user account, knowledge code, permission scenario 1, permission scenario 2, permission scenario 3 and permission scenario 4.

[0035] Preferably, in step S3, the knowledge definition is configured according to the required attributes for structured data. The required attributes should include the attributes used to build the index and the attributes required for data display. Each data source sorts out the organizational relationship table corresponding to the data source based on the actual organizational structure within the system.

[0036] Based on the knowledge definition, the data source permission logical relationship collection table is organized and compiled. The data permission logical table is organized using object-level data under the knowledge definition as the basic permission unit, and different association methods are selected as needed, specifically including:

[0037] Method 1: Associate the permission unit with one or more users or one or more organizations;

[0038] Method 2: Associate the permission unit with one or more organizational paths and specify the direction of permission extension. The direction of extension includes extending to the upper-level node, extending to the lower-level node, and extending to the same-level node.

[0039] For the analysis of the user permission logic table, the analysis work is divided into two stages, with the user as the basic permission unit:

[0040] The first phase involves determining whether the user has the data permissions for the specified knowledge definition.

[0041] In the second phase, users with specific knowledge definition data permissions can choose different association methods as needed. These association methods include:

[0042] Method 1 involves associating a user with one or more organizations;

[0043] Method 2 involves associating a user with one or more organizational paths and specifying the direction of permission extension, which can include extension to higher-level nodes, extension to lower-level nodes, and extension to nodes at the same level.

[0044] Preferably, in step S4, for each data source, referring to the personnel organization relationship table sorted out in S3, the corresponding detailed organization data and detailed personnel data of the data source are periodically generated by using SQL or SPARK_SQL script through the source database or big data platform data processing component.

[0045] For each type of knowledge defined in S3 for each data source, the content of the data collection table is collected according to the data permission logic relationship of the corresponding data source. Through the source database or big data platform data processing component, the business organization table, business permission association table and personnel permission logic table containing object-level detailed permission data are periodically generated using SQL or SPARK_SQL scripts. During the data processing, the encoding of organization, business, personnel and knowledge, as well as the primary key, are standardized and unique.

[0046] Preferably, in step S5, based on the target permission data standard of the search platform in S2, a SPARK_SQL script is compiled through a big data platform to complete the generation of permission scenario data, integration of business permission data, integration of personnel permission data, and data quality verification. The combined processing script configures the operation rules and periodically generates the target object-level permission data of the data source.

[0047] In the integration of business permission data, for each knowledge definition, the business detail data and business permission data are integrated at the object level, and the update time of business data and the update time of permission data are recorded by two timestamp fields respectively.

[0048] In the process of integrating personnel permission data, personnel permission data from various data sources and knowledge categories are integrated into a single data table.

[0049] Redundant data is filtered out through data quality verification to ensure that object-level business and permission data can be generated normally.

[0050] Preferably, in step S6, for unstructured data, the update of unstructured data is decoupled from the update of its corresponding permission data to improve the efficiency of permission data updates; when the search platform collection task determines that only permission data is updated, a separate permission data update task is triggered.

[0051] Preferably, in step S7, the specific method for knowledge production on the search platform is as follows:

[0052] Based on the knowledge categories configured in S6, corresponding streaming knowledge production tasks are configured on the search platform to process the periodically collected target permission data into the platform's knowledge base.

[0053] Preferably, in step S8, the specific method for configuring user permissions on the search platform is as follows:

[0054] For each data source, a corresponding role is configured on the search platform. Based on the system-level permission scope formed by S3, the role is associated with the corresponding organization or person, and the role status is activated.

[0055] Preferably, in step S9, when a user initiates a search request, the range of data sources that the user can access is first defined according to the permissions granted in S8, then the range of knowledge definitions under the data source is defined according to the personnel permission table, and finally the permission fields in the personnel table are matched with the permission fields in the data table. When any pair of fields has matching data, the user has the right to access the corresponding object-level data.

[0056] The retrieval of search content and the determination of object-level permissions are carried out simultaneously. When a row of data meets both the conditions for authentication and content retrieval, the object-level data is returned as the search result.

[0057] Furthermore, the permission fields in the personnel table include permission scenario 1, permission scenario 2, permission scenario 3, permission scenario 4, and user account; the permission fields in the data table include permission scenario 1, permission scenario 2, permission scenario 3, permission scenario 4, and permission scenario 5.

[0058] The beneficial effects of this invention are as follows:

[0059] 1. In this method, the granularity of data permission management on the search platform reaches the object level and is compatible with different data sources, different permission systems, and differentiated organizational structures. It can meet the requirement that data from the data source can still be subject to fine-grained permission management after entering the search platform, and achieve that the search recall results of different users under the same search query from the same data source are not completely consistent and are consistent with the data permissions of the data source.

[0060] 2. Data permissions in this method can be updated periodically. Through automated data processing and data acquisition tools, data permissions are updated periodically, ensuring that changes in data permissions from the data source can still be synchronized to the search platform, thus ensuring that data permissions for each data source within the search platform are always consistent with those of the data source.

[0061] 3. The workload of object-level data permission management and maintenance is controllable in this method. Based on achieving object-level permission control compatible with multiple data sources, the workload of system administrators is greatly reduced through program automation. As the platform's maintenance time, the number of data sources, and the amount of data increase, the workload of system administrators does not increase significantly and remains controllable and operable. Attached Figure Description

[0062] Figure 1 This is a schematic diagram of the process of the present invention;

[0063] Figure 2 This is a schematic diagram of the permission structure of the search platform in this invention. Detailed Implementation

[0064] Example 1:

[0065] like Figure 1 As shown, a method for object-level data permission management in a search platform with non-uniform permission systems and multi-source data includes the following steps:

[0066] S1, classifying multi-source data that can be collected by the search platform:

[0067] Based on data characteristics and data relationships, the multi-source data that the search platform can collect is classified into non-relational data and relational data. Non-relational data includes structured data and unstructured data, while relational data includes structured and unstructured relational data, and unstructured and unstructured relational data.

[0068] S2, establishes standard specifications for search platform permission data:

[0069] Establish object-level data permission standards for the search platform and a data source permission logic relationship collection table;

[0070] S3, Analysis of Multi-Source Data Access Requirements:

[0071] Analyze the data in the data source that has search requirements and its original data permissions. Referring to the data type of S1, divide the business data scope of the data source to be connected to the search platform, as well as the data classification and knowledge definition corresponding to the business data.

[0072] For the business data to be integrated into the search platform, refer to S2 and organize the data source data permission logic relationship collection table according to the knowledge definition;

[0073] S4, Data source permission data processing:

[0074] Based on the knowledge definitions outlined in S3 and the corresponding data source permission logic relationship collection table, primary object-level permission data is periodically generated using data processing tools;

[0075] S5, Search Platform Target Permission Data Processing:

[0076] The data processing component processes and integrates the primary object-level permission data of the data source formed by S4 to form the target object-level permission data of the data source. The target object-level permission data of the data source conforms to the object-level data permission standard of the search platform in S2.

[0077] S6, the search platform collects target permission data:

[0078] Based on the knowledge definition formed by S3, the corresponding knowledge categories are configured on the search platform management terminal, and the corresponding periodic data collection tasks are configured for each knowledge category to periodically collect the target permission data produced by the big data platform to the search platform.

[0079] S7, a search platform for knowledge production;

[0080] S8, Search Platform User Permission Configuration;

[0081] S9, User authentication in search requests:

[0082] The authentication process in the search request process is divided into two stages: query scope determination and object-level data permission determination.

[0083] Preferably, in step S1, the structured data includes transaction data, which is generated in business processes and represents records of business events, and is logically expressed and implemented in a two-dimensional table structure.

[0084] Unstructured data refers to data that does not have a predefined model or is not organized in a predefined way. In search platforms, it mainly includes document data, image data, and video data. The main formats of document data are TXT, WORD, EXCEL, PDF, and PPT; the main formats of image data are JPG, PNG, PSD, AI, CRD, TIF, SVG, WEBP, and HEIC; and the main formats of video data are MP4, FLV, AVI, and WMV.

[0085] Related data refers to the relationship between a single piece of data and its direct or indirect related data, representing the business logic connection between different data. In search platforms, related data mainly consists of structured and unstructured related data, and unstructured and unstructured related data. A single piece of data can be associated with one or more related pieces of data.

[0086] Preferably, in step S2, the search platform object-level permission standards include business data permission standards and personnel permission standards;

[0087] The business data permission standard includes seven necessary fields: business primary key, knowledge code, permission scenario 1, permission scenario 2, permission scenario 3, permission scenario 4, and permission scenario 5. The personnel permission standard includes six necessary fields: user account, knowledge code, permission scenario 1, permission scenario 2, permission scenario 3, and permission scenario 4.

[0088] The data source permission logic relationship collection table includes a personnel organization relationship table, a data permission logic table, and a personnel permission logic table; the personnel organization relationship table includes an organization table and a user table; organizations include physical organizations and virtual organizations, and the organization table includes organization primary key, organization code, organization name, organization type, and organization path; the user table includes user account, organization code, and organization path;

[0089] The data permission logic table includes a business organization table and a business permission association table; the business organization table includes a business primary key, organization code, and organization path; the business permission association table includes a business primary key, knowledge code, permission scenario 1, permission scenario 2, permission scenario 3, permission scenario 4, and permission scenario 5.

[0090] The personnel permission logic table includes user account, knowledge code, permission scenario 1, permission scenario 2, permission scenario 3 and permission scenario 4.

[0091] Preferably, in step S3, the knowledge definition is configured according to the required attributes for structured data. The required attributes should include the attributes used to build the index and the attributes required for data display. Each data source sorts out the organizational relationship table corresponding to the data source based on the actual organizational structure within the system.

[0092] Based on the knowledge definition, the data source permission logical relationship collection table is organized and compiled. The data permission logical table is organized using object-level data under the knowledge definition as the basic permission unit, and different association methods are selected as needed, specifically including:

[0093] Method 1: Associate the permission unit with one or more users or one or more organizations;

[0094] Method 2: Associate the permission unit with one or more organizational paths and specify the direction of permission extension. The direction of extension includes extending to the upper-level node, extending to the lower-level node, and extending to the same-level node.

[0095] For the analysis of the user permission logic table, the analysis work is divided into two stages, with the user as the basic permission unit:

[0096] The first phase involves determining whether the user has the data permissions for the specified knowledge definition.

[0097] In the second phase, users with specific knowledge definition data permissions can choose different association methods as needed. These association methods include:

[0098] Method 1 involves associating a user with one or more organizations;

[0099] Method 2 involves associating a user with one or more organizational paths and specifying the direction of permission extension, which can include extension to higher-level nodes, extension to lower-level nodes, and extension to nodes at the same level.

[0100] Preferably, in step S4, for each data source, referring to the personnel organization relationship table sorted out in S3, the corresponding detailed organization data and detailed personnel data of the data source are periodically generated by using SQL or SPARK_SQL script through the source database or big data platform data processing component.

[0101] For each type of knowledge defined in S3 for each data source, the content of the data collection table is collected according to the data permission logic relationship of the corresponding data source. Through the source database or big data platform data processing component, the business organization table, business permission association table and personnel permission logic table containing object-level detailed permission data are periodically generated using SQL or SPARK_SQL scripts. During the data processing, the encoding of organization, business, personnel and knowledge, as well as the primary key, are standardized and unique.

[0102] Preferably, in step S5, based on the target permission data standard of the search platform in S2, a SPARK_SQL script is compiled through a big data platform to complete the generation of permission scenario data, integration of business permission data, integration of personnel permission data, and data quality verification. The combined processing script configures the operation rules and periodically generates the target object-level permission data of the data source.

[0103] In the integration of business permission data, for each knowledge definition, the business detail data and business permission data are integrated at the object level, and the update time of business data and the update time of permission data are recorded by two timestamp fields respectively.

[0104] In the process of integrating personnel permission data, personnel permission data from various data sources and knowledge categories are integrated into a single data table.

[0105] Redundant data is filtered out through data quality verification to ensure that object-level business and permission data can be generated normally.

[0106] Preferably, in step S6, for unstructured data, the update of unstructured data is decoupled from its corresponding permission data; when the search platform collection task determines that only permission data is updated, a separate permission data update task is triggered.

[0107] Preferably, in step S7, the specific method for knowledge production on the search platform is as follows:

[0108] Based on the knowledge categories configured in S6, corresponding streaming knowledge production tasks are configured on the search platform to process the periodically collected target permission data into the platform's knowledge base.

[0109] Example 2:

[0110] like Figure 2 As shown, the specific method for configuring user permissions on the search platform in step S8 is as follows:

[0111] For each data source, a corresponding role is configured on the search platform. Based on the system-level permission scope formed by S3, the role is associated with the corresponding organization or person, and the role status is activated.

[0112] Preferably, in step S9, when a user initiates a search request, the range of data sources that the user can access is first defined according to the permissions granted in S8, then the range of knowledge definitions under the data source is defined according to the personnel permission table, and finally the permission fields in the personnel table are matched with the permission fields in the data table. When any pair of fields has matching data, the user has the right to access the corresponding object-level data.

[0113] The retrieval of search content and the determination of object-level permissions are carried out simultaneously. When the object-level data meets both the conditions for authentication and content retrieval, the object-level data is returned as a search result.

[0114] Furthermore, the permission fields in the personnel table include permission scenario 1, permission scenario 2, permission scenario 3, permission scenario 4, and user account; the permission fields in the data table include permission scenario 1, permission scenario 2, permission scenario 3, permission scenario 4, and permission scenario 5.

Claims

1. A method for object-level data permission management in a search platform for multi-source data with a non-uniform permission system, characterized in that: Includes the following steps: S1, classifying multi-source data that can be collected by the search platform: Based on data characteristics and data relationships, the multi-source data that the search platform can collect is classified into non-relational data and relational data. Non-relational data includes structured data and unstructured data, while relational data includes structured and unstructured relational data, and unstructured and unstructured relational data. S2, establishes standard specifications for search platform permission data: Establish object-level data permission standards for the search platform and a data source permission logical relationship collection table; the object-level data permission standards for the search platform include business data permission standards and personnel permission standards; the data source permission logical relationship collection table includes a personnel organization relationship table, a data permission logical table, and a personnel permission logical table; S3, Analysis of Multi-Source Data Access Requirements: Analyze the data in the data source that has search requirements and its original data permissions. Referring to the data type of S1, divide the business data scope of the data source to be connected to the search platform, as well as the data classification and knowledge definition corresponding to the business data. For the business data to be integrated into the search platform, refer to S2 and organize the data source data permission logic relationship collection table according to the knowledge definition; S4, Data source permission data processing: Based on the knowledge definitions outlined in S3 and the corresponding data source permission logic relationship collection table, primary object-level permission data is periodically generated using data processing tools; S5, Search Platform Target Permission Data Processing: The data processing component processes and integrates the primary object-level permission data of the data source formed by S4 to form the target object-level permission data of the data source. The target object-level permission data of the data source conforms to the object-level data permission standard of the search platform in S2. S6, the search platform collects target permission data: Based on the knowledge definition formed by S3, the corresponding knowledge categories are configured on the search platform management terminal, and the corresponding periodic data collection tasks are configured for each knowledge category to periodically collect the target permission data produced by the big data platform to the search platform. S7, knowledge production on the search platform, specifically through the following methods: Based on the knowledge categories configured in S6, the corresponding streaming knowledge production tasks are configured in the search platform to process the periodically collected target permission data into the platform knowledge base; S8, Search Platform User Permission Configuration; S9, User authentication in search requests: The authentication process in the search request process is divided into two stages: query scope determination and object-level data permission determination.

2. The method for object-level data permission management in a search platform for multi-source data with a non-unified permission system, as described in claim 1, is characterized in that... In step S1, the structured data includes transaction data, which is generated in business processes and represents records of business events. It is logically expressed and implemented in a two-dimensional table structure. Unstructured data refers to data that does not have a predefined model or is not organized in a predefined way. In search platforms, it mainly includes document data, image data, and video data. Related data refers to the relationship between a single piece of data and its directly or indirectly related data, representing the business logic connection between different pieces of data.

3. The method for object-level data permission management in a search platform for multi-source data with a non-unified permission system, as described in claim 1, is characterized in that... The business data permission standard includes seven necessary fields: business primary key, knowledge code, permission scenario 1, permission scenario 2, permission scenario 3, permission scenario 4, and permission scenario 5. The personnel permission standard includes six necessary fields: user account, knowledge code, permission scenario 1, permission scenario 2, permission scenario 3, and permission scenario 4. The personnel organization relationship table includes an organization table and a user table; organizations include physical organizations and virtual organizations, and the organization table includes the organization primary key, organization code, organization name, organization type, and organization path; the user table includes user account, organization code, and organization path; The data permission logic table includes a business organization table and a business permission association table; the business organization table includes a business primary key, organization code, and organization path; the business permission association table includes a business primary key, knowledge code, permission scenario 1, permission scenario 2, permission scenario 3, permission scenario 4, and permission scenario 5. The personnel permission logic table includes user account, knowledge code, permission scenario 1, permission scenario 2, permission scenario 3 and permission scenario 4.

4. The method for object-level data permission management in a search platform for multi-source data with a non-unified permission system, as described in claim 1, is characterized in that... In step S3, knowledge definitions are configured according to the required attributes for structured data. The required attributes should include the attributes used to build the index and the attributes required for data display. Each data source is organized into an organizational relationship table based on the actual organizational structure within the system. Based on the knowledge definition, the data source permission logical relationship collection table is organized and compiled. The data permission logical table is organized using object-level data under the knowledge definition as the basic permission unit, and different association methods are selected as needed, specifically including: Method 1: Associate the permission unit with one or more users or one or more organizations; Method 2: Associate the permission unit with one or more organizational paths and specify the direction of permission extension. The direction of extension includes extending to the upper-level node, extending to the lower-level node, and extending to the same-level node. For the analysis of the user permission logic table, the analysis work is divided into two stages, with the user as the basic permission unit: The first phase involves determining whether the user has the data permissions for the specified knowledge definition. In the second phase, users with specific knowledge definition data permissions can choose different association methods as needed. These association methods include: Method 1 involves associating a user with one or more organizations; Method 2 involves associating a user with one or more organizational paths and specifying the direction of permission extension, which can include extension to higher-level nodes, extension to lower-level nodes, and extension to nodes at the same level.

5. The method for object-level data permission management of a search platform for multi-source data with a non-unified permission system as described in claim 1, characterized in that, In step S4, for each data source, referring to the personnel organization relationship table sorted out in S3, the corresponding detailed organization data and detailed personnel data of the data source are periodically generated through the source database or big data platform data processing component using SQL or SPARK_SQL scripts. For each type of knowledge defined in S3 for each data source, the content of the data collection table is collected according to the data permission logic relationship of the corresponding data source. Through the source database or big data platform data processing component, the business organization table, business permission association table and personnel permission logic table containing object-level detailed permission data are periodically generated using SQL or SPARK_SQL scripts. During the data processing, the encoding of organization, business, personnel and knowledge, as well as the primary key, are standardized and unique.

6. The method for object-level data permission management in a search platform for multi-source data with a non-unified permission system, as described in claim 1, is characterized in that... In step S5, based on the target permission data standard of the search platform in S2, the SPARK_SQL script is compiled through the big data platform to complete the generation of permission scenario data, integration of business permission data, integration of personnel permission data and data quality verification. The combined processing script is configured with operation rules to periodically generate target object-level permission data of the data source. In the integration of business permission data, for each knowledge definition, the business detail data and business permission data are integrated at the object level, and the update time of business data and the update time of permission data are recorded by two timestamp fields respectively. In the process of integrating personnel permission data, personnel permission data from various data sources and knowledge categories are integrated into a single data table. Redundant data is filtered out through data quality checks.

7. The method for object-level data permission management of a search platform for multi-source data with a non-unified permission system as described in claim 1, characterized in that, In step S6, for unstructured data, the update of unstructured data is decoupled from its corresponding permission data; when the search platform collection task determines that only permission data is updated, a separate permission data update task is triggered.

8. The method for object-level data permission management of a search platform for multi-source data with a non-unified permission system according to claim 1, characterized in that, In step S8, the specific method for configuring user permissions on the search platform is as follows: For each data source, a corresponding role is configured on the search platform. Based on the system-level permission scope formed by S3, the role is associated with the corresponding organization or person, and the role status is activated.

9. The method for object-level data permission management of a search platform for multi-source data with a non-unified permission system as described in claim 8, characterized in that, In step S9, when a user initiates a search request, the scope of data sources that the user can access is first defined based on the permissions granted in S8. Then, the scope of knowledge definitions under the data sources is defined based on the personnel permission table. Finally, the permission fields in the personnel table are matched with the permission fields in the data table. If any pair of fields has matching data, the user has the permission to access the corresponding object-level data. The retrieval of search content and the determination of object-level permissions are carried out simultaneously. When the object-level data meets both the conditions for authentication and content retrieval, the object-level data is returned as a search result.

Images