Gateway and subsystem authority linkage control method integrating LDAP (Lightweight Directory Access Protocol) based on Keycloak

Abstract

The invention discloses a Keyblock-based portal and subsystem authority linkage control method for integrating an LDAP (Lightweight Directory Access Protocol), belongs to the technical field of identity authentication and authority management, and aims to solve the technical problem of how to realize authority management of user data unification, portal centralized authority control, subsystem authority flexibility, change real-time synchronization and operation traceability. In order to overcome the defects of user data dispersion, poor authority linkage and insufficient subsystem authority flexibility in the prior art, the technical scheme adopted by the invention is as follows: the method comprises the following steps of: centrally storing total user data of an enterprise by deploying an LDAP (Lightweight Directory Access Protocol) server, and realizing user data synchronization and authentication authorization by configuring a Keycloak server; the portal system synchronizes user data of LDAP and Keyblock through a timed task, a development subsystem management module and a user management module realize permission batch management, and a permission change notification is pushed based on an MQTT mechanism; and the subsystem is in butt joint with the Key block to complete authentication, receives the notification through the MQTT and updates the local user permission in real time.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of identity authentication and permission management, in particular to a portal and subsystem permission linkage control method based on Keycloak integration of LDAP. BACKGROUND

[0002] In enterprise-level information systems, the portal system, as a unified entrance, usually needs to interface with multiple business subsystems (such as OA systems, CRM systems, data platforms, etc.). When users access the portal and subsystems, identity authentication and permission verification are required to ensure data security and operation compliance. At the same time, there are two core demand problems:

[0003] ① User data uniformity: the portal and subsystems need to share a unified user list to avoid inconsistent user information in multiple systems;

[0004] ② Subsystem permission flexibility: each subsystem needs to independently maintain internal role permissions to meet individualized business logic.

[0005] In the prior art, the following problems exist in permission management:

[0006] ① If user data and permissions are managed uniformly in full, it will limit the flexibility of subsystem permissions and make it difficult to adapt to individualized businesses;

[0007] ② If the subsystems independently maintain users and permissions, it will lead to scattered user data and the portal cannot uniformly control access permissions;

[0008] ③ When permissions change, the portal and subsystems are synchronized with a lag, which is prone to permission invalidation or unauthorized access;

[0009] ④ There is a lack of full-link auditing of user operations and permission changes, making it difficult to trace security incidents.

[0010] Keycloak, as an identity authentication platform, can integrate LDAP (Lightweight Directory Access Protocol) to achieve centralized management of user data, but it does not design a linkage mechanism for the scenario of "portal unified control of access permissions + subsystem independent maintenance of internal permissions", and cannot balance data uniformity and permission flexibility.

[0011] Therefore, how to achieve user data uniformity, portal centralized control, subsystem permission flexibility, real-time synchronization of changes, and operation traceability of permission management, and overcome the defects of scattered user data, poor permission linkage, and insufficient subsystem permission flexibility in the prior art, is a technical problem that needs to be solved urgently. SUMMARY

[0012] The technical objective of this invention is to provide a portal and subsystem permission linkage control method based on Keycloak and LDAP integration, in order to solve the problem of how to achieve unified user data, centralized portal control, flexible subsystem permissions, real-time synchronization of changes, and traceable operation permission management, and overcome the shortcomings of existing technologies such as scattered user data, poor permission linkage, and insufficient flexibility of subsystem permissions.

[0013] The technical objective of this invention is achieved as follows: a portal and subsystem permission linkage control method based on Keycloak and LDAP integration, the specific method being as follows:

[0014] By deploying an LDAP server to centrally store all of the enterprise's user data, and configuring a Keycloak server to achieve user data synchronization and authentication authorization;

[0015] The portal system synchronizes user data between LDAP and Keycloak through scheduled tasks, develops subsystem management modules and user management modules to realize batch permission management, and pushes permission change notifications based on the MQTT mechanism;

[0016] The subsystem integrates with Keycloak to complete authentication, receives notifications via MQTT, and updates local user permissions in real time.

[0017] As a preferred option, deploying an LDAP server serves as the unified storage hub for enterprise-level user data. This centrally manages all basic user information, including core fields such as user account, department, organization (company), and account status (enabled / disabled). It also supports extended storage of personalized attributes such as user name, contact information, and job title. Furthermore, it achieves structured organization of user data through the unique hierarchical structure of directory services (e.g., hierarchical storage by company → department → user). This not only meets the system's need for sharing basic information but also provides efficient query capabilities for subsequent filtering of users by organization (e.g., personnel from specific companies or departments). At the same time, the LDAP access control mechanism ensures the security of user data access.

