Lightweight directory access protocol connection configuration method and device, equipment and medium

Abstract

Embodiments of the present application disclose a lightweight directory access protocol connection configuration method and device, electronic equipment and a computer readable storage medium, which can realize hot update of LDAP connection configuration and improve operation and maintenance efficiency. The method comprises the following steps: obtaining LDAP connection configuration parameters and an LDAP template instance; creating an LDAP context source instance, and filling the LDAP connection configuration parameters in the LDAP context source instance to obtain an LDAP context source instance filled with parameters; injecting the LDAP context source instance filled with parameters into the LDAP template instance to replace an existing LDAP connection source with a target LDAP connection source, the target LDAP connection source being a connection source obtained according to the LDAP connection configuration parameters; and performing an initialization operation on the LDAP template instance with the replaced connection source to make the target LDAP connection source effective.

Description

Technical Field

[0001] This application belongs to the field of enterprise information technology, and in particular relates to a method, apparatus, electronic device and computer-readable storage medium for configuring Lightweight Directory Access Protocol (LDAP) connection. Background Technology

[0002] LDAP is a network protocol used for accessing and managing directory services. It is widely used in enterprise information systems to support business operations such as user authentication and resource management.

[0003] In current LDAP connection configuration methods, LDAP connections are typically configured during application startup using pre-configured configuration files. Since LDAP connection configuration at application startup is done via configuration files, dynamic switching during runtime is not possible. When the Active Directory (AD) server address, port, or authentication information changes, the application service must be restarted to configure a new LDAP connection, impacting business continuity. Furthermore, when deployment is required in multiple environments such as development, testing, and production, multiple sets of configuration files need to be maintained, resulting in complex management and low operational efficiency. Summary of the Invention

[0004] This application provides a lightweight directory access protocol connection configuration method, apparatus, electronic device, and computer-readable storage medium, which can solve the problems that existing LDAP connection configurations cannot be switched at runtime and have low operation and maintenance efficiency.

[0005] In a first aspect, embodiments of this application provide a method for configuring a Lightweight Directory Access Protocol (LDAP) connection, including: Retrieve LDAP connection configuration parameters and LDAP template instance; Create an LDAP context source instance, populate the LDAP connection configuration parameters in the LDAP context source instance, and obtain the LDAP context source instance with the parameters populated; Inject the LDAP context source instance with populated parameters into the LDAP template instance to replace the existing LDAP connection source with the target LDAP connection source, which is the connection source obtained based on the LDAP connection configuration parameters; Initialize the LDAP template instance that has had its connection source replaced to make the target LDAP connection source effective.

[0006] In this embodiment, upon obtaining LDAP connection configuration parameters (i.e., obtaining a new connection configuration), an LDAP template instance (i.e., an LDAP Template instance) is obtained, and an LDAP context source instance (i.e., an LDAP ContextSource instance) is created. Then, the LDAP connection configuration parameters are populated into the LDAP Context Source instance. Next, the LDAP Context Source instance carrying the new LDAP connection configuration parameters is injected into the LDAP Template instance to replace the old LDAP connection source in the LDAP Template instance with the new LDAP connection source (i.e., the target LDAP connection source). Finally, an initialization operation makes the new LDAP connection source effective. In this way, new LDAP connections can be configured without restarting the application service during application operation, achieving runtime dynamic switching of LDAP connection configurations (i.e., hot updating of LDAP connection configurations). Furthermore, since LDAP connection configuration is not performed through configuration files, there is no need to maintain multiple sets of configuration files in multiple environments, supporting multi-environment configuration management and improving operational efficiency.

[0007] In some possible implementations of the first aspect, the method further includes, after the target LDAP connection source becomes active: Retrieve field mapping configuration information, which includes the correspondence between Active Directory attribute fields and business system fields; Query the target LDAP connection source to check if the Active Directory attribute field exists in the Active Directory domain; If an Active Directory attribute field exists in the Active Directory domain and the Active Directory attribute field is accessible, then retrieve the Active Directory attribute field. Filter the Active Directory attribute fields to obtain the filtered Active Directory attribute fields; Based on the field mapping configuration information, the filtered Active Directory attribute fields are mapped to business system fields, and the business system fields are synchronized to the business system.

[0008] This implementation achieves flexible field mapping configuration and real-time validation through configurable field mapping and filtering mechanisms, making it adaptable to the differences in different AD domain structures.

[0009] In some possible implementations of the first aspect, the method further includes, after the target LDAP connection source becomes active: Retrieve user data from the Active Directory domain via the target LDAP connection source; Parse the user data to obtain the group name to which the user belongs; Based on the group name and the mapping relationship between the group name and the business system permissions, determine the user's role, police force, and access domain type; the mapping relationship between the group name and the business system permissions includes the mapping relationship between the group name and the business system roles, the mapping relationship between the group name and the police force, and the mapping relationship between the group name and the access domain type. Generate access domain data corresponding to the user's access domain type.

[0010] In this implementation, permissions for multiple dimensions, such as roles, police teams, and access domains, can be automatically assigned to users based on group names in the Active Directory domain and the mapping relationship between group names and business system permissions, thus achieving automated allocation of group permissions.

[0011] In some possible implementations of the first aspect, the method further includes, after the target LDAP connection source becomes active: In response to user data synchronization requests, create a data synchronization task; By performing a data synchronization task, the group member list is cleared, and user data is queried from the Active Directory domain through the target LDAP connection source; Filter the user data to obtain the filtered user data; Synchronize the filtered user data and related data from the Active Directory domain to the business system to obtain the synchronization results; Update the group member list based on the synchronization results.

[0012] In some possible implementations of the first aspect, after creating the data synchronization task, the method further includes: Returns the task identifier of the data synchronization task; If the data synchronization task is determined to be in progress based on the task identifier, the status of the synchronization triggering device will be updated to disabled. The synchronization triggering device is used to trigger the data synchronization task. During the execution of the data synchronization task, the status of the data synchronization task is polled using the task identifier; If the data synchronization task is determined to be in a completed state, the status of the synchronization trigger device will be updated to an available state.

[0013] In this implementation, complete task status tracking is achieved during data synchronization, and a polling mechanism for the synchronization task status is implemented to prevent users from repeatedly clicking the synchronization trigger device.

[0014] In some possible implementations of the first aspect, the method further includes, after the target LDAP connection source becomes active: Obtain the login request, which includes the username and password; By matching account name attributes in the security account management system, the distinguishable name corresponding to the username can be determined. By invoking the password verification function through the target LDAP connection source, a distinguishable name and password are passed to the LDAP server so that the LDAP server can perform password verification based on the distinguishable name and password; Obtain the authentication result returned by the LDAP server.

[0015] In this implementation, dynamic LDAP connection configuration can be used for user authentication, enabling flexible authentication configuration management.

[0016] In some possible implementations of the first aspect, the method further includes, after the target LDAP connection source becomes active: Obtain LDAP query request; In response to an LDAP query request, the data access interface is invoked; By parsing the method name of the data access interface, the method name can be divided into multiple query conditions; Generate LDAP filters based on multiple query conditions; LDAP queries are executed using LDAP filters to obtain query results.

[0017] In this implementation, LDAP filters are automatically generated based on the method name of the data access interface, providing type-safe query methods and reducing coding errors.

[0018] Secondly, embodiments of this application provide a Lightweight Directory Access Protocol (LDAP) connection configuration device, comprising: The acquisition module is used to obtain LDAP connection configuration parameters and LDAP template instances; Create a populate module to create an LDAP context source instance and populate the LDAP connection configuration parameters into the LDAP context source instance, and obtain the LDAP context source instance with the parameters populated; The replacement module is used to inject an LDAP context source instance with populated parameters into an LDAP template instance to replace the existing LDAP connection source with the target LDAP connection source, which is a connection source obtained based on the LDAP connection configuration parameters. The initialization module is used to initialize the LDAP template instance that has had its connection source replaced, so that the target LDAP connection source becomes effective.

[0019] Thirdly, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method as described in any of the first aspects above.

[0020] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in any of the first aspects above.

[0021] Fifthly, embodiments of this application provide a computer program product that, when run on an electronic device, causes the electronic device to perform the method described in any one of the first aspects above.

[0022] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

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

[0024] Figure 1 This is a schematic block diagram of a traditional AD domain integration scheme architecture provided in an embodiment of this application; Figure 2 A flowchart illustrating an LDAP connection configuration method provided in an embodiment of this application; Figure 3 A flowchart illustrating the intelligent field mapping process provided in this application embodiment; Figure 4 A schematic block diagram illustrating the intelligent field mapping mechanism provided in this application embodiment; Figure 5 A flowchart illustrating a group permission mapping and automatic access domain allocation provided in this application embodiment; Figure 6 This is a schematic diagram illustrating the automatic allocation of group permissions and the processing of access domain types provided in an embodiment of this application; Figure 7 A schematic flowchart illustrating data synchronization provided in this application embodiment; Figure 8 A flowchart illustrating the multi-dimensional data synchronization process provided in this application embodiment; Figure 9 A schematic diagram of the LDAP authentication process provided in this application embodiment; Figure 10 This is a schematic block diagram illustrating the LDAP query process provided in an embodiment of this application. Figure 11 A schematic block diagram of the LDAP connection configuration device provided in the embodiments of this application; Figure 12 A schematic block diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0025] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0026] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0027] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0028] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0029] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0030] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0031] In related technologies, LDAP connection configuration is typically static, which cannot be dynamically switched at runtime, resulting in poor flexibility. For example, see... Figure 1 The diagram shown illustrates a traditional Active Directory (AD) domain integration architecture. An LDAP connection exists between the AD domain server and the application server. Through this LDAP connection and the application server, user data and other information from the AD domain server can be synchronized to the business database. The business database refers to the database within the business system, storing data such as user tables and permission tables.