[0018] As a preferred option, the Keycloak Admin UI console should be configured as follows when configuring the Keycloak server:

[0019] Create a custom Realm (domain) to ensure that the portal system and subsystems are under the same Realm, and connect to the LDAP server through the LDAP connector to synchronize all user data;

[0020] Under the Clients menu, create a unique Client for each subsystem and configure the ClientID, Valid redirectURIs, and Web origins information.

[0021] Each client is configured with only one default role. The role represents the permission to "access this subsystem". To configure the role, the role is located in the Client list tab under the Clients menu. Find the corresponding subsystem ClientID, enter the Client details page through the subsystem ClientID, and create a custom role through the Roles tab. Use the ClientID-role format (replace ClientID with the corresponding subsystem ID) and fill in the Description field information for easy management later.

[0022] Under the Users menu, map the roles permissions of manage-clients and manage-users under the realm-management client to the portal administrator user account, making it easier to call the Keycloak Admin API in REST.

[0023] Preferably, the portal system configures Spring Security's JWT authentication settings for the OAuth 2.0 resource server by configuring the `spring.security.oauth2.resourceserver.jwt.jwk-set-uri` parameter (whose value points to the JWK collection address of the deployed Keycloak server) in the YAML configuration file. It also configures the Keycloak's `auth-server-url` and realm information in the YAML configuration file to provide basic parameters for URL concatenation when the RestTemplate calls the Keycloak Admin RESTAPI. Additionally, it configures LDAP connection information (urls, base, authentication account and password) and user search scope (user-search-base) to retrieve a list of users from a specific company or department.

[0024] As a preferred approach, when the portal system synchronizes user data between LDAP and Keycloak via scheduled tasks, it adopts a collaborative strategy that combines Keycloak data with scheduled tasks. Specifically, the user data synchronization process is triggered periodically by scheduled tasks. First, basic user data is obtained from LDAP, and the unique identifier (such as email address) is extracted from the basic user data. Then, the / admin / realms / {realm} / users interface of Keycloak is called to query the detailed information of the corresponding user. Finally, the standardized data is stored in the local database.

[0025] For departing users, LDAP directly removes their data. The portal system employs a logical deletion mechanism that preserves complete operation traces while ensuring data processing standardization. Specifically, the logical deletion mechanism involves pre-setting the `is_use` and `delete_time` fields in the local database. The initial value of `is_use` is 1, indicating the user is valid. `delete_time` records the logical deletion time. During data updates, all users' `is_use` is uniformly set to 0. When synchronizing data from LDAP and Keycloak, for existing or newly added valid users, the corresponding `is_use` is reset to 1. After the update, for users with `is_use` of 0 and `delete_time` empty (i.e., departing users not synchronized), `delete_time` is automatically populated with the current time. The front-end interface only displays users with `is_use` of 1, ensuring the operation view focuses on valid users.

[0026] As a preferred option, a subsystem management module is developed to implement full lifecycle management of subsystem client information. This full lifecycle management of subsystem client information includes a subsystem management list, a role list, and a list of users associated with those roles; specifically as follows:

[0027] Call Keycloak's / admin / realms / {realm} / clients interface (based on ClientRepresentation) to retrieve the subsystem management list;

[0028] The list of roles for a specified subsystem can be obtained through Keycloak's / admin / realms / {realm} / clients / {client-uuid} / roles interface (based on RoleRepresentation);

[0029] Use Keycloak's / admin / realms / {realm} / clients / {client-uuid} / roles / {role-name} / users interface (based on UserRepresentation) to query the list of users associated with a role;

[0030] To address the limitation of Keycloak's inability to add or remove user roles in batches, a subsystem management module was developed. Based on user data stored in a local database (including personalized attributes such as company and department synchronized with LDAP), it supports retrieving users by organizational dimension (such as company or department). By batch selecting user groups, it can repeatedly call Keycloak's / admin / realms / {realm} / users / {user-id} / role-mappings / clients / {client-uuid} interface to complete batch authorization or permission revocation, significantly improving operational efficiency and flexibility.

[0031] As a preferred option, the user management module is used to focus on the permission mapping management between users and subsystems. It has functions such as displaying a user management list, a role mapping list, a full role list, batch adding roles, and removing roles, as detailed below:

[0032] Query the local database to obtain all user data, and call the Keycloak / admin / realms / {realm} / users / {user-id} / role-mappings interface based on the user-id (received through a custom KeycloakRoleMappingsResponse entity) to obtain the current role mapping relationship of the corresponding user;