[0032] The application server stores a pre-configured configuration file. When the application starts, it reads this file to configure the LDAP connection. This LDAP connection configuration is static, meaning the configuration is fixed at application startup and cannot be dynamically switched at runtime, resulting in poor flexibility. Furthermore, if deployment is required in multiple environments, multiple configuration files need to be maintained, leading to low operational efficiency.

[0033] To address the aforementioned issues, this application provides an LDAP connection configuration scheme that enables dynamic switching and configuration of LDAP connections at runtime. LDAP connection configurations can be modified and made effective without a restart, thereby improving the flexibility of LDAP connection configuration and enhancing operational efficiency.

[0034] The technical solutions provided by the embodiments of this application are described below with reference to the accompanying drawings and examples.

[0035] Please see Figure 2 This is a flowchart illustrating an LDAP connection configuration method provided in an embodiment of this application. The method may include the following steps: Step S201: Obtain LDAP connection configuration parameters and LDAP template instance.

[0036] It should be noted that LDAP connection configuration parameters may include, but are not limited to, at least one of the following: server address, port, Distinguished Name (DN), username, and password. The DN is a unique identifier for an LDAP object.

[0037] In practical applications, when it is necessary to modify the LDAP connection configuration, the system will receive new LDAP connection configuration parameters. These new LDAP connection configuration parameters are used to configure the new LDAP connection configuration, or in other words, they are used to modify the current LDAP connection configuration (i.e., the old LDAP connection configuration).

[0038] An LDAP template instance (or LDAP Template instance) is an LDAP template, a template class provided by Spring LDAP for performing LDAP operations. In specific applications, the LDAP connection source dynamic switching engine can obtain the application context through the Spring framework's application context-aware interface to retrieve the LDAP Template instance. This LDAP Template instance contains an existing LDAP connection source, meaning an older LDAP connection configuration already exists.

[0039] The LDAP Context Source Dynamic SwitchingEngine is used to dynamically create and switch LDAP connection sources at runtime. This engine can obtain an LDAP Template instance from the application context of the Spring framework; it can also dynamically create new LDAP Context Source instances, explicitly call the `after PropertiesSet` method to complete context initialization, and replace the connection source in the LDAPTemplate instance using the `set Context Source` method, thus achieving hot configuration updates.

[0040] In some embodiments, after receiving new LDAP connection configuration parameters, the system can encrypt the LDAP connection configuration parameters and save the encrypted LDAP connection configuration parameters to the database. When it is necessary to modify the LDAP connection configuration, the system queries the database to retrieve the encrypted LDAP connection configuration parameters, and then decrypts the encrypted LDAP connection configuration parameters to obtain the LDAP connection configuration parameters.

[0041] In practical applications, the password in the LDAP connection configuration parameters can be encrypted using AES-GCM by configuring the encryption storage engine. AES-GCM (Advanced Encryption Standard - Galois / Counter Mode) is a symmetric encryption algorithm.

[0042] Configure an encrypted storage engine for the encrypted storage and decryption of LDAP connection passwords. This engine uses the AES-GCM encryption algorithm to encrypt and store passwords, and automatically decrypts them when querying LDAP connection configurations, ensuring the security of sensitive information. A temporary configuration is used during configuration testing, and the original configuration is automatically restored after the test is complete.

[0043] It is worth noting that security can be improved by encrypting and storing passwords.

[0044] Of course, in other embodiments, the system may not need to encrypt and store the LDAP connection configuration parameters after receiving them.

[0045] Step S202: Create an LDAP context source instance and populate the LDAP connection configuration parameters in the LDAP context source instance to obtain the LDAP context source instance with the parameters populated.

[0046] It should be noted that the LDAP Context Source instance is an abstraction of the LDAP connection configuration, which can contain connection address and authentication information, etc.

[0047] In practical applications, an LDAP Context Source instance can be created through the LDAP connection source dynamic switching engine, and the new LDAP connection configuration parameters, such as the Shenzhen server address, port, basic DN, username, and password, can be populated into the Context Source instance.

[0048] Step S203: Inject the LDAP context source instance with the populated parameters into the LDAP template instance to replace the existing LDAP connection source with the target LDAP connection source, which is the connection source obtained according to the LDAP connection configuration parameters.

[0049] It should be noted that the existing LDAP connection source refers to the currently existing LDAP connection source, which is the old LDAP connection. The target LDAP connection source, on the other hand, obtains a new LDAP connection configuration based on the new LDAP connection configuration parameters.

[0050] In practical applications, the LDAP connection source can be dynamically switched by calling the `set Context Source` method in the LDAP Template instance to replace the LDAP connection source, thus enabling hot updates of the LDAP connection configuration. Hot updates refer to dynamically switching during runtime without restarting the service, allowing for updates to the LDAP connection configuration.

[0051] Step S204: Initialize the LDAP template instance of the replaced connection source to make the target LDAP connection source effective.

[0052] In practical applications, the LDAP connection source dynamic switching engine explicitly calls the after Properties Set method to complete context initialization so that the new LDAP connection configuration takes effect immediately, that is, the modified LDAP connection configuration takes effect immediately without restarting the application service.

[0053] Optionally, in some embodiments, the LDAP connection can also be tested and validated using a Connection TestValidation Engine to verify the validity of the LDAP connection configuration. The Connection TestValidation Engine can provide a separate connection testing interface, using a temporary LDAP template during testing without affecting existing LDAP connections, and automatically restoring the original LDAP configuration after the test is completed.

[0054] In this embodiment, a dynamic Context Source switching mechanism allows for the configuration of new LDAP connections without restarting the application service during application operation, enabling dynamic switching of LDAP connection configurations at runtime (i.e., hot updating of LDAP connection configurations). Furthermore, since LDAP connection configuration is not performed through configuration files, there is no need to maintain multiple sets of configuration files in multiple environments, supporting multi-environment configuration management. Changes to LDAP connection configurations take effect immediately, improving operational efficiency.

[0055] There are differences between the user attribute fields in the Active Directory (AD) domain and the fields in the business system, so a mapping relationship needs to be established. Based on this mapping relationship, the user attribute fields in the AD domain can be mapped and transformed to the business system fields.

[0056] In related technologies, the mapping relationship between user attribute fields in the Active Directory (AD) domain and business system fields is usually hard-coded, which cannot adapt to the differences in AD domain structures. Furthermore, the lack of a mapping verification mechanism means that configuration errors can only be discovered at runtime, affecting data synchronization quality.

[0057] In response to the issues mentioned above, the configurable field mapping and verification mechanisms in this application embodiment support flexible field mapping configuration and real-time verification, adapt to different AD domain structures, and ensure mapping correctness.

[0058] Based on the various embodiments described above, see [link to relevant documentation]. Figure 3 The illustrated flowchart of the smart field mapping process further includes the following steps after the target LDAP connection source becomes active: Step S301: Obtain field mapping configuration information, which includes the correspondence between Active Directory attribute fields and business system fields.

[0059] In practical applications, when field mapping needs to be configured, the system can receive field mapping configuration information. Optionally, after receiving the field mapping configuration information, it can also save the field mapping configuration information to the database, and then read the field mapping configuration information from the database when needed.

[0060] For example, the mapped fields may include user account (sAMAccountName), username (cn), email (userPrincipalName), and group information (memberOf), etc.

[0061] Among them, sAMAccountName, cn, userPrincipalName, memberOf, etc. are all AD domain attribute field names, while user account, username, email and group information are all business system field names.

[0062] The Field Mapping Configuration Engine can be used to manage the mapping relationships between AD attribute fields and business system fields. The Field Mapping Configuration Engine supports custom mapping configurations. The default mapping relationships are configurable and can be modified at runtime.

[0063] Step S302: Query the target LDAP connection source to see if the Active Directory attribute field exists in the Active Directory domain.

[0064] In practical applications, the validity of mapping relationships can be verified using a Mapping Relationship Validation Engine. This engine performs LADP queries on the target LDAP connection source to verify the existence of the corresponding AD attribute fields in the AD domain, thereby validating the mapping relationship. The engine also provides a mapping relationship testing interface.

[0065] When validating the mapping relationship, the mapping relationship validation engine can verify whether the corresponding field exists in the Active Directory domain, and verify the accessibility and data format of the field. If the validation passes, it proceeds to the next step; if the validation fails, it returns an error message.