[0033] Simultaneously, the ` / admin / realms / {realm} / ui-ext / available-roles / users / {user-id}` interface (based on a custom AvailableRole entity) is called to obtain a full list of client roles that can be assigned to the user;

[0034] For role assignment scenarios, it supports batch selection of target role groups and completes batch authorization by repeatedly calling Keycloak's / admin / realms / {realm} / users / {user-id} / role-mappings / clients / {client-uuid} interface, which efficiently realizes the management of user and role mapping relationship and improves the convenience of permission configuration.

[0035] As a preferred approach, the portal system collects three types of operation logs: subsystem management-related operations (such as batch allocation of Client role users), user permission management operations (such as role permission adjustment), and execution details of scheduled data update tasks (such as synchronization results and exception information). Each log entry is associated with the user who performed the operation, the subsystem involved, the operation time, and the specific content, forming a traceable audit chain. At the same time, the portal system supports multi-condition queries by user, subsystem, or time dimension, and realizes full-process traceability of permission changes through structured log data, meeting the enterprise's compliance audit requirements and providing accurate data support for investigating permission anomalies.

[0036] As a preferred approach, the portal system integrates MQTT to enable message push capabilities, ensuring that permission change notifications are efficiently delivered to subsystems, as detailed below:

[0037] Configure the MQTT server connection information in the YAML configuration file. The connection information includes the server address (broker-url), port, authentication account and password, client ID (ensure unique identification), and connection timeout.

[0038] Configure message publishing parameters, including the default topic (divided by subsystem client-id, such as permissions / {client-id} / changes), message QoS level (ensuring at least one delivery), and whether to retain messages;

[0039] Initialize an MQTT client instance, encapsulate a message publishing utility class, and support sending permission change messages (including user-id, operation type, timestamp, etc.) by dynamically specifying topics according to subsystems;

[0040] Configure client reconnection mechanisms (such as automatic reconnection after disconnection, reconnection interval strategy) to ensure the reliability of message push and avoid notification loss due to network fluctuations.

[0041] More ideally, the subsystem configures Keycloak connection information (auth-server-url, realm, resource) in the YAML configuration file to achieve authentication integration with Keycloak. During subsystem initialization, it calls the portal system's backend interface using its own client-id to obtain the list of users granted the default role in this system, completing the initialization of the local user database. This ensures that only users authorized by the portal can log in to the subsystem, ensuring controllable access sources. Simultaneously, the subsystem integrates an MQTT client specifically for receiving permission change notifications pushed by the portal system. When the portal system adjusts a user's subsystem access permissions by adding or removing a user, it immediately sends a change instruction to the corresponding subsystem via MQTT message. The change instruction includes the user-id, operation type, and timestamp information. After receiving the message, the subsystem updates its local user list in real time, ensuring that permission changes take effect immediately and achieving dynamic synchronization of user data with the portal.

[0042] The portal and subsystem permission linkage control method based on Keycloak and LDAP integration of the present invention has the following advantages:

[0043] (i) This invention solves the problems of scattered user data, poor permission linkage, and insufficient flexibility of subsystem permissions in the prior art. It realizes unified user data, centralized portal control, flexible subsystem permissions, real-time synchronization of changes, and traceable operation permission management, which is suitable for enterprise-level multi-system permission management scenarios.

[0044] (ii) The present invention adopts a collaborative strategy of “using Keycloak data as the standard” combined with scheduled tasks. It relies on Keycloak to ensure the authority of user information, and uses scheduled tasks to realize dynamic data updates, ensuring that the user information in the local database is consistent with Keycloak, while avoiding the data inconsistency problem caused by the difference between LDAP and Keycloak fields.

[0045] (iii) The logical deletion mechanism of the present invention is linked with the removal operation of departing users in LDAP, and retains complete data traces through logical deletion (supporting audit traceability). At the same time, it accurately distinguishes the validity of users through status fields, balancing data timeliness and historical traceability.

[0046] (iv) This invention enables the portal system to trigger MQTT message push in real time when permissions change, providing an efficient and reliable source for permission synchronization triggering for subsystems;

[0047] (V) This invention centrally stores basic user data through LDAP, synchronizes and manages user information using Keycloak, and combines scheduled tasks to ensure consistency between local database data and Keycloak data, thus solving the problem of data dispersion across multiple systems and achieving unified user data.

[0048] (vi) The portal system of the present invention pushes permission change notifications through the MQTT mechanism, and the subsystem updates local user permissions in real time, avoiding the lag of traditional timed synchronization, ensuring that permission changes take effect immediately, thus realizing efficient and real-time permission linkage.

[0049] (vii) Each subsystem of the present invention achieves the separation of "portal control of access and subsystem management of internal affairs" through the unique default role of Keycloak Client, which not only ensures the centralized control of access permissions by the portal, but also gives the subsystem permission management flexibility.

[0050] (viii) This invention uses logical deletion (is_use + delete_time field) instead of physical deletion to retain user operation traces; it is linked with the removal operation of departing users in LDAP to ensure data timeliness and audit traceability, thereby realizing the traceability of the processing standards for departing users;

[0051] (ix) This invention addresses the limitation of Keycloak's lack of support for bulk authorization by filtering users by organization dimension (company or department) through a local library and repeatedly calling the Keycloak Admin REST API to achieve bulk permission allocation and revocation, improving operational efficiency by more than 80% and greatly enhancing the efficiency of bulk operation management.

[0052] (x) This invention collects logs of subsystem management, permission operation, scheduled tasks, etc., supports multi-dimensional query, realizes full-process traceability of permission changes, meets the enterprise's compliance and security audit needs, and ensures that the full-link audit meets compliance requirements;

[0053] (xi) When adding a new subsystem, this invention only requires configuring the Client in Keycloak without modifying the core permission control logic, adapting to the iterative needs of enterprise systems and having strong scalability. Attached Figure Description

[0054] The invention will be further described below with reference to the accompanying drawings.

[0055] Appendix Figure 1 This is a schematic diagram of a portal and subsystem permission linkage control method based on Keycloak and LDAP integration;

[0056] Appendix Figure 2 Flowchart for permission change notification;

[0057] Appendix Figure 3 This is a flowchart of the permission verification process. Detailed Implementation

[0058] The following detailed description of the portal and subsystem permission linkage control method based on Keycloak and LDAP integration according to the present invention is provided with reference to the accompanying drawings and specific embodiments.

[0059] Example 1:

[0060] As attached Figure 1 As shown in the figure, this embodiment provides a method for portal and subsystem permission linkage control based on Keycloak and LDAP integration. The method is as follows:

[0061] S1. By deploying an LDAP server to centrally store all of the enterprise's user data, and configuring a Keycloak server to achieve user data synchronization and authentication authorization;

[0062] S2. The portal system synchronizes user data between LDAP and Keycloak through scheduled tasks, develops subsystem management modules and user management modules to realize batch permission management, and pushes permission change notifications based on the MQTT mechanism.

[0063] S3 and its subsystems interface with Keycloak to complete authentication, receive notifications via MQTT, and update local user permissions in real time.

[0064] In step S1 of this embodiment, the deployment of an LDAP server serves as the unified storage hub for enterprise-level user data. It centrally manages all basic user information, including core fields such as user account, department, enterprise organization (company), and account status (enabled / disabled). It supports extended storage of personalized attributes such as user name, contact information, and job title. Through the unique hierarchical structure of the directory service (such as hierarchical storage by company → department → user), it achieves structured organization of user data. This not only meets the system's need for sharing basic information but also provides efficient query capabilities for subsequent filtering of users by organizational dimension (such as personnel from specific companies or departments). At the same time, it ensures the security of user data access through LDAP's access control mechanism.

[0065] In step S1 of this embodiment, when configuring the Keycloak server, the specific configuration of the Keycloak Admin UI console is as follows:

[0066] S101. Create a custom Realm (domain). Ensure that the portal system and subsystems are under the same Realm and connect to the LDAP server through the LDAP connector to synchronize all user data.

[0067] S102. Under the Clients menu, create a unique Client for each subsystem and configure the ClientID, Validredirect URIs, and Web origins information;

[0068] S103. Each Client is configured with only one default Role. The Role represents the permission to "access this subsystem". To configure the Role, the Role is located in the Client list tab under the Clients menu. Find the corresponding subsystem ClientID, enter the Client details page through the subsystem ClientID, and create a custom Role through the Roles tab. Use the ClientID-role format (replace ClientID with the corresponding subsystem ID) and fill in the Description field information for easy management later.

[0069] S104. Under the Users menu, map the roles permissions of manage-clients and manage-users under the realm-management client to the portal administrator user account to facilitate calling the Keycl Oak Admin REST API.