[0066] Specifically, if the corresponding AD attribute field exists in the AD field and the AD attribute field can be accessed, the verification passes; otherwise, if the corresponding AD attribute field does not exist in the AD field or the AD attribute field cannot be accessed, the verification fails.

[0067] Step S303: If an Active Directory attribute field exists in the Active Directory domain and the Active Directory attribute field is accessible, then obtain the Active Directory attribute field.

[0068] Step S304: Filter the Active Directory attribute fields to obtain the filtered Active Directory attribute fields.

[0069] In practical applications, a data filter validation engine can be used to perform multi-dimensional filtering and validation of data in the Active Directory domain before data synchronization.

[0070] The data filtering and validation engine can filter administrator accounts, users without configured groups, usernames that do not conform to regular expressions, and fields that exceed length limits in the Active Directory (AD) domain data. By filtering the AD domain data before synchronization, only data that passes all filtering and validation checks is synchronized, ensuring the quality of the synchronized data.

[0071] Step S305: According to the field mapping configuration information, convert the filtered Active Directory attribute fields into business system fields, and synchronize the business system fields to the business system.

[0072] After filtering, the AD attribute fields can be mapped to business system fields according to the field mapping relationship configured in the field mapping configuration information, and the mapped and converted business system fields can be synchronized to the business system.

[0073] For example, see Figure 4 The diagram shown illustrates the intelligent field mapping mechanism. Field mapping can support default mapping, and the mapping relationship can be modified at runtime. Field mapping relationships can be configured. In addition, mapping verification is also supported, that is, the validity of the mapping relationship can be verified through the mapping relationship verification engine.

[0074] The Active Directory (AD) domain attributes include multiple attribute fields, such as sAMAccountName, cn, userPrincipalName, and memberOf. Through configured field mapping relationships, each attribute field in the AD domain is mapped to a business system field. For example, sAMAccountName can be mapped to a user account. Business system fields can include user account, username, email, and group information, etc.

[0075] In this embodiment, a configurable field mapping mechanism and a data filtering mechanism are used to achieve flexible field mapping configuration and real-time verification, which can be applied to the differences in different AD domain structures.

[0076] Group information in the Active Directory (AD) domain needs to be mapped to roles and access domains in the business system. Currently, related technologies require manually configuring permissions and access domains for each user, which is labor-intensive and error-prone. Furthermore, it's not yet possible to automatically assign multi-dimensional permissions (such as roles, police units, and access domains) to users based on AD group information.

[0077] To address the aforementioned issues, this application embodiment utilizes group permission mapping configuration and an automatic permission allocation scheme to automatically allocate multi-dimensional permissions (such as roles, police teams, access domains, etc.) based on AD group information, thereby achieving automated permission allocation.

[0078] Based on the various embodiments described above, see [link to relevant documentation]. Figure 5 The illustrated flowchart illustrates a process for group permission mapping and automatic allocation of access domains. After the target LDAP connection source becomes active, the method further includes the following steps: Step S501: Obtain user data from the Active Directory domain through the target LDAP connection source.

[0079] During data synchronization, the system retrieves user data from the Active Directory domain through the target LDAP connection source. User data may include the user's `memberOf` attribute. The `memberOf` attribute can include information about the groups the user belongs to. In other words, `memberOf` is a membership attribute representing a list of groups the user belongs to.

[0080] Step S502: Parse the user data to obtain the group name to which the user belongs.

[0081] In practical applications, the `memberOf` attribute in user data can be parsed using an Automatic Permission Assignment Engine to extract the group names of the user's groups. When a user belongs to multiple groups, the last group retrieved will be used.

[0082] The automatic permission allocation engine can automatically assign permissions based on the group information of AD users. This engine retrieves the group a user belongs to based on the AD user's memberOf attribute; and automatically assigns role IDs, police IDs, and access domain types to the user based on the group name and the mapping relationship between network and business system permissions.

[0083] It should be noted that the `memberOf` attribute in the Active Directory (AD) domain contains the complete group DN, so the group name needs to be extracted from it. This application embodiment can automatically extract the group name from the complete DN through `memberOf` attribute parsing and RDN extraction algorithms, without manual parsing, and supports complex DN structures. Here, RDN (Relative Distinguished Name) refers to a relatively distinguishable name.

[0084] The memberOf attribute parsing engine is used to parse the memberOf attribute. This engine can extract user group information from the memberOf attribute in LDAP, which contains the complete group DN; and use the New LDAP Name method of the LDAP utility class to convert the string DN into an LDAP name object.

[0085] The RDN Extraction Engine is used to extract group names. This engine retrieves all RDN components of a DN using the Relative Distinguished Name Components method of the LDAP Name object, and takes the last RDN as the group name (using the string value retrieval method of the LDAP utility class).

[0086] The Multiple Group Processing Engine handles cases where a user belongs to multiple groups. If a user belongs to multiple groups, the first group is selected by default. Multiple group processing strategies can be configured (e.g., select the first group, select the last group, select all groups, etc.). Multiple group cases can be filtered and mapped using streaming processing.

[0087] The DN Operation Engine is used for building and manipulating DNs. This engine supports calculating relative DNs, calculating relative paths by filtering RDN components, building and manipulating DN objects using the LDAP name builder, and supports operations such as merging, splitting, and comparing DNs.

[0088] When it's necessary to resolve a user's group name from the `memberOf` attribute, the `memberOf` attribute resolution engine retrieves the user's `memberOf` attribute; the RDN extraction engine extracts the group name by resolving the DN. Specifically, it converts the string DN into an LDAP name object, retrieves all RDN components, and takes the last RDN as the group name. If a user belongs to multiple groups, the multi-group processing engine selects a group according to the configured strategy; otherwise, it defaults to the first group. The DN operation engine performs relative path calculations or other operations on the DN.

[0089] It is worth noting that the embodiments of this application automatically extract group names from the complete DN without manual resolution, support complex DN structures, adapt to different AD domain organization methods, and provide flexible group name extraction strategies.

[0090] Step S503: Determine the user's role, police force, and access domain type based on the group name and the mapping relationship between the group name and the business system permissions; the mapping relationship between the group name and the business system permissions includes the mapping relationship between the group name and the business system roles, the mapping relationship between the group name and the police force, and the mapping relationship between the group name and the access domain type.

[0091] Specifically, by mapping group names to business system roles, a user's business system role can be determined based on the group name, i.e., the role ID assigned to the user. Similarly, by mapping group names to police departments, the police department to which a user belongs can be determined based on the group name, i.e., the police department ID assigned to the user. Likewise, by mapping group names to access domain types, the user's access domain type can be determined based on the group name.

[0092] The Group Permission Mapping Configuration Engine manages the mapping relationship between group names and business system permissions. This engine establishes and maintains mapping relationships between AD group names and business system roles, AD group names and police teams, and AD group names and access domain types. It also supports one group corresponding to multiple access domains (multiple police team management).

[0093] Step S504: Generate access domain data corresponding to the user's access domain type.

[0094] In practical applications, the Access Domain Type Processing Engine can be used to automatically generate access domain data based on the access domain type. This engine supports three access domain types: All Groups (users can access all police teams configured within a group), Multiple Groups (users can access multiple specified police teams configured within a group), and Self Only (users can only access their own data), and automatically generates an access domain data list based on the access domain type.

[0095] In other words, if the access domain type is the "all groups" type, access domain data containing all configured police teams will be generated; if the access domain type is the "multiple groups" type, access domain data containing the specified police team will be generated; if the access domain type is the "only yourself" type, access domain data containing only the user's own will be generated.

[0096] It should be noted that enterprise-level police systems may include information related to police forces. That is, the solutions provided in this application can be applied to enterprise-level police systems.

[0097] See Figure 6The diagram illustrating automatic group permission allocation and access domain type processing first obtains the `memberOf` attribute from the Active Directory (AD) user data. Then, it performs Domain Name (DN) parsing on the `memberOf` attribute to extract the group name. After extracting the group name, based on the group permission mapping (i.e., the mapping relationship between the group name and business system permissions), it determines the corresponding role ID, police ID, and access domain type. Finally, based on the role ID, police ID, and access domain type, it assigns the user a role, police unit, and access domain. This achieves automated group permission allocation, reducing manual configuration workload.

[0098] When processing access domain types, different access domain data is generated based on different access domain types.

[0099] In this embodiment of the application, based on the group name in the AD domain and the mapping relationship between the group name and the permissions of the business system, permissions of multiple dimensions such as roles, police force and access domain are automatically assigned to users, thereby realizing the automatic allocation of group permissions.

[0100] Based on the various embodiments described above, see [link to relevant documentation]. Figure 7 The illustrated flowchart of a data synchronization process includes the following steps after the target LDAP connection source becomes active: Step S701: In response to the user's data synchronization operation, create a data synchronization task.

[0101] The data synchronization action is used to trigger a data synchronization task. For example, a user can trigger a data synchronization task by clicking the synchronization button to input a data synchronization action.