[0070] In step S2 of this embodiment, the portal system completes the JWT authentication settings for the OAuth 2.0 resource server by configuring the `spring.security.oauth2.resourceserver.jwt.jwk-set-uri` parameter (whose value points to the JWK collection address of the deployed Keycloak server) in the YAML configuration file. It also configures the Keycloak's `auth-server-url` and `realm` information in the YAML configuration file to provide basic parameters for URL concatenation when the RestTemplate calls the KeycloakAdmin REST API. Simultaneously, it configures the LDAP connection information (urls, base, authentication account password) and user search scope (user-search-base) to obtain a user list for a specific company or department.

[0071] In step S2 of this embodiment, when the portal system synchronizes user data between LDAP and Keycloak through scheduled tasks, it adopts a collaborative strategy that combines Keycloak data with scheduled tasks. Specifically, the user data synchronization process is triggered periodically through scheduled tasks. First, the basic user data is obtained from LDAP, and the unique identifier (such as email address) in the basic user data is extracted. Then, the / admin / realms / {realm} / users interface of Keycloak is called to query the detailed information of the corresponding user. Finally, the standardized data is stored in the local database.

[0072] For departing users, LDAP directly removes their data. The portal system employs a logical deletion mechanism that preserves complete operation traces while ensuring data processing standardization. Specifically, the logical deletion mechanism involves pre-setting the `is_use` and `delete_time` fields in the local database. The initial value of `is_use` is 1, indicating the user is valid. `delete_time` records the logical deletion time. During data updates, all users' `is_use` is uniformly set to 0. When synchronizing data from LDAP and Keycloak, for existing or newly added valid users, the corresponding `is_use` is reset to 1. After the update, for users with `is_use` of 0 and `delete_time` empty (i.e., departing users not synchronized), `delete_time` is automatically populated with the current time. The front-end interface only displays users with `is_use` of 1, ensuring the operation view focuses on valid users.

[0073] In step S2 of this embodiment, the development subsystem management module is used to implement full lifecycle management of subsystem Client information. This full lifecycle management of subsystem Client information includes a subsystem management list, a role list, and a role-associated user list; specifically as follows:

[0074] S201. Call Keycloak's / admin / realms / {realm} / clients interface (based on ClientRepresentation) to obtain the subsystem management list;

[0075] S202. Obtain the list of roles for the specified subsystem through Keycloak's / admin / realms / {realm} / clients / {client-uuid} / roles interface (based on RoleRepresentation);

[0076] S203. Use Keycloak's / admin / realms / {realm} / clients / {client-uuid} / roles / {role-name} / users interface (based on UserRepresentation) to query the list of users associated with a role;

[0077] To address the limitation of Keycloak's inability to add or remove user roles in batches, a subsystem management module was developed. Based on user data stored in a local database (including personalized attributes such as company and department synchronized with LDAP), it supports retrieving users by organizational dimension (such as company or department). By batch selecting user groups, it can repeatedly call Keycloak's / admin / realms / {realm} / users / {user-id} / role-mappings / clients / {client-uuid} interface to complete batch authorization or permission revocation, significantly improving operational efficiency and flexibility.

[0078] In this embodiment, the user management module in step S2 focuses on the permission mapping management between users and subsystems. It has functions such as displaying a user management list, a role mapping list, a full role list, batch adding roles, and removing roles, as detailed below:

[0079] Query the local database to obtain all user data, and call the Keycloak / admin / realms / {realm} / users / {user-id} / role-mappings interface based on the user-id (received through a custom KeycloakRoleMappingsResponse entity) to obtain the current role mapping relationship of the corresponding user;

[0080] Simultaneously, the ` / admin / realms / {realm} / ui-ext / available-roles / users / {user-id}` interface (based on a custom AvailableRole entity) is called to obtain a full list of client roles that can be assigned to the user;

[0081] For role assignment scenarios, it supports batch selection of target role groups and completes batch authorization by repeatedly calling Keycloak's / admin / realms / {realm} / users / {user-id} / role-mappings / clients / {client-uuid} interface, which efficiently realizes the management of user and role mapping relationship and improves the convenience of permission configuration.

[0082] In this embodiment, the portal system collects three types of operation logs: subsystem management-related operations (such as batch allocation of Client role users), user permission management operations (such as role permission adjustment), and execution details of scheduled data update tasks (such as synchronization results and exception information). Each log entry is associated with the user performing the operation, the subsystem involved, the operation time, and the specific content, forming a traceable audit chain. At the same time, the portal system supports multi-condition queries by user, subsystem, or time dimension, and realizes full-process traceability of permission changes through structured log data, meeting the enterprise's compliance audit requirements and providing accurate data support for investigating permission anomalies.

[0083] As attached Figure 2 As shown, the portal system in this embodiment integrates MQTT to achieve message push capabilities, ensuring that permission change notifications are efficiently delivered to subsystems, as detailed below:

[0084] (1) Configure the MQTT server connection information in the YAML configuration file. The connection information includes the server address (broker-url), port, authentication account and password, client ID (ensure unique identification) and connection timeout.

[0085] (2) Configure message publishing parameters, including default topic (divided by subsystem client-id, such as permissions / {client-id} / changes), message QoS level (ensure at least one delivery) and whether to retain messages;

[0086] (3) Initialize the MQTT client instance, encapsulate the message publishing utility class, and support sending permission change messages (including user-id, operation type, timestamp, etc.) by dynamically specifying topics according to subsystems;

[0087] (4) Configure client reconnection mechanism (such as automatic reconnection after disconnection, reconnection interval strategy) to ensure the reliability of message push and avoid notification loss due to network fluctuations.

[0088] As attached Figure 3As shown, in step S3 of this embodiment, the subsystem configures Keycloak connection information (auth-server-url, realm, resource) in the YAML configuration file to achieve authentication integration with Keycloak. During subsystem initialization, it calls the portal system's backend interface using its own client-id to obtain the list of users granted the default role in this system, completing the initialization of the local user database and ensuring that only users authorized by the portal can log in to the subsystem, thus ensuring controllable access sources. Simultaneously, the subsystem integrates an MQTT client specifically for receiving permission change notifications pushed by the portal system. When the portal system adjusts a user's subsystem access permissions by adding or removing a user, it immediately sends a change instruction to the corresponding subsystem via MQTT message. The change instruction includes the user-id, operation type, and timestamp information. After receiving the message, the subsystem updates its local user list in real time, ensuring that permission changes take effect immediately and achieving dynamic synchronization of user data with the portal.

[0089] Example 2:

[0090] The implementation process of this invention will be described in the context of specific scenarios:

[0091] (I) Environment configuration, as detailed below:

[0092] (1) LDAP server: OpenLDAP 2.4.5 is used to store user entries (such as uid=user001,ou=dept1,dc=enterprise,dc=com), which include attributes such as name, mail, department, and enabled.

[0093] (2) Keycloak server: version 24.0.1, create a Realm named enterprise-realm, and connect to OpenLDAP through an LDAP connector (read-only + full synchronization + change user synchronization);

[0094] (3) Portal system: developed based on Spring Boot 3.3.3;

[0095] (4) Subsystem: OA system (Java Web application), Keycloak Client is oa-client, default role is oa-client-role;

[0096] (5) MQTT server: Mosquitto 2.0 is used, with the topic prefix being permissions / .

[0097] (II) The implementation steps are as follows:

[0098] (1) The LDAP stores users in department dept1 such as user001 (mail = user001@enterprise.com) and user002;

[0099] (2) Keycloak's enterprise-realm synchronizes users through the LDAP connector, creates a default role for oa-client as oa-client-role, and assigns manage-clients and manage-users permissions to the realm-management client to the portal system administrator.

[0100] (3) The YAML configuration of the portal system is as follows:

[0101] #Keycloak configuration

[0102] keycloak:

[0103] auth-server-url:http: / / keycloak-server:8080 / auth

[0104] realm:enterprise-realm

[0105] #LDAP Configuration

[0106] ldap:

[0107] urls:ldap: / / ldap-server:389

[0108] base:dc=enterprise,dc=com

[0109] username:cn=admin,dc=enterprise,dc=com

[0110] password:******

[0111] user-search-base:ou=dept1,dc=enterprise,dc=com

[0112] #MQTT Configuration

[0113] mqtt:

[0114] broker-url:tcp: / / mqtt-server:1883

[0115] client-id:portal-mqtt-client

[0116] username:mqtt-user

[0117] password: ******;

[0118] (4) User synchronization function in the portal system: The scheduled task is executed every 30 minutes to retrieve the user dept1 from LDAP, and retrieve the user details through the Keycloak interface / admin / realms / enterprise-realm / users?search={mail} via mail, and store them in the local database (including is_use=1);

[0119] (5) Handling of departing users in the portal system: After user002 leaves the company, the user is removed from LDAP; during portal synchronization, user002's is_use remains 0, and delete_time is automatically set to the synchronization time, and the front end will no longer display it;

[0120] (6) Batch authorization in the portal system: The administrator filters the dept1 user through the subsystem management module and authorizes oa-client-role in batches. The system calls the / admin / realms / enterprise-realm / users / {user-id} / role-mappings / clients / {client-uuid} interface in a loop to complete the operation;