[0102] In practical applications, data synchronization tasks can be created using the Asynchronous Synchronization TaskEngine. This engine manages these tasks. It can execute asynchronously, immediately returning the task identifier and persistently storing the task's status (e.g., task status, error messages, completion time). The frontend can obtain the task's status through a polling mechanism.

[0103] In other words, when a data synchronization task is created, the asynchronous synchronization task engine can immediately return the task identifier to the front end. This allows the front end to poll the task based on the task identifier during execution to obtain the real-time task status.

[0104] Step S702: By executing the data synchronization task, clear the group member list and query user data from the Active Directory domain through the target LDAP connection source.

[0105] Step S703: Filter the user data to obtain the filtered user data.

[0106] Step S704: Synchronize the filtered user data and related data from the Active Directory domain to the business system to obtain the synchronization result.

[0107] Step S705: Update the group member list based on the synchronization results.

[0108] Data synchronization tasks are executed asynchronously in the background. Specifically, the DataSynchronization Process Engine executes this task according to a predefined process. The DataSynchronization Process Engine is used to execute the various steps of the data synchronization task. The steps of a data synchronization task can be as follows: Step 1: Clear group members. This means clearing the member list of all groups in preparation for repopulation. Step 2: Retrieve AD data. This involves querying all user data from the AD domain. Step 3: Data Filtering. This involves filtering data based on the configured group mapping and validation rules. Step 4: Batch create / update users. This involves distinguishing between adding and updating users, and processing them in batches. Step 5: Related Data Processing. This involves batch processing of user snapshots, access domains, device associations, etc. Step 6: Update group members. This involves updating the group's member list based on the synchronization results. Step 7: Trigger the event. This involves triggering the user parameter delivery event to notify the relevant systems.

[0109] Optionally, the entire data synchronization process can be executed within a single transaction using a Transactional Guarantee Engine. If any step fails, all operations are automatically rolled back. This ensures data consistency and integrity. The Transactional Guarantee Engine guarantees the transactionality of data synchronization.

[0110] It is worth noting that user data synchronization requires processing multi-dimensional data such as basic user information, permission information, access domains, and device associations simultaneously. Related technologies lack transactional guarantees, making data inconsistency prone to occur. Furthermore, the exception handling mechanism during data synchronization is imperfect, making rollback difficult after failure. In contrast, the embodiments of this application guarantee data consistency during the data synchronization process through a transactional guarantee engine; any failure in any step can trigger a transaction rollback.

[0111] Optionally, when an LDAP connection error is encountered, the error handling and retry engine can automatically retry multiple times (e.g., 3 times) and record detailed error information.

[0112] The error handling and retry engine is used to handle errors during data synchronization. It retryes the connection multiple times when an LDAP connection fails, logs error messages and records the results, and persists the data synchronization results (e.g., synchronization success, synchronization failure, and reasons for failure).

[0113] It is worth noting that providing error handling and retry mechanisms can better ensure transactional integrity.

[0114] Optionally, after data synchronization is complete, the system can update the status of the data synchronization task (e.g., task success or task failure). Furthermore, based on the task identifier of the data synchronization task, the front end can obtain the real-time status of the data synchronization task through a polling mechanism.

[0115] It is worth noting that large-scale user data synchronization is a time-consuming operation, and if executed synchronously, it will block user operations and affect user experience. However, in this embodiment, asynchronous data synchronization is achieved through an asynchronous synchronous task mechanism and a state management mechanism, providing a complete task state tracking and error recovery mechanism to ensure the integrity and consistency of data synchronization.

[0116] In some embodiments, after creating a data synchronization task, the task identifier of the data synchronization task can also be returned; if it is determined that the data synchronization task is being executed based on the task identifier, the status of the synchronization triggering device is updated to the disabled state, and the synchronization triggering device is used to trigger the data synchronization task; during the execution of the data synchronization task, the status of the data synchronization task is polled through the task identifier; if it is determined that the status of the data synchronization task is the completed state, the status of the synchronization triggering device is updated to the available state.

[0117] Data synchronization tasks are executed asynchronously, requiring management of their status. In this embodiment, after creating a data synchronization task, a task identifier is immediately returned to the front-end, and the task is executed asynchronously in the background. During task execution, the front-end can poll the status of the data synchronization task based on the task identifier to obtain its real-time status and display its real-time progress.

[0118] Once the data synchronization task is completed, i.e., the data synchronization is finished, the data synchronization results can be persistently stored in the system configuration table, and detailed operation logs can be recorded through the operation log.

[0119] In practical applications, asynchronous data synchronization tasks can be managed using an asynchronous task management engine. After creating a data synchronization task, the engine immediately returns a task identifier. Furthermore, the task status of the data synchronization task is persistently stored in the database table `t_ad_sync_task`. The task status can include: in progress, successful, or failed. It can also record detailed information such as task completion time, error messages, and error codes.

[0120] The polling mechanism is implemented through a Status Polling Engine. That is, the front-end can synchronize the real-time status of tasks based on task identifiers by polling data. It supports real-time querying of task progress and results, and polling can be canceled when switching to other pages, saving resources.

[0121] The Result Persistence Engine is used to persist the synchronization results after data synchronization is complete. This engine can persistently store the synchronization results in a system configuration table, using JSON format to store detailed synchronization result information, and supports querying and analyzing historical synchronization records.

[0122] The Operation Log Recording Engine is used to record operation logs. During data synchronization, it records detailed operation logs. The log content can include data synchronization results and error messages, supporting operation auditing and troubleshooting.

[0123] In this embodiment, complete data synchronization task status tracking is implemented; persistent storage of synchronization results supports historical record queries; and detailed operation logs support auditing and problem troubleshooting.

[0124] Before data synchronization begins, it is typically necessary to clear relevant data to avoid leaving old data behind. Simultaneously, it is also necessary to prevent users from repeatedly clicking the synchronization button, thus repeatedly triggering the data synchronization task. In this embodiment, if it is determined that a data synchronization task is being executed based on the task identifier, the status of the synchronization triggering device is updated to a disabled state, and the synchronization triggering device is used to trigger the data synchronization task; if it is determined that the data synchronization task is in a completed state, the status of the synchronization triggering device is updated to an available state. This prevents the repeated triggering of the data synchronization task.

[0125] The synchronization triggering device can be a synchronization button. When the synchronization triggering device is disabled, the user cannot trigger data synchronization; when the synchronization triggering device is enabled, the user can trigger data synchronization.

[0126] In practical applications, the Duplicate Submission Prevention Engine disables the sync button during data synchronization to prevent repeated clicks from triggering data synchronization. Furthermore, it determines whether data synchronization is in progress based on the task status and restores the sync button's availability after synchronization is complete.

[0127] The Pre-Sync Clearance Engine is used to clear data before data synchronization begins. Before synchronization starts, this engine clears the member lists of all groups (i.e., sets the members to empty), ensuring consistency between the group member lists and the synchronized data, avoiding the retention of old data, and ensuring data accuracy.

[0128] The embodiments of this application can ensure data consistency and improve system stability through a pre-synchronization clearing mechanism and a mechanism to prevent duplicate submissions.

[0129] As shown above, the data synchronization process engine can execute each step of a data synchronization task. See also Figure 8 The multi-dimensional data synchronization flowchart shown can include steps 1 through 7, as detailed below: Step 1: Clear group members.

[0130] In practical applications, the member lists of all groups can be cleared before synchronization. This clears the group member lists in preparation for repopulation.

[0131] Step 2: Retrieve AD data. That is, query and retrieve all user data from the AD domain.

[0132] Step 3: Data filtering.

[0133] Before data synchronization, AD data undergoes multi-dimensional filtering and verification to ensure data quality. This application provides a multi-dimensional filtering mechanism and a hierarchical filtering strategy in its embodiments.

[0134] A multi-dimensional filtering mechanism is implemented through a multi-dimensional filtering engine. A layered filtering strategy is executed through a layered filtering engine.

[0135] The multi-dimensional filtering engine is used for multi-dimensional data filtering. It supports administrator filtering, group mapping filtering, regular expression validation filtering, length validation filtering, data integrity filtering, and more.

[0136] Administrator filtering refers to filtering out platform administrator accounts to prevent overriding administrator privileges. Group mapping filtering means only synchronizing users with configured group mappings; users without configured groups are not synchronized. Users with configured group mappings are those with configured group names and business system permissions.

[0137] Regular expression validation filtering filters usernames that do not conform to regular expressions to prevent special character contamination. Length validation filtering filters excessively long fields to ensure data meets business system requirements. Data integrity filtering synchronizes only data containing all required fields, such as name, account, group, and email.

[0138] A hierarchical filtering engine can include a three-tiered filtering strategy. The first tier uses object class attributes for filtering during LDAP queries, only querying user-type objects. The second tier uses streaming processing for multi-dimensional filtering of the query results. The third tier performs final validation before data is stored in the database.

[0139] The multi-dimensional filtering in the second-level filtering strategy may include, but is not limited to: filtering administrator accounts, filtering users who are not configured with groups, filtering usernames that do not conform to regular expressions, filtering fields that exceed the length limit, and filtering users with incomplete data.

[0140] In practical applications, filtering rule configurations can be managed through the Filter Rule Configuration Engine. The Filter Rule Configuration Engine supports configurable username length limits (default 45 characters), configurable account length limits (default 10 characters), configurable special character regular expressions, and supports dynamic adjustment of filtering rules at runtime.

[0141] In addition, a filter log recording engine can be used to record filtered data and the reasons for filtering. This facilitates troubleshooting and data quality analysis, and supports filter statistics and report generation.

[0142] It is worth noting that the embodiments of this application ensure the data quality of data synchronization through multi-dimensional filtering, the configurable filtering rules adapt to different business scenarios, and the detailed filtering logs facilitate troubleshooting.

[0143] Step 4: Create / update users in batches.

[0144] Data synchronization requires distinguishing between newly added users and updated users, and processing them separately. This application's embodiments optimize performance through an automatic identification mechanism and batch processing. Automatic identification reduces manual judgment logic, while batch processing significantly improves performance.

[0145] In practical applications, the Add / Update Auto-IdentificationEngine automatically identifies newly added and updated users. This engine performs batch queries on the account list to identify existing users (using a method that searches for identifiers based on account names), constructs a mapping table (map) from account to user, and determines whether a user is newly added or updated. Optional objects and the mapping table are used to optimize search performance, and separate lists of newly added and updated users are constructed and processed in batches.

[0146] During data synchronization, the automatic addition / update identification engine constructs a mapping table from accounts to users, and then determines whether each AD user is a new user or an update user. Specifically, if the AD user account exists in the mapping table, it is an update user; if the AD user account does not exist in the mapping table, it is a new user.

[0147] After identifying new and updated users, the Batch Processing Optimization Engine can be used to build separate lists for each, enabling batch processing. The engine uses a batch insert method to insert new users and a batch update method to update existing users, reducing database interactions and improving performance.

[0148] The Unified Update Logic Engine sets user attributes uniformly to ensure data consistency. This engine uses the same `updateUser` method for both adding and updating users, distinguishing between additions and updates by checking if the user object is null, thus uniformly setting user attributes and guaranteeing data consistency.

[0149] The Performance Optimization Engine is used for performance optimization. This engine uses streaming processing for data processing and transformation, batch operations reduce the number of database transactions, avoid processing row by row, and improve overall performance.

[0150] In this embodiment, by automatically identifying new and updated users, manual judgment logic is reduced; batch processing of new and updated users significantly improves performance; and unified logic ensures code maintainability.

[0151] Step 5: Related data processing.

[0152] During data synchronization, multiple dimensions of data, such as user basic information, permission information, access domains, and device associations, can be processed simultaneously. This application embodiment utilizes an automatic synchronization mechanism for associated data to automatically process associated data such as user snapshots, access domains, and device associations, ensuring the integrity and consistency of user-related data.

[0153] In practical applications, the User Snapshot Data Synchronization Engine, Access Domain Data Synchronization Engine, and Device Association Data Synchronization Engine can be used to synchronize user snapshot data, access domain data, and device association data, respectively.

[0154] During data synchronization, after synchronizing basic user information, the user snapshot data synchronization engine automatically creates or updates user snapshots. These snapshots can include information such as user ID, username, account, role, and police unit.

[0155] The user snapshot data synchronization engine first queries existing snapshots; if a snapshot exists for a user, it updates that user's snapshot; otherwise, it creates a new snapshot. When a snapshot exists for a user, its hash value can be used to determine whether an update is needed. Updating a user snapshot can refer to updating information such as roles and police units within the snapshot.

[0156] The access domain data synchronization engine deletes old access domain data for updated users and automatically generates new access domain data based on group configuration, and inserts access domain data in batches.

[0157] The device-associated data synchronization engine automatically synchronizes the police information of associated devices when there are changes in the user's police force, ensuring consistency between the devices and the user's police force.

[0158] User snapshot data needs to be updated synchronously, but not necessarily as a full update every time. This application's embodiments improve update efficiency and reduce database operations through a snapshot hashing mechanism and an incremental update strategy.

[0159] When synchronizing user data, the Snapshot Hash Engine generates a hash value for each user snapshot. The hash value can be calculated based on key fields of the snapshot and used to determine whether the user snapshot needs to be updated.

[0160] The Incremental Update Engine builds a snapshot mapping table by querying existing user snapshots. For an existing snapshot, if the snapshot's hash value differs from the user's data hash value, it's determined that the snapshot needs to be updated. Specifically, information such as roles and police units in the snapshot can be updated. If no snapshot exists for the user, a new snapshot is created.

[0161] The Snapshot Data Integrity Engine ensures the integrity of snapshot data. This engine automatically updates snapshot data during user data synchronization, guaranteeing consistency between snapshots and user data, and supports batch creation and updating of snapshot data.

[0162] This application embodiment improves update efficiency through a snapshot hashing mechanism, reduces database operations through an incremental update strategy, and ensures the integrity and consistency of snapshot data.

[0163] Step 6: Update group members.

[0164] After data synchronization is complete, the group's member list can be updated based on the synchronization results. This embodiment of the application automatically maintains the group member list through a group member aggregation algorithm and a batch update mechanism, reducing manual maintenance workload and improving performance through batch updates.

[0165] In practical applications, once data synchronization is complete, the Group Member Aggregation Engine aggregates multiple users from the same group. Specifically, the Group Member Aggregation Engine iterates through all synchronized users, aggregating multiple users from the same group into a member list, grouped by group name. Each group corresponds to a member information list, formatted as "username (account)". Multiple members are separated by commas.

[0166] The group member list is updated in batches using the Batch Update Engine. All group member lists are cleared before data synchronization, and are updated in batches after synchronization is complete, based on the synchronization results.

[0167] The Member List Maintenance Engine is responsible for maintaining the group member list. This engine stores the group member list in the business system database, not LDAP, and dynamically generates the member list based on Active Directory user data during synchronization. It supports incremental and full updates of the member list.

[0168] Data consistency is ensured through a Data Consistency Guarantee Engine. This engine executes clear and update operations within the same transaction, guaranteeing the consistency between the group member list and the synchronized data. It automatically rolls back in case of synchronization failure, ensuring data integrity.

[0169] This application embodiment reduces manual maintenance workload by automatically maintaining the group member list, improves performance through batch updates, reduces the number of database operations, and ensures data consistency through transactional guarantees.

[0170] Step 7: Trigger the event.

[0171] After data synchronization is complete, relevant systems can be notified to update user information. This embodiment of the application utilizes an event-triggered mechanism and distributed system support to achieve system decoupling through event-driven mechanisms, supporting data synchronization within distributed systems.

[0172] After data synchronization is complete, the Root Company Identification Engine queries all root company IDs and converts the root company list into a comma-separated string. The EventTrigger Engine then creates a user parameter change event and publishes the change time to notify relevant systems (such as the device management system) to update user information. The user parameter change event includes a list of root company IDs.

[0173] The Distributed System Support Engine detects user parameter change events through relevant systems (such as device management systems) and automatically updates user information based on these events, ensuring data consistency in the distributed system.

[0174] The Cache Cleanup Engine cleans up the user information cache after data synchronization is complete (using the batch deletion method in the cache utility class), ensuring consistency between the cache and the database data, and supporting batch deletion based on cache key pattern matching.

[0175] In related technologies, LDAP authentication configurations are typically fixed at application startup and cannot be dynamically switched during runtime. When the AD server address, port, or authentication information changes, the application service needs to be restarted. This results in a lack of flexible authentication configuration management and verification mechanisms.

[0176] To address the aforementioned issues, this application embodiment employs a unified LDAP authentication mechanism, using dynamic LDAP connection configuration for user authentication without requiring application service restarts, providing flexible authentication configuration management and verification mechanisms. Furthermore, passwords are verified on the LDAP server side and not stored on the application side, enhancing security.

[0177] Based on the various embodiments described above, see [link to relevant documentation]. Figure 9 The illustrated LDAP authentication process diagram shows that, after the target LDAP connection source becomes active, the method further includes the following steps: Step S901: Obtain the login request, which includes the username and password.

[0178] Specifically, when logging in, users enter their username and password to detect the login request.

[0179] Step S902: Determine the distinguishable name corresponding to the username by matching the account name attributes in the security account management system.

[0180] Step S903: Through the target LDAP connection source, call the password verification function to pass a distinguishable name and password to the LDAP server so that the LDAP server can perform password verification based on the distinguishable name and password.

[0181] Step S904: Obtain the authentication result returned by the LDAP server.

[0182] In practical applications, the LDAP Authentication Configuration Engine obtains the current LDAP connection configuration; the Authentication Process Engine queries the user's basic information to verify the user's existence; and the LDAP Authentication Execution Engine uses LDAP's password verification function to perform password verification. Specifically, the LDAP Authentication Execution Engine builds a query filter, matches the username using the secure account management account name (sAMAccountName), and then calls the password verification function, sending the username and password to the LDAP server. If the password is correct, authentication succeeds; if the password is incorrect, authentication fails. Upon successful authentication, the system returns user information; upon authentication failure, the system returns an error message.