[0121] (7) MQTT notification in the portal system: When user001 is removed from the oa-client-role, the portal pushes a message to the permissions / oa-client / changes topic: {"userId":"user001","action":"remove","timestamp":"2024-05-20T10:30:00"};

[0122] (8) Subsystem configuration: Connect to Keycloak via auth-server-url:http: / / keycloak-server:8080 / auth, realm:enterprise-realm, and resource:oa-client;

[0123] (9) Subsystem user list initialization: Call the portal interface / api / users?clientId=oa-client to get the list of users granted oa-client-role and initialize the local user database;

[0124] (10) Subsystem permission update: After receiving the MQTT message, the OA system logically removes user001 from the local database to ensure that it cannot log in;

[0125] (11) Audit traceability of the portal system: The portal log records "2025-08-21 10:30, administrator admin removed oa-client-role permission of user001", which supports querying by user user001 or subsystem oa-client to realize permission traceability.

[0126] Through the above implementation, the present invention achieves unified user data, real-time linkage of permissions, and traceability of operations, meeting the enterprise's multi-system permission management needs.

[0127] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention 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 or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A portal and subsystem permission linkage control method based on Keycloak and LDAP integration, characterized in that, The method is as follows: By deploying an LDAP server to centrally store all of the enterprise's user data, and configuring a Keycloak server to achieve user data synchronization and authentication authorization; The portal system synchronizes user data between LDAP and Keycloak through scheduled tasks, develops subsystem management modules and user management modules to realize batch permission management, and pushes permission change notifications based on the MQTT mechanism; The subsystem integrates with Keycloak to complete authentication, receives notifications via MQTT, and updates local user permissions in real time.

2. The portal and subsystem permission linkage control method based on Keycloak and LDAP integration according to claim 1, characterized in that, Deploying an LDAP server serves as the unified storage hub for enterprise-level user data, centrally managing all basic user information, including core fields such as user account, department, organization, and account status. It supports extended storage of personalized attributes such as user name, contact information, and job title, and achieves structured organization of user data through the unique hierarchical structure of directory services. This not only meets the system's need for sharing basic information but also provides efficient query capabilities for subsequent user filtering by organization dimension. At the same time, the LDAP access control mechanism ensures the security of user data access.

3. The portal and subsystem permission linkage control method based on Keycloak and LDAP integration according to claim 1, characterized in that, When configuring the Keycloak server, the specific configuration of the Keycloak Admin UI console is as follows: Create a custom Realm, ensuring that the portal system and subsystems are under the same Realm, and connect to the LDAP server through an LDAP connector to synchronize all user data; Under the Clients menu, create a unique Client for each subsystem and configure the ClientID, Valid redirectURIs, and Web origins information. Each client is configured with only one default role. The role represents the permission to "access this subsystem". To configure the role, the role is located in the Client list tab under the Clients menu. Find the corresponding subsystem ClientID, enter the Client details page through the subsystem ClientID, and create a custom role through the Roles tab. Use the ClientID-role format and fill in the Description field information. Under the Users menu, map the roles permissions of manage-clients and manage-users under the realm-management client to the portal administrator user account, making it easier to call the Keycloak Admin API in REST.

4. The portal and subsystem permission linkage control method based on Keycloak and LDAP integration according to claim 1, characterized in that, The portal system configures Spring Security's JWT authentication settings for the OAuth 2.0 resource server by configuring the `spring.security.oauth2.resourceserver.jwt.jwk-set-uri` parameter in the YAML configuration file. It also configures the `auth-server-url` and `realm` information for Keycloak in the YAML configuration file, providing basic parameters for URL concatenation when `RestTemplate` calls Keycloak Admin API. Additionally, it configures LDAP connection information and user query scope to retrieve user lists from specific companies or departments.

5. The portal and subsystem permission linkage control method based on Keycloak and LDAP integration according to claim 1, characterized in that, When the portal system synchronizes user data between LDAP and Keycloak through scheduled tasks, it adopts a collaborative strategy that combines Keycloak data with scheduled tasks. Specifically, the user data synchronization process is triggered periodically by scheduled tasks. First, the basic user data is obtained from LDAP, and the unique identifier in the basic user data is extracted. Then, the / admin / realms / {realm} / users interface of Keycloak is called to query the detailed information of the corresponding user. Finally, the standardized data is stored in the local database. For departing users, LDAP directly removes their data. The portal system employs a logical deletion mechanism that preserves complete operation traces while ensuring data processing standardization. Specifically, the logical deletion mechanism involves pre-setting the `is_use` and `delete_time` fields in the local database. The initial value of `is_use` is 1, indicating the user is valid. `delete_time` records the logical deletion time. During data updates, all users' `is_use` is uniformly set to 0. When synchronizing data from LDAP and Keycloak, for existing or newly added valid users, the corresponding `is_use` is reset to 1. After the update, for users with `is_use` of 0 and `delete_time` empty, `delete_time` is automatically populated with the current time. The front-end interface only displays users with `is_use` of 1, ensuring the operation view focuses on valid users.