[0183] The LDAP authentication configuration engine manages LDAP authentication configurations and can perform user authentication using dynamic LDAP connection configurations. Authentication configurations and AD connection configurations are managed uniformly, supporting dynamic switching of AD servers at runtime without requiring a service restart.

[0184] The LDAP authentication execution engine is used to perform LDAP authentication operations. It uses LDAP's password verification functionality to verify usernames and passwords, constructs query filters using equality filters, uses the sAMAccountName attribute for user matching, supports LDAP referral exception handling, and uses the ignore partial result exception setting to avoid AD server referral issues.

[0185] The authentication process engine manages the authentication process. Upon login, it queries basic user information, performs password verification using LDAP's password authentication functionality, provides clear error messages when authentication fails, and supports an LDAP connection retry mechanism for abnormal connections.

[0186] If an LDAP referral exception is encountered, the engine uses setIgnorePartialResultException to avoid the exception.

[0187] In this embodiment, dynamic LDAP connection configuration is used for user authentication, which enables flexible authentication configuration management.

[0188] In related technologies, LDAP queries require writing fixed LDAP filter strings, lack type safety, and cannot dynamically generate LDAP queries based on method names, resulting in high code duplication. The mapping from Java attribute names to LDAP attribute names needs to be manually maintained, which is prone to errors. Furthermore, there is a lack of support for complex query conditions (such as AND, OR combinations, fuzzy matching, etc.).

[0189] To address the issues mentioned above, this application embodiment automatically generates LDAP queries based on the method name of the data access interface, providing a type-safe query method and reducing coding errors.

[0190] Based on the various embodiments described above, see [link to relevant documentation]. Figure 10 The illustrated LDAP query process diagram shows that, after the target LDAP connection source becomes active, the method further includes the following steps: Step S1001: Obtain the LDAP query request.

[0191] Step S1002: In response to the LDAP query request, call the data access interface.

[0192] Step S1003: Parse the method name of the data access interface to divide the method name into multiple query conditions.

[0193] In practical applications, when calling the methods of the data access interface to perform LDAP queries, the Method Name Parsing Engine parses the method name of the data access interface and decomposes the method name into multiple query conditions.

[0194] The method name resolution engine can use PartTree to parse the method names of data access interfaces, breaking them down into multiple query condition parts. Each query condition part represents a query condition, which can include Java attribute names and query types.

[0195] Step S1004: Generate an LDAP filter based on multiple query conditions.

[0196] In practical applications, the Dynamic LDAP Filter Generation Engine can convert method name resolution results into LDAP query objects. That is, the Dynamic LDAP Filter Generation Engine uses ObjectDirectoryMapper to dynamically map Java attribute names to LDAP attribute names; and generates corresponding LDAP filters based on the query type of the query conditions.

[0197] Query types can include, but are not limited to: equal to, prefix matching, suffix matching, contain, fuzzy matching, greater than or equal to, less than or equal to, not empty, empty, etc.

[0198] After obtaining the LDAP query objects (i.e., LDAP attribute names and LDAP filters), the Query Condition Combination Engine generates the final LDAP filter by combining multiple query conditions. The Query Condition Combination Engine supports AND and OR logic combinations of multiple query conditions and supports query result restrictions and sorting.

[0199] Step S1005: Execute an LDAP query through the LDAP filter to obtain the query results.

[0200] In this embodiment, an LDAP filter is automatically generated based on the method name of the data access interface, providing a type-safe query method and reducing coding errors; it also supports complex combinations of query conditions, improving query performance and resource utilization.

[0201] In some embodiments, an attribute projection engine can also be used to identify the attributes to be queried based on the return type, thereby optimizing query performance. That is, the attribute projection engine can automatically identify the attributes to be queried based on the return type, and supports interface projection and DTO projection, querying only the necessary attributes, which can reduce network transmission and memory usage.

[0202] In the above embodiment, Java attribute names can be dynamically mapped to LDAP attribute names using ObjectDirectoryMapper.

[0203] However, in related technologies, the mapping relationship of ObjectDirectoryMapper needs to be hard-coded on the entity class, and the attribute mapping relationship cannot be dynamically adjusted at runtime. In response, the embodiments of this application integrate a dynamic attribute name resolution mechanism into ObjectDirectoryMapper to dynamically resolve the mapping from Java attribute names to LDAP attribute names at runtime. This can adapt to different AD domain structures and realize a runtime dynamic attribute mapping resolution mechanism.

[0204] When performing attribute mapping resolution, the Attribute Mapping Integration Engine first retrieves the mapping metadata of the entity classes. This mapping metadata can include mapping relationships defined by annotations. This mapping relationship is a mapping from Java attribute names to LDAP attribute names.

[0205] The attribute mapping integration engine performs attribute mapping by integrating Spring LDAP's ObjectDirectoryMapper. It dynamically resolves the mapping from Java attribute names to LDAP attribute names at runtime, based on mapping relationships defined by annotations such as @Entry, @Attribute, and @Id. Then, the Dynamic Attribute NameResolution Engine parses the Java attribute names in real-time during LDAP query creation. Specifically, it calls the mapper's attribute retrieval function to obtain the entity type and Java attribute name, and outputs the corresponding LDAP attribute name based on the mapping relationship, entity type, and Java attribute name.

[0206] In practical applications, the mapping relationship between Java attribute names and LDAP attribute names can be customized. Custom mapping relationships can be managed through a custom mapping configuration engine. This engine allows for customization of attribute mapping relationships via configuration files or code, overriding the default annotation mapping relationships to adapt to the structural differences of different Active Directory domains.

[0207] Optionally, to improve parsing performance, mapping relationships can be cached through the Mapping Context Management Engine. The Mapping Context Management Engine manages entity mapping metadata, using LDAP mapping contexts to manage entity mapping metadata and supporting dynamic registration and discovery of entity types.

[0208] The runtime dynamic attribute mapping resolution mechanism provided in this application embodiment can adapt to different AD domain structures, and can dynamically resolve attribute mappings at runtime without restarting the service; in addition, it can also support custom mapping relationship configurations, improving the system's versatility.

[0209] In the above embodiments, LDAP queries can be implemented by calling the data access interface to obtain query results. However, in related technologies, LDAP queries require writing fixed filter strings, lacking flexibility. To address this, this application embodiment provides a flexible query definition method through @Query annotation support and parameter binding mechanisms. It also supports complex query scenarios and a secure parameter binding mechanism to prevent LDAP injection.

[0210] When a method of the data access interface annotated with @Query is called, the AnnotationQuery Processing Engine parses the @Query annotation to obtain the LDAP filter string and the underlying DN.

[0211] The annotation-based query processing engine handles queries defined using the `@Query` annotation. It supports using the `@Query` annotation on data access interface methods to define custom LDAP filters; it supports defining LDAP filter strings in the `value` attribute; and it supports defining the base DN for searching in the base attribute.

[0212] The parameter binding engine binds the method parameters of the data access interface to the query string. Specifically, it first identifies named parameters, index parameters, SpEL expressions, and attribute placeholders, and then binds these method parameter values ​​to the query string (i.e., the LDAP filter string).

[0213] The Parameter Encoding Security Engine encodes method parameter values ​​to prevent LDAP injection attacks.

[0214] The Value Evaluation Context Engine evaluates SpEL expressions to compute dynamic values. This engine can create value evaluation contexts through the ValueEvaluationContextProvider, supporting runtime evaluation of SpEL expressions and the analysis and optimization of expression dependencies. Finally, the system executes an LDAP query to obtain the LDAP query results.

[0215] In related technologies, extending the functionality of a data access interface requires modifying the base class, which in turn affects all data access interfaces. To address this, this application's embodiment utilizes the Fragment composition pattern to achieve modular combination of data access interface functionalities. This supports dynamically combining different data access interface functional fragments at runtime, loading functionality on demand, and improving system performance.

[0216] Specifically, when a data access interface instance needs to be created, the FragmentDetection Engine detects the inheritance relationship of the data access interface to determine whether a specific Fragment needs to be added.

[0217] The Fragment detection engine detects the metadata of the data access interface by obtaining repository fragments; based on the inheritance relationship between the metadata and the data access interface, it determines whether a specific Fragment needs to be added.

[0218] The Fragment Composition Engine can combine data access interface functional fragments based on the detection results (i.e., the detection results of whether a specific Fragment needs to be added). For example, if the data access interface inherits a query domain-specific language predicate executor, a QueryDSL Fragment is added; other Fragments are added according to the interface inheritance relationship.

[0219] If a QueryDSL Fragment is added, QueryDSL query functionality is provided through the QueryDSL Integration Fragment Engine.

[0220] When the QueryDSL integrated Fragment engine inherits a query domain-specific language (LDAP) predicate executor from the data access interface, it automatically adds a LDAP predicate executor Fragment. The Fragment uses reflection to detect the inheritance relationship of the data access interface, supports type-safe QueryDSL queries, and automatically converts them to LDAP filters.

[0221] Alternatively, a Fragment Isolation Engine can be used to ensure that different Fragments are isolated from each other, independent of each other, and do not affect each other.

[0222] In related technologies, LDAP queries lack type safety and are prone to errors. To address this, embodiments of this application provide a type-safe query interface through a QueryDSL Predicate conversion and operator mapping mechanism, and automatically convert QueryDSL expressions into LDAP filters at compile time.

[0223] Specifically, when using Query DSL for queries, users construct query conditions using Query DSL and create predicate objects. The Query DSL Predicate Conversion Engine then converts these predicate objects into LDAP filters using an LDAP serializer. Specifically, the Query DSL Predicate Conversion Engine uses a visitor pattern to traverse the expression tree, identifies Query DSL operators, and calls the operator mapping engine to convert the Query DSL operators into LDAP filters.

[0224] The Operator Mapping Engine is used to map Query DSL operators to LDAP filters. It supports various operator mappings.

[0225] For example, the equals operator is mapped to an equals filter; the fuzzy matching operator is mapped to a fuzzy matching filter; the prefix matching operator is mapped to a fuzzy matching filter with an asterisk suffix; the suffix matching operator is mapped to a fuzzy matching filter with an asterisk prefix; the containment operator is mapped to a fuzzy matching filter with an asterisk prefix and suffix; the logical AND operator is mapped to an AND filter; the logical OR operator is mapped to an OR filter; the logical NOT operator is mapped to a NOT filter; the not-empty operator is mapped to an existence filter; the empty operator is mapped to a not-existence filter; the greater than or equal to operator is mapped to a greater than or equal to filter; and the less than or equal to operator is mapped to a less than or equal to filter.

[0226] The Attribute Name Dynamic Resolution Engine converts QueryDSL path expressions into LDAP attribute names. After obtaining the LDAP attribute names and LDAP filters, the system executes the LDAP query and returns the LDAP query results. The Fluent Query engine supports chained query construction and advanced query functionality.

[0227] The attribute name dynamic resolution engine can convert Query DSL path expressions into LDAP attribute names using the Object Directory Mapper.

[0228] The embodiments of this application can provide a type-safe query interface that automatically converts Query DSL expressions into LDAP filters, and can support complex combinations of query conditions.

[0229] When executing LDAP queries, if all queries use the same execution method, query performance cannot be optimized based on the return type. To address this, this application embodiment utilizes a multi-strategy execution mode and a result processing converter to automatically select the execution strategy based on the return type, thereby optimizing query performance.

[0230] Specifically, when calling the data access interface to execute an LDAP query, the Multi-Strategy Execution Engine can select the execution strategy based on the method return type.

[0231] Specifically, if the return type is a list or collection, the collection execution strategy is selected; if the return type is a single entity or optional object, the single entity execution strategy is selected; if the return type is a stream, the streaming execution strategy is selected to perform streaming processing.

[0232] The Dynamic Projection Engine can determine whether projection is needed by analyzing the return type. Specifically, the engine can analyze the return type through the Result Processor to determine whether projection is required; it determines the projection type based on the method parameters and automatically identifies the attributes required for projection.

[0233] After executing an LDAP query and obtaining the raw results, the Result ProcessingConversion Engine converts the raw results into the target type. Finally, the ExecutionStrategy Wrapping Engine applies the result converter to complete the result processing.

[0234] Specifically, if the projection type is an interface projection, a projection factory is used to create a projection instance; if the projection type is a data transfer object projection, a data transfer object instantiation converter is used for instantiation.

[0235] The execution strategy wrapper engine is used to execute strategies. By wrapping the execution strategy with Result Processing Execution, it applies result transformers after query execution, supports chained result processing, and enables complex result transformations.

[0236] Different versions of the data access interface base class may support different constructor parameters, requiring detection and selection of the appropriate constructor. This application's embodiments support backward compatibility with older versions of the data access interface base class and provide flexible version migration support through constructor reflection detection and version compatibility handling.

[0237] Specifically, when creating a data access interface instance, the constructor reflection detection engine examines the constructor of the data access interface base class to determine whether LDAP mapping context parameters are supported.

[0238] The constructor reflection detection engine can detect whether the data access interface base class supports LDAP mapping context parameters by accepting the mapping context method; it can also check the parameter types and quantities by traversing all declared constructors; if a 4-parameter constructor exists and the second parameter is of the LDAP mapping context type, then mapping context is supported.

[0239] The Version Compatibility Processing Engine selects the appropriate constructor based on the detection results. Specifically, it uses a 4-parameter constructor if mapping context is supported, and a 3-parameter constructor if mapping context is not supported.

[0240] Optionally, the Reflection Optimization Engine can cache constructor detection results to avoid repeated reflections.

[0241] The embodiments of this application are backward compatible with older versions of the data access interface, supporting flexible version migration, reducing reflection overhead, and improving performance.

[0242] Based on the above embodiments, the embodiments of this application can avoid AD server referral problems and optimize query performance through AD referral exception handling and query optimization mechanisms.

[0243] Specifically, when executing an LDAP query, the AD Referral ExceptionHandling Engine avoids referral exceptions by setting the LDAP operation template to ignore partial result exceptions.

[0244] The Query Optimization Engine can optimize queries based on query type. For example, if the query type is a counting operation, only object class attributes are queried; if the query type is a projection query, only necessary attributes are queried; and if the query is a streaming query, a streaming return type is used.

[0245] The system executes an LDAP query and obtains the LDAP query results. If an exception occurs, the Exception Graceful Handling Engine processes the exception file.

[0246] For example, if the name is not found exception, a null value for the optional object is returned; if the null result data access exception is returned, a null value for the optional object is returned.

[0247] The Query Result Filtering Engine can filter LDAP query results to return only the complete data.

[0248] This application's embodiments improve system stability by avoiding AD server referral issues; optimize query performance to reduce network transmission and memory usage; and improve API usability through exception handling.

[0249] When adding or modifying groups, embodiments of this application can avoid configuration conflicts by checking whether group names are duplicated. Specifically, embodiments of this application prevent configuration conflicts and improve configuration quality through group name deduplication mechanism and configuration conflict detection, and multi-layer verification ensures configuration correctness.

[0250] Specifically, when adding or modifying a group, the Group Name Duplicate CheckEngine can check whether the group name already exists; if the group name already exists, it returns an error message.

[0251] The Configuration Conflict Detection Engine checks whether the group name matches the group name in the Active Directory domain to verify the integrity of the group configuration and prevent invalid configurations from causing synchronization failures.

[0252] The Configuration Validation Process Engine can perform multi-layered validation. Specifically, it performs connection tests before saving the configuration; it performs mapping tests before saving the mapping relationships; if all validation tests pass, the configuration is saved; if any validation test fails, an error message is returned.

[0253] The group name deduplication mechanism and configuration conflict detection in this application embodiment can prevent configuration conflicts and improve configuration quality.

[0254] Data synchronization involves a large number of data operations. The embodiments of this application can significantly improve performance through batch operation strategies and transactional guarantees, while transactional guarantees ensure data consistency.

[0255] Specifically, during data synchronization, the Batch Operation Engine constructs separate lists for adding and updating users, batch inserts new users, batch updates existing users, batch saves snapshots, batch saves access domains, and batch updates group members. Furthermore, the transactional guarantee engine executes the entire synchronization process within a single transaction, automatically rolling back the transaction if any step fails.

[0256] As can be seen from the above, the embodiments of this application achieve an enterprise-level AD domain user management solution with zero-downtime configuration updates, intelligent data mapping, automated permission allocation, and efficient batch synchronization through runtime dynamic LDAP configuration, intelligent field mapping, automated permission allocation, multi-dimensional data synchronization, and efficient batch processing.

[0257] The technical solution provided in this application can be applied to enterprise-level police systems, significantly improving system flexibility, reliability, scalability, and operational efficiency. By deeply integrating Spring Data LDAP's dynamic query generation, attribute mapping, fragment composition, and execution strategy optimization, combined with runtime dynamic configuration, intelligent field mapping, multi-dimensional filtering, batch operation optimization, and event notification mechanisms, an enterprise-level AD domain user management solution is achieved, featuring zero-downtime configuration updates, intelligent data mapping, automated permission allocation, and efficient batch synchronization. This solves the pain points of traditional solutions, such as static configuration, manual mapping, and lack of automation.

[0258] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0259] Corresponding to the printing method described in the above embodiments, Figure 11 A schematic block diagram of the LDAP connection configuration device provided in the embodiments of this application is shown. For ease of explanation, only the parts related to the embodiments of this application are shown.

[0260] Reference Figure 11 The device includes: Module 1110 is used to obtain LDAP connection configuration parameters and LDAP template instances; Create a populate module 1120 to create an LDAP context source instance and populate the LDAP connection configuration parameters in the LDAP context source instance to obtain the LDAP context source instance with the parameters populated. Replacement module 1130 is used to inject the LDAP context source instance with populated parameters into the LDAP template instance to replace the existing LDAP connection source with the target LDAP connection source, which is the connection source obtained according to the LDAP connection configuration parameters; Initialization module 1140 is used to initialize the LDAP template instance of the replaced connection source so that the target LDAP connection source becomes effective.