6. The portal and subsystem permission linkage control method based on Keycloak and LDAP integration according to claim 1, characterized in that, A subsystem management module was developed to implement full lifecycle management of subsystem client information. This full lifecycle management includes the subsystem management list, role list, and role-associated user list; details are as follows: Call the Keycloak / admin / realms / {realm} / clients interface to retrieve the subsystem management list; Retrieve the list of roles for a specified subsystem through Keycloak's / admin / realms / {realm} / clients / {client-uuid} / roles interface; Use Keycloak's / admin / realms / {realm} / clients / {client-uuid} / roles / {role-name} / users interface to query the list of users associated with a role; To address the limitation of Keycloak not supporting batch addition or removal of user roles, a subsystem management module was developed. Based on user data stored in a local library, it supports searching for users by organization. By batch selecting user groups, it can repeatedly call Keycloak's / admin / realms / {realm} / users / {user-id} / role-mappings / clients / {client-uuid} interface to complete batch authorization or permission revocation, significantly improving operational efficiency and flexibility.

7. The portal and subsystem permission linkage control method based on Keycloak and LDAP integration according to claim 1, characterized in that, The user management module focuses on the permission mapping management between users and subsystems. It features a user management list, a role mapping list, a full role list display, batch addition of roles, and removal of roles, as detailed below: Query the local database to obtain all user data, and call Keycloak's / admin / realms / {realm} / users / {user-id} / role-mappings interface based on user-id to obtain the current role mapping relationship of the corresponding user; Simultaneously, the ` / admin / realms / {realm} / ui-ext / available-roles / users / {user-id}` interface is called to obtain a full list of client roles that can be assigned to the user; For role assignment scenarios, it supports batch selection of target role groups and completes batch authorization by repeatedly calling Keycloak's / admin / realms / {realm} / users / {user-id} / role-mappings / clients / {client-uuid} interface, which efficiently realizes the management of user and role mapping relationship and improves the convenience of permission configuration.

8. The portal and subsystem permission linkage control method based on Keycloak and LDAP integration according to claim 1, characterized in that, The portal system collects three types of operation logs: subsystem management-related operations, user permission management operations, and execution details of scheduled data update tasks. Each log entry is associated with the user who performed the operation, the subsystem involved, the operation time, and the specific content, forming a traceable audit chain. At the same time, the portal system supports multi-condition queries by user, subsystem, or time dimension, and realizes full-process traceability of permission changes through structured log data, meeting the enterprise's compliance audit requirements and providing accurate data support for investigating permission anomalies.

9. The portal and subsystem permission linkage control method based on Keycloak and LDAP integration according to claim 1, characterized in that, The portal system integrates MQTT to enable message push capabilities, ensuring that permission change notifications are efficiently delivered to subsystems, as detailed below: Configure the MQTT server connection information in the YAML configuration file. The connection information includes the server address, port, authentication account and password, client ID, and connection timeout. Configure message publishing parameters, including default topic, message QoS level, and whether to retain messages; Initialize an MQTT client instance, encapsulate a message publishing utility class, and support sending permission change messages by dynamically specifying topics according to subsystems; Configure a client reconnection mechanism to ensure the reliability of message push and avoid notification loss due to network fluctuations.

10. The portal and subsystem permission linkage control method based on Keycloak and LDAP integration according to any one of claims 1 to 9, characterized in that, The subsystem configures Keycloak connection information in its YAML configuration file to achieve authentication integration with Keycloak. During subsystem initialization, it calls the portal system's backend interface using its own client-id to obtain the list of users granted the default role in this system, completing the initialization of the local user database. This ensures that only users authorized by the portal can log in to the subsystem, guaranteeing controllable access sources. Simultaneously, the subsystem integrates an MQTT client specifically for receiving permission change notifications pushed by the portal system. When the portal system adjusts a user's subsystem access permissions by adding or removing a user, it immediately sends a change command to the corresponding subsystem via MQTT message. The change command includes the user-id, operation type, and timestamp information. After receiving the message, the subsystem updates the local user list in real time to ensure that permission changes take effect immediately and achieve dynamic synchronization of user data with the portal.

Images