[0261] In some possible implementations, the device also includes an intelligent field mapping module, used to: obtain field mapping configuration information, which includes the correspondence between Active Directory attribute fields and business system fields; query whether Active Directory attribute fields exist in the Active Directory domain through the target LDAP connection source; if Active Directory attribute fields exist in the Active Directory domain and are accessible, obtain the Active Directory attribute fields; filter the Active Directory attribute fields to obtain filtered Active Directory attribute fields; map the filtered Active Directory attribute fields to business system fields according to the field mapping configuration information, and synchronize the business system fields to the business system.

[0262] In some possible implementations, the device also includes a group permission allocation module, used for: obtaining user data from an Active Directory domain via a target LDAP connection source; parsing the user data to obtain the group name of the group to which the user belongs; determining the user's role, police force, and access domain type based on the group name and the mapping relationship between the group name and business system permissions; the mapping relationship between the group name and business system permissions includes the mapping relationship between the group name and business system roles, the mapping relationship between the group name and police force, and the mapping relationship between the group name and access domain type; and generating access domain data corresponding to the user's access domain type.

[0263] In some possible implementations, the device also includes a multidimensional data synchronization module for: creating a data synchronization task in response to a user's data synchronization operation; clearing the group member list and querying user data from the Active Directory domain via a target LDAP connection source by executing the data synchronization task; filtering the user data to obtain filtered user data; synchronizing the filtered user data and associated data from the Active Directory domain to the business system to obtain synchronization results; and updating the group member list based on the synchronization results.

[0264] In some possible implementations, the multidimensional data synchronization module is specifically used to: return the task identifier of the data synchronization task; if it is determined that the data synchronization task is being executed based on the task identifier, then update the status of the synchronization triggering device to the disabled state, and the synchronization triggering device is used to trigger the data synchronization task; during the execution of the data synchronization task, poll the status of the data synchronization task through the task identifier; if it is determined that the status of the data synchronization task is completed, then update the status of the synchronization triggering device to the available state.

[0265] In some possible implementations, the device also includes an LDAP authentication module for: obtaining a login request, which includes a username and password; determining the distinguishable name corresponding to the username by matching the account name attributes of the security account management system; invoking the password verification function through the target LDAP connection source, and sending the distinguishable name and password to the LDAP server so that the LDAP server can perform password verification based on the distinguishable name and password; and obtaining the authentication result returned by the LDAP server.

[0266] In some possible implementations, the device also includes an LDAP query module for: obtaining an LDAP query request; invoking a data access interface in response to the LDAP query request; dividing the method name of the data access interface into multiple query conditions by parsing the method name; generating an LDAP filter based on the multiple query conditions; and executing an LDAP query through the LDAP filter to obtain the query results.

[0267] It should be noted that the information interaction and execution process between the above-mentioned devices / modules are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0268] Figure 12 This is a schematic block diagram of the structure of an electronic device provided in an embodiment of this application. Figure 12 As shown, the electronic device 12 of this embodiment includes: at least one processor 120 ( Figure 12 (Only one is shown in the diagram), memory 121, and computer program 122 stored in said memory 121 and executable on said at least one processor 120, wherein said processor 120 executes said computer program 122 to implement the steps of any of the above method embodiments.

[0269] The electronic device may include, but is not limited to, a processor 120 and a memory 121. Those skilled in the art will understand that... Figure 12 This is merely an example of electronic device 12 and does not constitute a limitation on electronic device 12. It may include more or fewer components than shown, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0270] The processor 120 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0271] In some embodiments, the memory 121 may be an internal storage unit of the electronic device 12, such as a hard disk or memory of the electronic device 12. In other embodiments, the memory 121 may be an external storage device of the electronic device 12, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the electronic device 12. Furthermore, the memory 121 may include both internal and external storage units of the electronic device 12. The memory 121 is used to store the operating system, applications, bootloader, data, and other programs, such as the program code of the computer program. The memory 121 can also be used to temporarily store data that has been output or will be output.

[0272] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0273] Furthermore, the specific names of each functional unit and module are merely for easy differentiation and are not intended to limit the scope of protection of this application. The specific working processes of the units and modules in the above system can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0274] This application also provides an electronic device, which includes: at least one processor, a memory, and a computer program stored in the memory and executable on the at least one processor, wherein the processor executes the computer program to implement the steps in any of the above method embodiments.

[0275] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps described in the various method embodiments above.

[0276] This application provides a computer program product that, when run on an electronic device, enables the electronic device to perform the steps described in the various method embodiments above.

[0277] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographing device / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0278] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0279] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0280] In the embodiments provided in this application, it should be understood that the disclosed devices, electronic devices, and methods can be implemented in other ways. For example, the device / electronic device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings or direct couplings or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0281] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0282] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for configuring a Lightweight Directory Access Protocol (LDAP) connection, characterized in that, include: Retrieve LDAP connection configuration parameters and LDAP template instance; Create an LDAP context source instance and populate the LDAP connection configuration parameters into the LDAP context source instance to obtain the LDAP context source instance with the parameters populated; The LDAP context source instance with the populated parameters is injected into the LDAP template instance to replace the existing LDAP connection source with the target LDAP connection source, which is a connection source obtained according to the LDAP connection configuration parameters; The LDAP template instance whose connection source has been replaced is initialized to enable the target LDAP connection source.

2. The method as described in claim 1, characterized in that, After the target LDAP connection source becomes active, the method further includes: Obtain field mapping configuration information, which includes the correspondence between Active Directory attribute fields and business system fields; The Active Directory attribute field is queried in the target LDAP connection source to determine whether it exists in the Active Directory domain. If the Active Directory attribute field exists in the Active Directory domain and the Active Directory attribute field is accessible, then the Active Directory attribute field is retrieved. Filter the Active Directory attribute fields to obtain the filtered Active Directory attribute fields; According to the field mapping configuration information, the filtered Active Directory attribute fields are mapped to business system fields, and the business system fields are synchronized to the business system.

3. The method as described in claim 1, characterized in that, After the target LDAP connection source becomes active, the method further includes: User data is obtained from the Active Directory domain through the target LDAP connection source; The user data is parsed to obtain the group name to which the user belongs; Based on the group name and the mapping relationship between the group name and the business system permissions, the user's role, police force, and access domain type are determined; the mapping relationship between the group name and the business system permissions includes the mapping relationship between the group name and the business system role, the mapping relationship between the group name and the police force, and the mapping relationship between the group name and the access domain type. Based on the user's access domain type, generate access domain data corresponding to the access domain type.

4. The method as described in claim 1, characterized in that, After the target LDAP connection source becomes active, the method further includes: In response to user data synchronization requests, create a data synchronization task; By executing the data synchronization task, the group member list is cleared, and user data is queried from the Active Directory domain through the target LDAP connection source; The user data is filtered to obtain filtered user data; The filtered user data and associated data are synchronized from the Active Directory domain to the business system to obtain the synchronization result. Update the group member list based on the synchronization results.

5. The method as described in claim 4, characterized in that, After creating the data synchronization task, the method further includes: Return the task identifier of the data synchronization task; If it is determined that the data synchronization task is being executed based on the task identifier, the status of the synchronization triggering device is updated to disabled. The synchronization triggering device is used to trigger the data synchronization task. During the execution of the data synchronization task, the status of the data synchronization task is polled using the task identifier; If the data synchronization task is determined to be in a completed state, the state of the synchronization triggering device is updated to an available state.

6. The method as described in claim 4, characterized in that, After the target LDAP connection source becomes active, the method further includes: Obtain a login request, which includes a username and password; The distinguishable name corresponding to the username is determined by matching the account name attributes in the security account management system. By invoking the password verification function through the target LDAP connection source, the distinguishable name and the password are sent to the LDAP server so that the LDAP server can perform password verification based on the distinguishable name and the password; Obtain the authentication result returned by the LDAP server.

7. The method according to any one of claims 1 to 6, characterized in that, After the target LDAP connection source becomes active, the method further includes: Obtain LDAP query request; In response to the LDAP query request, the data access interface is invoked; By parsing the method name of the data access interface, the method name can be divided into multiple query conditions; Generate an LDAP filter based on the multiple query conditions; LDAP queries are executed through the LDAP filter to obtain query results.

8. A Lightweight Directory Access Protocol (LDAP) connection configuration device, characterized in that, include: The acquisition module is used to obtain LDAP connection configuration parameters and LDAP template instances; Create a populate module to create an LDAP context source instance and populate the LDAP connection configuration parameters into the LDAP context source instance to obtain an LDAP context source instance with populated parameters; The replacement module is used to inject the LDAP context source instance with the populated parameters into the LDAP template instance to replace the existing LDAP connection source with the target LDAP connection source, which is a connection source obtained according to the LDAP connection configuration parameters; An initialization module is used to initialize the LDAP template instance that has had its connection source replaced, so that the target LDAP connection source becomes effective.

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

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 7.

Images