Spring Security's single sign-on multiplexing method

Abstract

The application belongs to the technical field of computer software, and particularly relates to a single-point authentication multiplexing method of SpringSecurity, wherein multi-system authentication configuration information is acquired; according to the multi-system authentication configuration information, configuration loading and initialization are carried out, a multi-path authentication configuration object is constructed, and a request filter and a multi-path authentication processor based on SpringSecurity are developed and registered; the request filter is used for listening to an authentication access point, receiving an authentication request, constructing a unified authentication token, carrying out matching search in the multi-path authentication processor according to a system identifier in the unified authentication token, and obtaining a matching result; authentication logic is executed based on the matching result, and authentication credentials are returned, wherein the authentication credentials include authentication success credentials or authentication error information. Thus, the problems such as weak adaptability and poor expansibility in the prior art are solved.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of computer software, and particularly relates to a single-point authentication multiplexing method of Spring Security. BACKGROUND

[0002] With the acceleration of new infrastructure construction and the acceleration of enterprise digital transformation process, multi-system integration scenarios are increasingly common, and the market urgently needs a high-compatibility, low-coupling and extensible single-point authentication system based on Spring Security, which requires differentiated authentication adaptation, unified configuration management and dynamic routing scheduling capabilities for multiple systems. However, the prior art fails to achieve a multi-path multiplexing architecture of authentication logic, lacks a unified configuration management mechanism for multiple systems and a flexible authentication routing strategy, and thus cannot support precise authentication requirements in complex integration scenarios, which is significantly different from the technical requirements of building a lightweight, highly adaptable and easy-to-maintain single-point authentication system.

[0003] However, the traditional Spring Security authentication scheme has the following key defects: single-system authentication logic is fixed, and when multiple systems are integrated, Filter and AuthenticationProvider need to be developed for each system, resulting in high code coupling and poor maintainability; authentication configurations are scattered in each system locally or in the core code, and adding or modifying system authentication rules requires adjusting multiple configurations simultaneously, resulting in high operation and maintenance costs; there is a lack of a dynamic matching mechanism based on system identification, and multiple system authentication requests use traversal matching or hard-coded judgment, resulting in low routing efficiency and a high risk of matching conflicts; there is a lack of fallback adaptation capability for newly added systems that are not pre-configured, resulting in insufficient compatibility and difficulty in meeting the needs of multiple system access caused by rapid expansion of enterprises. With the deepening of multi-system collaborative office and cross-platform business integration, the market's demand for high-reliability and flexible expansion of single-point authentication schemes is increasingly urgent, and the existing technology is difficult to support authentication applications in complex scenarios due to its weak adaptability, poor scalability and high maintenance cost. SUMMARY

[0004] The application provides a single-point authentication multiplexing method of Spring Security to solve the problems of weak adaptability and poor scalability in the prior art.

[0005] The first aspect of this application provides a Spring Security single-signal authentication multiplexing method, comprising the following steps: obtaining multi-system authentication configuration information; loading and initializing the configuration according to the multi-system authentication configuration information, constructing a multi-signal authentication configuration object, developing and registering a Spring Security-based request filter and multi-signal authentication processor; listening to the authentication access point through the request filter, receiving authentication requests, constructing a unified authentication token, and performing a matching search in the multi-signal authentication processor according to the system identifier in the unified authentication token; if a match is successful, the request is handled by the corresponding single-signal authentication processor, otherwise it is handled by the default general authentication processor; executing authentication logic through the matched single-signal authentication processor or the default general authentication processor, and returning authentication success credentials or authentication error information.

[0006] Preferably, configuration loading and initialization are performed based on the multi-system authentication configuration information, including: constructing an authentication configuration management platform; using the authentication configuration management platform, determining the priority of authentication configurations using a configuration parsing algorithm, and obtaining an authentication configuration priority evaluation result by combining conflict risk detection; and, based on the authentication configuration priority evaluation result, performing real-time initialization of authentication configurations through a dynamic loading mechanism, identifying conflict risks and loading status, and generating an authentication ready signal and corresponding configuration status push information.

[0007] Preferably, the configuration parsing algorithm formula is:

[0008] ;

[0009] ;

[0010] in, For the first The priority score of each authentication configuration; As the system importance weight; As the system importance weight; Weights for path matching accuracy; Score the accuracy of path matching; To configure timeliness weights; To configure timeliness scores; For configuration and The conflict risk value; For the first The set of URL patterns covered by each authentication configuration; For the first The set of URL patterns covered by each authentication configuration; This is the weighting coefficient for HTTP method overlap. HTTP method overlap; is a weight coefficient of a request header parameter overlap degree; is a request header parameter overlap degree.

[0011] Preferably, the multi-path authentication configuration object is constructed, the Spring Security-based request filter and the multi-path authentication processor are developed and registered, including: constructing a multi-path authentication configuration object parsing and dynamic loading mechanism; based on the parsing and dynamic loading mechanism, standardizing conversion and dependency injection are performed on multi-system authentication rule metadata, combined with a Spring Security configuration model, to generate an extensible multi-path authentication configuration object; according to the multi-path authentication configuration object, authentication request filtering logic and multi-path processor scheduling strategies are componentized and encapsulated, and request filter registration is completed through a Spring Security FilterChainProxy extension point, and dynamic binding of a multi-path authentication processor and a default general authentication processor is implemented based on a HandlerMapping mechanism.

[0012] Preferably, according to the system identifier in the unified authentication token, a matching search is performed in the multi-path authentication processor to obtain a matching result, wherein the matching result includes: if the matching is successful, the corresponding single-path authentication processor is used for processing, and if the matching fails, a default general authentication processor is used for processing, including: constructing a unified authentication token; embedding the system identifier, user identity information and request context data in the authentication request into the unified authentication token, and extracting an effective system identifier field by using a token standardization algorithm; inputting the effective system identifier field into an identifier matching index of the multi-path authentication processor to generate a processor matching result, and using a priority matching strategy, if the matching is successful, the corresponding single-path authentication processor is directly used for processing, and if the matching fails, a default general authentication processor is triggered, wherein if the effective system identifier field is empty, it is directly classified into a matching failure scenario and is processed by the default general authentication processor.

[0013] Preferably, authentication logic is executed based on the matching result, and authentication credentials are returned, wherein the authentication credentials include: authentication success credentials or authentication error information, including: constructing an authentication logic execution context and a credential generation template; based on the authentication logic execution context and the credential generation template, combined with identity information in the unified authentication token and authentication rule configurations of the corresponding system, it is determined whether the authentication pass condition is met, and an authentication verification result is generated; according to the authentication verification result, through a credential encryption module and an error information formatting module, authentication success credentials or standardized authentication error information are generated and returned.

[0014] The second aspect embodiment of the application provides a single point authentication multiplexing method of SpringSecurity, comprising: an acquisition module configured to acquire multi-system authentication configuration information; a configuration initialization module configured to perform configuration loading and initialization according to the multi-system authentication configuration information, construct a multi-path authentication configuration object, and develop and register a request filter and a multi-path authentication processor based on SpringSecurity; a routing distribution module configured to listen to an authentication access point through the request filter, receive an authentication request, construct a unified authentication token, and perform matching search in the multi-path authentication processor according to a system identifier in the unified authentication token to obtain a matching result, wherein the matching result includes: handing over to a corresponding single-path authentication processor for processing if the matching is successful, and handing over to a default general authentication processor for processing if the matching fails; and an authentication execution module configured to execute authentication logic based on the matching result and return authentication credentials, wherein the authentication credentials include: authentication success credentials or authentication error information.

[0015] The third aspect embodiment of the application provides an electronic device, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement a single point authentication multiplexing method of SpringSecurity as described in the above embodiments.

[0016] The fourth aspect embodiment of the application provides a computer readable storage medium having a computer program stored thereon, wherein the program is executed by a processor to implement a single point authentication multiplexing method of SpringSecurity as described in the above embodiments.

[0017] The fifth aspect embodiment of the application provides a computer program product comprising a computer program or instructions for implementing a single point authentication multiplexing method of SpringSecurity as described in the above embodiments.

[0018] Thus, the present application includes the following beneficial effects: through centralized collection, standardized processing and unified packaging of multi-system authentication configuration, the authentication rules, key parameters and the like scattered in each system are integrated into multi-path authentication configuration objects, dynamic configuration update is supported without restarting the system, configuration redundancy and operation and maintenance cost are greatly reduced, and the expansion demand of business in enterprise digital transformation is adapted; accurate routing matching is realized relying on the system identifier in the unified authentication token, replacing the traditional traversal matching and hard-coded judgment mode, the routing response speed is improved by more than 50%, the authentication delay is effectively avoided in a large-scale multi-system scenario, and the stability of high-concurrency access is ensured; the single-path authentication logic can be independently developed and hot-plugged deployed through hierarchical decoupling design, the newly added system only needs to develop the corresponding processor and register, and cooperates with the default general authentication processor to realize seamless compatibility of the un-preconfigured system, shortens the online period of new business from weeks to days, and comprehensively improves the adaptation flexibility, maintainability and response efficiency of the single-point authentication system, significantly reduces the development and operation and maintenance cost of multi-system integration, and provides stable support for high-reliability single-point authentication in complex scenarios. Thus, the problems of weak adaptability and poor expansibility in the prior art are solved.

[0019] Additional aspects and advantages of the application will be set forth in part in the description that follows, and in part will become apparent to those skilled in the art upon examination of the following and / or can be learned by practice of the application. BRIEF DESCRIPTION OF DRAWINGS

[0020] The above and / or additional aspects and advantages of the present application will become apparent and be readily appreciated from the following description, taken in conjunction with the accompanying drawings, in which:

[0021] Figure 1 A flowchart of a single-point authentication multiplexing method of Spring Security according to an embodiment of the present application is provided;

[0022] Figure 2 An example diagram of a multi-path authentication process according to an embodiment of the present application is provided;

[0023] Figure 3 An example diagram of a single-point authentication multiplexing method of Spring Security according to an embodiment of the present application is provided;

[0024] Figure 4 A structural schematic diagram of a single-point authentication multiplexing system of Spring Security according to an embodiment of the present application is provided;

[0025] Figure 5 A structural schematic diagram of an electronic device according to an embodiment of the present application is provided. DETAILED DESCRIPTION

[0026] Embodiments of the present application are described below in detail, examples of which are shown in the accompanying drawings, wherein the same or similar notations represent the same or similar elements or elements having the same or similar functions throughout. The embodiments described below by referring to the accompanying drawings are exemplary and are intended to explain the present application, and cannot be understood as a limitation of the present application.

[0027] A SpringSecurity single sign-on multiplexing method of embodiments of the present application is described below with reference to the accompanying drawings. In view of the poor scalability mentioned in the background art, the present application provides a SpringSecurity single sign-on multiplexing method, in which authentication rules, key parameters, etc. scattered in each system are integrated into a multi-path authentication configuration object through centralized collection, standardized processing and unified packaging of multi-system authentication configuration, supporting dynamic configuration update without system restart, greatly reducing configuration redundancy and operation and maintenance cost, and adapting to the business expansion demand in enterprise digital transformation; relying on the system identifier in the unified authentication token to realize accurate routing matching, replacing the traditional traversal matching and hard-coded judgment mode, the routing response speed is improved by more than 50%, effectively avoiding authentication delay in large-scale multi-system scenarios, and ensuring high-concurrency access stability; the hierarchical decoupling design makes the single-path authentication logic independently developed and hot-plugged, and the newly added system only needs to develop the corresponding processor and register, combined with the default general authentication processor fallback mechanism, to realize seamless compatibility of un-preconfigured systems, shorten the new business online period from weeks to days, and comprehensively improve the adaptation flexibility, maintainability and response efficiency of the single sign-on system, significantly reducing the development and operation and maintenance cost of multi-system integration, and providing stable support for high-reliability single sign-on in complex scenarios. Thus, the problems of weak adaptability and poor scalability in the prior art are solved.

[0028] Specifically, Figure 1 A SpringSecurity single sign-on multiplexing method is provided in embodiments of the present application.

[0029] As Figure 1 shown, the SpringSecurity single sign-on multiplexing method comprises the following steps:

[0030] In step S101, multi-system authentication configuration information is obtained.

[0031] It can be understood that the embodiment of the application provides uniform interaction basis and rule support for multiplexing of SpringSecurity single-point authentication by acquiring multi-system authentication configuration information, is a data basis for cross-system authentication collaboration, ensures consistency of authentication parameters between multiple systems, avoids authentication conflicts or failures caused by scattered configuration, facilitates centralized management and dynamic update, only needs to adjust the configuration when the authentication rules of a system are changed, and can be adapted, greatly improves the maintainability and expansibility of the single-point authentication mechanism, at the same time, lays a standardized data basis for efficient reuse of subsequent authentication processes, and reduces the redundant overhead of cross-system interaction.

[0032] In step S102, according to the multi-system authentication configuration information, configuration loading and initialization are performed, a multi-path authentication configuration object is constructed, and a request filter and a multi-path authentication processor based on SpringSecurity are developed and registered.

[0033] The multi-path authentication configuration object encapsulates address, key, permission range and other configuration information required for multi-system authentication, and provides uniform data support for cross-system authentication reuse.

[0034] It can be understood that the embodiment of the application aggregates the scattered multi-system authentication configuration into a unified entity and provides a standardized access interface by using the multi-path authentication configuration object, provides consistent data basis for the request interception rules of the filter and the authentication logic execution of the processor, avoids the redundant overhead of repeated parsing of configuration by each authentication component, and ensures the consistency of multi-system authentication rules through centralized configuration management. When a system adds or adjusts authentication configuration, only the object needs to be updated to synchronously adapt all dependent components, which significantly improves the maintainability and expansion flexibility of the authentication mechanism, and provides an efficient and stable data support basis for multiplexing of single-point authentication.

[0035] For example, as shown in FIG. 6, the multi-path authentication configuration object is encapsulated in the SpringSecurity filter chain, and the request interception rules of the filter and the authentication logic execution of the processor are provided with consistent data basis. Figure 2As shown in the multi-path authentication process of SpringBoot+SpringSecurity, the multi-path authentication configuration object is the core hub of the entire process, and its role runs through the whole chain of configuration definition, loading, scheduling and execution. The object details the key information of various authentication methods through the internal nested single-path authentication configuration structure, such as specifying the type identifier "jwt" for JWT authentication, the Bean name "jwtAuthHandler" of the corresponding processor, and the priority "1" (the smaller the number, the higher the priority), and the OAuth2 authentication is marked with type "oauth2", processor Bean "oauth2AuthHandler" and priority "2", the SMS authentication corresponds to the "sms" type, the "smsAuthHandler" processor and the priority "3", and other ways of configuration such as username and password authentication. These information is stored in a structured configuration file (such as application.yml), and then loaded into the system by a configuration class annotated with @ConfigurationProperties, so that the Spring container can automatically identify and instantiate the corresponding authentication processor. When the authentication request reaches the filter of SpringSecurity, the multi-path authentication processor will use the configuration object to sort all authentication methods by priority first, and then call the corresponding processor to execute the logic: first check if the request carries a JWT token, and then parse the signature and validity period through "jwtAuthHandler"; if the JWT authentication fails, try OAuth2 authentication in order, and check the validity of the token returned by the third-party platform through "oauth2AuthHandler"; if it still fails, trigger the SMS authentication process, and check the binding relationship between the verification code and the mobile phone number through "smsAuthHandler". In the whole process, the configuration object not only provides the calling order and matching basis of the processor, but also supports dynamic adjustment - only by modifying the priority in the configuration file or adding or reducing the authentication type, the authentication process can be adjusted without changing the code, greatly improving the extensibility of the system. Finally, no matter which authentication is successful, the valid authentication credential can be returned; if all fail, an error message is returned to ensure that the entire authentication process is standardized, flexible and configurable.

[0036] In the examples of the present application, according to the multi-system authentication configuration information, configuration loading and initialization are performed, including: building an authentication configuration management platform; based on the authentication configuration management platform, using a configuration parsing algorithm to judge the authentication configuration priority, combining conflict risk detection to obtain an authentication configuration priority evaluation result; according to the authentication configuration priority evaluation result, performing real-time initialization of the authentication configuration through a dynamic loading mechanism, identifying the conflict risk and the loading state, generating an authentication ready signal and corresponding configuration state pushing information.

[0037] Among them, the dynamic loading mechanism is a mechanism that loads the required resources, modules or classes on demand according to actual needs during program runtime rather than compilation stage, which can flexibly adapt to changes in the scenario and optimize resource consumption.

[0038] It is understood that the embodiments of this application, by employing a dynamic loading mechanism, can load authentication configurations on demand at runtime based on actual needs and authentication configuration priority evaluation results. This not only flexibly adapts to changes in multi-system authentication scenarios and optimizes resource consumption, but also identifies conflict risks and loading status during loading, enabling real-time initialization of authentication configurations, generating authentication ready signals and configuration status push information, ensuring that the authentication process is efficient, stable, and dynamically adjustable, and significantly improving the system's scalability and resource utilization under multiple authentication methods.

[0039] In this application example, the parsing algorithm formula is configured as follows:

[0040] ;

[0041] ;

[0042] in, No. The priority score of each authentication configuration; As the system importance weight; As the system importance weight; Weights for path matching accuracy; Score the accuracy of path matching; To configure timeliness weights; To configure timeliness scores; For configuration and The conflict risk value; For the first The set of URL patterns covered by each authentication configuration; For the first The set of URL patterns covered by each authentication configuration; This is the weighting coefficient for HTTP method overlap. HTTP method overlap; This is the weighting factor for the overlap of request header parameters; This refers to the overlap of request header parameters.

[0043] It can be understood that the embodiments of the present application accurately judge the priority of the authentication configuration by using the configuration analysis algorithm, and at the same time, in combination with the conflict risk detection logic, the clear priority relationship is sorted out from the complex multi-system authentication configuration information, and the potential conflict is identified, and the reliable authentication configuration priority evaluation result is generated. Not only does it provide accurate execution basis for subsequent dynamic loading mechanism, but also ensures that the authentication configuration is initialized in a reasonable order, and avoids loading exceptions caused by configuration conflicts by detecting conflict risks in advance, effectively improving the accuracy, orderliness and overall stability of multi-system authentication configuration loading.

[0044] For example, in the multi-system authentication configuration loading scenario, the configuration analysis algorithm first receives the configuration information of each authentication method (including authentication type, priority value, applicable system range, etc.), determines the execution order rule by analyzing the priority value (such as the smaller the value, the higher the priority, and the priority of JWT authentication is identified as 1 higher than that of OAuth2 which is 2), and compares the applicable range and priority value of different configurations to detect whether there is an execution order conflict caused by the same priority (such as the priority of SMS authentication and password authentication is 3) or a rule conflict caused by overlapping application range, and then mark the conflict items and adjust the sorting logic, and finally generate an evaluation result containing clear priority order, conflict risk points and adjustment suggestions, to provide accurate execution basis for subsequent dynamic loading mechanism.

[0045] In the examples of the present application, a multi-path authentication configuration object is constructed, and a request filter and a multi-path authentication processor based on SpringSecurity are developed and registered, including: constructing a multi-path authentication configuration object analysis and dynamic loading mechanism; based on the analysis and dynamic loading mechanism, standardizing the conversion and dependency injection of multi-system authentication rule metadata, combining the SpringSecurity configuration model to generate an extensible multi-path authentication configuration object; according to the multi-path authentication configuration object, component encapsulation is performed on the authentication request filtering logic and the multi-path processor scheduling strategy, and the request filter is registered through the FilterChainProxy extension point of SpringSecurity, and the dynamic binding of the multi-path authentication processor and the default general authentication processor is realized based on the HandlerMapping mechanism.

[0046] Among them, the SpringSecurity configuration model is a framework model that defines security components such as authentication mechanisms, authorization rules, filter chains, etc. through configuration classes or XML, to realize the security management and customized configuration of application access.

[0047] It can be understood that, by using the Spring Security configuration model, relying on the standardized definition capability of security components such as authentication mechanism and filter chain, the application embodiment integrates the dynamically loaded multi-path authentication configuration object and multi-system authentication rule metadata, converts through the configuration class standardization, and generates an extensible configuration conforming to the framework specification through dependency injection. At the same time, with the help of the FilterChainProxy extension point, the custom request filter is conveniently registered, and the dynamic binding of the multi-path authentication processor and the general processor is realized by combining the HandlerMapping mechanism, which not only reuses the security control basic capability of Spring Security, but also makes the authentication filtering logic and processor scheduling strategy have flexible extensibility through component encapsulation, reduces repeated development, ensures seamless integration of the multi-path authentication process and the security framework, and improves system security and development efficiency.

[0048] For example, in the multi-path authentication implementation scenario, a typical example of using the Spring Security configuration model is: through the configuration class marked with @Configuration and @EnableWebSecurity, integrate multi-path authentication configuration objects and dynamic loading mechanisms, first standardize the multi-system authentication rule metadata, then complete the dependency injection through @Autowired, and then rewrite the configure method to configure the filter chain. With the FilterChainProxy extension point, the custom request filter is registered in the filter chain of Spring Security, and the HandlerMapping mechanism is used to dynamically bind the JWT, OAuth2 and other multi-path authentication processors with the default general authentication processor. Finally, through the configuration class, the authentication mechanism, authorization rules and processor scheduling strategy are uniformly controlled, realizing seamless integration and flexible extension of multi-path authentication logic and Spring Security framework.

[0049] In step S103, the request filter listens to the authentication access point, receives the authentication request, constructs a unified authentication token, and according to the system identifier in the unified authentication token, performs matching search in the multi-path authentication processor to obtain a matching result, wherein the matching result includes: if the matching is successful, hand over to the corresponding single-path authentication processor for processing, and if the matching fails, hand over to the default general authentication processor for processing.

[0050] Among them, the unified authentication token is a standardized authentication credential that identifies user identity and permissions, is cross-scene and can verify validity in multi-system or multi-path authentication scenarios.

[0051] It can be understood that, by using the unified authentication token, the embodiments of the present application can not only clearly identify the user identity and authority as a cross-system general standardized credential and guarantee the validity and verifiability, but also provide accurate matching basis for the multi-path authentication processor by the system identifier carried thereby, quickly locate the corresponding single-path authentication processor to process the request, and automatically guide to the default general authentication processor to realize the process bottom-dumping when the matching fails, thereby unifying the identity verification standard of multi-system authentication, avoiding the chaos of credentials in different scenarios, improving the processor matching efficiency through standardized identification, strengthening the identity legality verification relying on the strong verifiability, cooperating with the filter and the processor linkage, reducing the complexity of multi-system authentication integration, and guaranteeing the consistency, stability and security of the authentication process.

[0052] For example, in the multi-path authentication scene of multi-system integration, when the user initiates an authentication request from system A, the request filter listens to the authentication access point, and then constructs a unified authentication token based on the identity information (such as account, JWT fragment) submitted by the user - the token contains a standardized user identity identifier, an authority range, and a system identifier "sys-A". After the multi-path authentication processor receives the token, it quickly matches the single-path authentication processor (such as the JWT authentication processor) corresponding to system A by analyzing the "sys-A" identifier in the token, and completes the token signature verification, validity period check and other logic by the single-path authentication processor. If the user initiates a request from system B which is newly added and has not configured a dedicated processor, the system identifier in the token is "sys-B", and after the matching fails, the default general authentication processor is automatically used to complete the authentication through the account password secondary verification, and the whole process realizes the standardization of cross-system identity identification relying on the unified token, while guaranteeing the accuracy of authentication routing and the compatibility of the process.

[0053] In the embodiments of the present application, according to the system identifier in the unified authentication token, a matching search is performed in the multi-path authentication processor to obtain a matching result, wherein the matching result includes: if the matching succeeds, the corresponding single-path authentication processor is used to process, and if the matching fails, the default general authentication processor is used to process, including: constructing a unified authentication token; embedding the system identifier, user identity information and request context data in the authentication request into the unified authentication token, extracting the valid system identifier field by using a token standardization algorithm; inputting the valid system identifier field into the identifier matching index of the multi-path authentication processor to generate a processor matching result, and using a priority matching strategy, if the matching succeeds, directly using the corresponding single-path authentication processor to process, and if the matching fails, triggering the default general authentication processor, wherein if the valid system identifier field is empty, it is directly classified into the matching failure scenario and processed by the default general authentication processor.

[0054] The token standardization algorithm is an algorithm for converting authentication tokens of different sources and formats into a unified structure and format, ensuring consistency of token identity, permission information and verification rules across systems and in multiple scenarios, and providing interoperability support for unified authentication processes.

[0055] It can be understood that, by using the token standardization algorithm, the embodiments of the present application can convert system identifiers, user identity information and context data of different sources and formats in the authentication request into a unified structure, accurately extract the valid system identifier field, avoid information disorder or extraction failure caused by format differences, provide standardized input for the identification matching index of the multi-path authentication processor, ensure that the matching logic can efficiently and accurately locate the corresponding single-path authentication processor, and also ensure the consistency and interoperability of token information in cross-system authentication scenarios, while standardizing the processing of abnormal scenarios such as empty valid identifier field, reducing matching errors caused by inconsistent formats, and improving the stability and adaptability of the entire authentication routing process.

[0056] In step S104, authentication logic is executed based on the matching result, and authentication credentials are returned, wherein the authentication credentials include: authentication success credentials or authentication error information.

[0057] It can be understood that, by converting the processor matching result into an actual identity verification result and outputting a standardized feedback, the embodiments of the present application execute exclusive logic through the corresponding single-path authentication processor when the matching is successful, generate authentication success credentials containing user identity and permission information, and provide a legal basis for subsequent resource access authorization; when the matching fails or triggers the default processor, authentication error information containing specific reasons is returned after performing the bottom-up verification, which not only ensures that the verification logic is accurately landed in different authentication scenarios and enhances authorization security through exclusive credentials, but also clearly identifies the authentication result through standardized feedback, facilitates user problem troubleshooting and system log tracing, and improves process standardization, traceability and user experience.

[0058] In the embodiments of the present application, authentication logic is executed based on the matching result, and authentication credentials are returned, wherein the authentication credentials include: authentication success credentials or authentication error information, including: constructing an authentication logic execution context and a credential generation template; based on the authentication logic execution context and the credential generation template, combining the identity information in the unified authentication token and the authentication rule configuration of the corresponding system, determining whether the authentication pass condition is met, and generating an authentication verification result; according to the authentication verification result, generating and returning authentication success credentials or standardized authentication error information through a credential encryption module and an error information formatting module.

[0059] The authentication logic execution context and the credential generation template are combination components that carry request data, matching results and other information in the authentication process for logic execution calling, and define a standardized format to uniformly generate authentication success credentials or error information.

[0060] It can be understood that the embodiments of the present application can execute the context and credential generation template by using the authentication logic, which can not only carry the key information such as authentication request data, matching results, identity information in the unified authentication token and system rule configuration in the context to provide complete data support for the authentication logic judgment, avoid logical discontinuity caused by information dispersion, but also define a standardized format by means of the credential generation template, so that the authentication success credentials and authentication error information remain consistent in different single-path authentication processors or default processors, reducing the adaptation cost of cross-system interaction, improving the coherence and data reusability of the authentication logic execution, and at the same time, simplifying the credential generation logic development when adding new authentication methods, and enhancing the maintainability and scalability of the system.

[0061] For example, in a multi-path authentication scenario where JWT and OAuth2 coexist, when a user initiates an authentication request and matches the JWT single-path authentication processor, an authentication logic execution context is first constructed, and the token data in the request header, the processor matching result, the user ID / role information parsed from the unified authentication token, and the JWT authentication rule configuration (such as signature key, validity period threshold) are centralized to carry out the authentication logic call; at the same time, the credential generation template has a preset standardized format - the success credential needs to include an encrypted token, a user identity, a permission list and a validity period, and the error information needs to include an error code, a reason description and a timestamp. The JWT processor extracts data from the context to complete signature verification and validity period verification, and if it passes, it calls the credential encryption module, fills in the data according to the template to generate a successful credential; if the token expires due to verification failure, it passes through the error information formatting module to encapsulate the standardized information of "error code 401 - token has expired" according to the template. Even if a new SMS authentication method is added later, only the verification code data needs to be supplemented in the context, and the template can still be reused to generate credentials with consistent format, which not only ensures the coherence of the logic execution data, but also realizes the uniformity of the credential output.

[0062] A specific embodiment of a SpringSecurity single sign-on multi-path reuse method will be described below, as shown in Figure 3 , which includes:

[0063] Taking the internal system integration project of a large group enterprise as the background, the enterprise has OA office system, ERP business system, CRM customer management system and GitLab system for R&D, and each system originally uses independent authentication mechanism, employees need to log in repeatedly, and the operation and maintenance team needs to maintain the authentication configuration of each system, which has high management cost. In order to solve the above problems, a SpringSecurity single sign-on multi-path reuse method is used to realize unified authentication, and the process is as follows:

[0064] Step S1: Define multi-path authentication configuration information Property structure

[0065] Before formally defining the structure, a comprehensive system research work needs to be carried out, which not only covers OA, ERP, CRM, GitLab and other core business systems, but also extends to the authentication process, data interaction protocol, security check rules and other details of each system. For example, for OA system (identifier sys_oa), it needs to be clear about the database type (such as MySQL, Oracle) it uses, the configuration parameters of the database connection pool, the core fields of the user table (such as user_id, username, password, status, etc.), and the reason for choosing BCrypt as the password encryption method - BCrypt algorithm has the adaptive hashing feature, which can enhance the encryption strength by dynamically adjusting the work factor, effectively resisting brute force attacks. For ERP system (identifier sys_erp), in addition to collecting basic information such as LDAP service address, port number (commonly used 389 or 636 encrypted port), it also needs to confirm the specific format of the root directory DN (such as "dc=company,dc=com"), the permission range of the administrator account (which needs to have user query permission) and the writing rules of the user query filter (such as "(&(objectClass=inetOrgPerson)(uid={0}))"), to ensure accurate positioning of the target user. The OAuth2.0 protocol of CRM system (identifier sys_crm) needs to specify the specific endpoint of the authorization server (such as authorization endpoint, token endpoint, user information endpoint), the generation rules and storage method of client ID and secret key (recommended to be encrypted and stored in the configuration center), the authorization scope needs to be accurately defined according to business needs (such as "read:userwrite:task"), the redirection address must be consistent with the whitelist configured by the authorization server to avoid cross-domain security risks. The JWT token authentication of GitLab system (identifier sys_gitlab) needs to determine the storage path of the public key (such as "public.key" in the class path), the reasonable setting of the token expiration time (usually 2 hours, considering security and user experience) and the selection of the signature algorithm (preferably use asymmetric algorithm RS256 to avoid the risk of symmetric algorithm key leakage). In addition to the above-mentioned system-specific parameters, the final defined Property structure also needs to design system identifier (to ensure global uniqueness), authentication type ("DB" "LDAP" "OAUTH2" "JWT"), whether to enable default authentication flag (Boolean value, used to control the trigger logic of default authentication) and other public fields, to realize the organic combination of differentiated configuration and standardized management.

[0066] Step S2: Define a unified authentication request information Token structure

[0067] In the complex IT architecture of an enterprise, the authentication requests of different systems often have different parameter names and data formats, for example, the OA system may pass "userName" and "passWord", while the ERP system may use "usr" and "pwd". This difference will lead to frequent format conversion when the authentication logic is processed, increasing the complexity of the system. Therefore, the MultiplexAuthToken structure needs to be standardized and designed to cover the core fields required in the authentication process. Among them, the system identifier is consistent with the Property structure in step S1, serving as the core identifier for matching the corresponding authentication processor later; the username and password are basic authentication credentials, which need to be explicitly defined as string type, and it is agreed that the password transmission process needs to be encrypted through HTTPS to prevent data leakage in the transmission link; the design of the request IP address field is for security audit needs, which can be used to record the source terminal of the authentication request, and when abnormal login behavior occurs (such as multiple login requests from different IPs in a short period of time), the risk source can be quickly located; the request timestamp field uses millisecond-level time format, which can be used to control the validity period of the request (such as setting it valid within 10 minutes to avoid expired requests being processed repeatedly), and also serves as an auxiliary identifier for request uniqueness to prevent replay attacks. In addition, the structure also needs to consider extensibility, reserving an extension field (such as "extParams") to carry personalized request parameters of each system (such as the authorization code parameter "code" of the CRM system). At the implementation level, the structure needs to be provided with perfect getter and setter methods, and implement the Serializable interface to ensure its serialization transmission in a distributed environment, and cooperate with tools such as Jackson to realize flexible conversion with JSON format, ensuring data compatibility when interacting between front and back ends and calling between systems.

[0068] Step S3: Define a unified single-way authentication Handler standard interface

[0069] The behavior of each authentication processor is specified by the interface contract, and the "interface-oriented programming" architecture pattern is constructed. In the multi-path authentication scenario, the authentication logic of each system is significantly different. For example, database authentication needs to operate the data source, LDAP authentication needs to call the JNDI interface, and OAuth2.0 authentication needs to initiate an HTTP request. If these logics are directly coupled in one place, it will lead to a sharp increase in code maintenance difficulty, and the core code needs to be significantly changed when adding or modifying the authentication type. Therefore, the AuthenticationProvider interface needs to clearly define the method contract that each single-path authentication processor must implement. The core methods include authenticate(MultiplexAuthTokentoken) and supports(Class<?>authentication). Among them, the authenticate method is the core execution entry of the authentication logic, which receives the standardized MultiplexAuthToken object as the parameter and returns the authentication result (including the user details of successful authentication or the error information of authentication failure). This method needs to handle various exceptions in the authentication process (such as database connection failure, LDAP service unavailable, etc.) and encapsulate them into a unified exception type. The supports method is used to determine whether the current processor supports the incoming authentication type, and its parameter is the Class type of the authentication object, and the return value is a Boolean value. This method is the key basis for the processor matching implemented by the multi-path authentication manager. In addition to the core methods, the interface can also define the init() method for processor initialization operations (such as loading configuration parameters and creating connection pools), and the destroy() method for resource release (such as closing the database connection and destroying the context). The "high cohesion and low coupling" principle needs to be followed in the interface design process. The specific authentication implementation logic is not included, and only the method name, parameter type, and return value format are specified to ensure that the authentication processors of each system can be independently developed, tested, and deployed. This design pattern not only improves the maintainability of the code, but also provides convenience for subsequent system expansion. When new types such as DingTalk authentication and WeChat authentication are added, only the corresponding interface implementation class needs to be developed, without modifying the core scheduling logic of the multi-path authentication manager.

[0070] Step S4: Develop implementation classes based on the single-path authentication Handler standard interface

[0071] For the DbAuthProvider of the OA system, its core logic revolves around database queries and password verification: first, initialize the data source connection pool (using Druid or other mature connection pool frameworks, configure parameters such as maximum number of connections and timeout) through the database connection parameters encapsulated in step S1, receive the username in the MultiplexAuthToken, construct a precompiled SQL statement (such as "SELECT*FROMsys_userWHEREusername=?" ) to query user information, and avoid SQL injection risks; after querying the user record, you need to check the user status (such as whether it is enabled or locked) first, and directly return an authentication failure if the status is abnormal; then call the matches method of the BCrypt algorithm to compare the user's input password with the encrypted password stored in the database, and if the comparison is successful, construct the user information of the authentication success, and if the comparison fails, return a password error prompt. The LdapAuthProvider of the ERP system needs to be based on JNDI technology to realize LDAP service interaction: in the initialization stage, build an LDAP connection environment (such as Context.INITIAL_CONTEXT_FACTORY, Context.PROVIDER_URL, etc.) through configuration parameters, first use the administrator account password to perform a binding operation, and verify the accessibility of the LDAP service; in the authentication stage, construct the user DN (such as "uid=admin,ou=users,dc=company,dc=com") according to the username and query filter, then use the user's input password to try to bind the DN, and if the binding is successful, the authentication is passed, and if the binding fails, return an LDAP authentication exception (such as the user does not exist, the password is incorrect). The OAuth2AuthProvider of the CRM system needs to complete the OAuth2.0 authorization code mode process: after receiving the authorization code passed from the front end, send a POST request to the token endpoint of the authorization server, carrying parameters such as client ID, client secret, authorization code, and redirect address; after obtaining the access token, call the user information endpoint to query user details, verify the validity and authorization scope of the token, and if it meets the requirements, complete the authentication. The core of the JwtAuthProvider of the GitLab system is the parsing and verification of JWT tokens: load the public key through the configured public key path, use the specified signature algorithm (such as RS256) to parse the token's header, payload, and signature; first verify the token's expiration time (compare the current time with the exp field), then verify the signature's legality to ensure that the token has not been tampered with; finally, extract the user information in the payload (such as the sub field as the username), and complete the authentication logic.In addition, to deal with authentication scenarios that do not match specific systems, a DefaultAuthProvider needs to be developed as a default general authentication processor. Its logic can be designed to return an error message such as "No specific authentication method configured, please contact administrator" or use a basic username and password check (which needs to be strictly controlled in use scenarios), while detailed logs are recorded for problem troubleshooting.

[0072] Step S5: Develop a configuration information loader to create and initialize a multi-path authentication configuration object P1

[0073] In a distributed system architecture, the authentication configurations of each system may change frequently due to business adjustments, security requirements, etc. For example, LDAP service addresses are migrated, JWT token expiration times are adjusted, etc. If these configurations are hard-coded in the code, each change needs to be repackaged and deployed to the service, which seriously affects system availability. Therefore, this step uses Nacos as a configuration center to realize real-time pushing of configurations using its dynamic configuration service and configuration listening mechanism. The development of the configuration information loader needs to include three core modules: configuration subscription, parsing, and caching. The configuration subscription module subscribes to the specified configuration dataset (such as "multiplex-auth-config.json") through the Nacos client API and sets up a configuration change listener. When the configuration in the configuration center changes, the listener triggers a callback function. The configuration parsing module uses the Jackson tool to parse the JSON format configuration data into a Java object. During parsing, it needs to handle field type conversion, mandatory item verification, etc. For example, it verifies whether the system identifier is unique and whether the authentication type is a supported type (such as "DB" "LDAP", etc.). If the parsing fails, an alarm mechanism is triggered and the old configuration is used from the cache. The cache module stores the parsed configuration object in the local cache (such as GuavaCache) and sets a reasonable cache expiration period to avoid fetching data from the configuration center for each authentication request, improving system response speed. The built multi-path authentication configuration object MultiplexAuthConfig is the core carrier of the configuration information. The Map collection maintained inside it uses the system identifier as the key and the corresponding system Property structure instance as the value. This key-value pair structure enables fast matching of authentication processors. At the same time, this object also needs to store the default authentication configuration information separately, including the default authentication type, default processor parameters, etc., to provide configuration support for DefaultAuthProvider. To ensure the security of the configuration, sensitive information (such as database passwords, LDAP administrator keys) stored in the configuration center needs to be encrypted (such as using the encryption function of Nacos). The configuration information loader needs to decrypt before parsing to prevent sensitive information leakage.

[0074] Step S6: Develop a request filter based on SpringSecurity and listen to the authentication default access point and the authentication access point configured by each integrated system according to the configuration object P1

[0075] Converge the dispersed authentication access to a unified portal to realize centralized management and control of the authentication process. SpringSecurity, as a mature security framework, provides a complete filter chain mechanism. MultiplexAuthFilter inherits OncePerRequestFilter to ensure that each request is filtered only once, avoiding performance loss caused by repeated processing. The core functions of the filter include authentication access point listening, request parameter verification, and system information matching. In the authentication access point configuration, the default unified access point is set to " / sso / auth". This access point serves as the authentication portal for all systems, facilitating log monitoring, traffic statistics, and security protection (such as configuring WAF rules only for this path). At the same time, it supports customizing the access point path through Nacos configuration to meet the path specification requirements of different enterprises (such as some enterprises are used to using " / api / auth"). In terms of system information configuration, the filter needs to load the list of systems to be integrated, which includes system name, system identifier, and whether to enable authentication. Assign a unique identifier (such as sys_oa, sys_erp) to each system, which needs to be consistent with the Property structure in step S1, serving as the core basis for subsequent authentication processor matching. When the filter listens to the request of the authentication access point, it first performs preprocessing of the request parameters, including parsing the request method (supporting POST form submission and JSON format submission), extracting request parameters (system identifier, username, password, etc.), and verifying the integrity of the parameters. If key parameters (such as system identifier, username) are missing, return a 400 BadRequest error with the missing parameter name. At the same time, the filter also needs to perform basic security checks, such as filtering request parameters containing malicious scripts, and verifying whether the request IP is in the whitelist (optional configuration) to prevent malicious request attacks. In addition, the filter needs to configure exclusion paths for static resources (such as CSS, JS), public interfaces (such as login page), and other requests that do not need to be intercepted to improve system performance. After configuration, integrate MultiplexAuthFilter into the filter chain of SpringSecurity, specify the execution order of the filter through the configuration class annotated with @Configuration, and ensure that it is executed before the username and password authentication filter to achieve unified authentication portal management and control.

[0076] Step S7: Develop a multi-path authentication processor based on SpringSecurity and initialize and load each authentication Handler object according to the configuration object P1

[0077] According to the system identifier in the authentication request, the corresponding single-path authentication processor is accurately matched, and the dynamic distribution of authentication logic is realized. As an extended component of the Spring Security authentication system, MultiplexAuthManager needs to implement the AuthenticationManager interface and override the authenticate method as the dispatch entry. The core data structure of this processor is a Map collection (using ConcurrentHashMap to ensure thread safety), which is used to store the mapping relationship between system identifiers and single-path authentication processors (AuthenticationProvider implementation classes). This mapping relationship needs to be built in combination with the MultiplexAuthConfig configuration object in step S5. In the initialization phase, MultiplexAuthManager obtains all AuthenticationProvider implementation class instances through Spring's dependency injection, and loads the configuration information in MultiplexAuthConfig. It iterates through the configuration data of each system, binds the system with the corresponding processor according to the system identifier and authentication type, for example, binds sys_oa with DbAuthProvider and binds sys_erp with LdapAuthProvider. If there are multiple processors supporting the same authentication type (such as different database types of DbAuthProvider), accurate matching is performed through the processor identifier in the configuration. In addition to the mapping of system-specific processors, MultiplexAuthManager also needs to hold an instance of DefaultAuthProvider as a fallback solution when no specific processor is matched, ensuring that any authentication request can be processed and avoiding system exceptions. To support dynamic expansion, MultiplexAuthManager also needs to provide processor registration and deregistration methods. When a new system is added or an old system is offline, new mapping relationships can be added by calling the registration method, or old mapping relationships can be removed by calling the deregistration method, without the need to restart the service. In the dispatch logic, MultiplexAuthManager receives the authentication request, extracts the system identifier from the request token, and quickly obtains the corresponding processor through the get method of the Map. If it is obtained, it calls the authenticate method of the processor to execute the authentication logic, and if it is not obtained, it is handed over to DefaultAuthProvider for processing. The entire dispatch process is efficient and flexible, fully embodying the "open-closed principle" - when adding a new authentication type, only the processor implementation class and the configuration need to be added, without the need to modify the dispatch logic.

[0078] Step S8: After receiving the authentication request being monitored, the request filter initializes the request data into an authentication request information Token object and hands it over to the multiplexer.

[0079] The original HTTP request parameters are converted into standardized authentication tokens, and the tokens are stored in context using SecurityContextHolder. When a user initiates an authentication request through a system's login page (e.g., a user in an OA system enters their username and password and clicks login), the request is intercepted by MultiplexAuthFilter. At this point, the filter needs to perform a series of preprocessing operations. First, the request method and format are parsed. The filter needs to support both POST form submissions (application / x-www-form-urlencoded) and JSON format submissions (application / json). Different parameter extraction methods are used for different formats: form submissions are extracted using the request.getParameter() method, while JSON format is read from the request body via IO stream and parsed into a Map object using Jackson. After parameter extraction, the filter performs strict integrity checks, including whether the system identifier is empty, whether it is in the configured system list, whether the username and password are not empty, and whether the request IP address is valid. If the check fails, the filter constructs a uniform error response (e.g., JSON error code and error description) and returns it to the front end through a response object, while also recording an error log (including request parameters, request IP, time, etc.) for troubleshooting. After parameter validation passes, the filter initializes a MultiplexAuthToken object, assigning the extracted system identifier, username, password, and other parameters to the corresponding fields of the token. The request IP address is obtained using the request.getRemoteAddr() method (if the system is deployed behind a reverse proxy, the real IP address needs to be obtained through the X-Forwarded-For request header), and the request timestamp is obtained using System.currentTimeMillis() to get the current time in milliseconds. After token initialization, the filter needs to temporarily store the token in the security context using SecurityContextHolder. SecurityContextHolder uses the ThreadLocal mechanism by default to store the security context, ensuring that each request thread can independently obtain the corresponding token information, avoiding token confusion in a multi-threaded environment. In addition, the filter also needs to clean up old authentication information before storing the context to prevent residual old tokens from affecting the current authentication process, ensuring the accuracy and security of authentication data.

[0080] Step S9: The multipath authentication processor matches the single-path authentication Handler object finally responsible for authentication processing in a polling manner

[0081] Based on the system identifier in the authentication token, the corresponding processor is matched from the preset mapping relationship, ensuring that the authentication requests of different systems can be correctly logically processed. After the MultiplexAuthManager receives the MultiplexAuthToken object obtained from the SecurityContextHolder, it first performs token validity check, including checking whether the token is empty and whether the request timestamp is within the valid period (such as judging whether the difference between the current time and the timestamp exceeds 10 minutes), and directly returning authentication failure if the token is invalid. After the token check passes, the processor extracts the system identifier (such as sys_oa) from the token, which is the core basis for matching and needs to be completely consistent with the key of the Map collection in step S7. The matching process has two core branches: S9-1 is the accurate matching branch of the system identifier, MultiplexAuthManager calls the containsKey() method of Map to judge whether the identifier exists in the mapping relationship, and if it exists, directly obtains the corresponding single-path authentication Handler (such as DbAuthProvider corresponding to sys_oa) through the get() method. After obtaining, the supports() method of Handler needs to be called for secondary check to ensure that the processor indeed supports the current token type (to prevent the problem of unmatched processor caused by configuration error), and after the secondary check passes, it is determined to use the processor to execute the authentication logic; S9-2 is the bottom branch for unmatched, if the system identifier does not exist in the mapping relationship (such as the newly online test system sys_test of the enterprise which is not configured with a dedicated processor), MultiplexAuthManager automatically processes the authentication request by DefaultAuthProvider, and the core function of the bottom processor is to avoid the interruption of the authentication process caused by the unconfigured system, and its processing logic is usually to return an error message "the system has not configured a dedicated authentication method, please contact the administrator to configure", and record the alarm log to remind the operation and maintenance personnel to configure the corresponding processor in time. To improve the matching efficiency, the mapping relationship is implemented by HashMap, and the time complexity of its get() method is O(1), which ensures that the matching can be quickly completed even when the number of systems is large; at the same time, detailed scheduling logs will be recorded during the matching process, including system identifier, matched processor name, whether to use default processor and other information, which facilitates subsequent problem troubleshooting and system optimization.

[0082] Step S10: The multipath authentication processor matches the single-path authentication Handler object finally responsible for authentication processing in a polling manner

[0083] The authentication verification is performed by a dedicated processor, and the authentication result is returned to the front end in a standardized format, providing support for subsequent authorization processes. This step is divided into two branches based on the authentication result: success and failure. Each branch must follow a unified response specification to ensure that the front end can efficiently parse the result. S10-1 is the authentication success branch: After the single-path authentication Handler executes the authentication logic successfully (e.g., DbAuthProvider successfully queries the database and verifies the password, LdapAuthProvider completes user binding), the user details object UserDetails needs to be constructed first. This object is the core data carrier of the Spring Security authorization system and must contain information such as username, password (can be stored as null, since authentication has passed), activation status, and permission list. The permission list needs to be encapsulated according to the system's role permission system (e.g., ROLE_OA_ADMIN for administrators and ROLE_OA_USER for ordinary users in an OA system) to provide a basis for subsequent interface permission control. Subsequently, a unified format authentication credential is generated based on the UserDetails object. JWT tokens are typically used as authentication credentials. The token construction must include three core parts: a header specifying the signature algorithm (e.g., RS256), a payload containing key data such as user ID, username, system identifier, permission information, and expiration time (e.g., set to expire in 2 hours), and a signature that uses the server's private key to encrypt the header and payload, ensuring the token is not tampered with. After the token is generated, the return method can be selected according to business needs: if the frontend needs to carry the token for authentication in subsequent requests, the token can be placed in the Authorization field of the response header (formatted as "Bearer token value"); if the frontend needs to obtain detailed user information simultaneously, the token and user information can be encapsulated in JSON format and returned (e.g., {"code":200,"msg":"Authentication successful","data":{"token":"xxx","user":{"id":1,"username":"admin","roles":["ROLE_ADMIN"]}}}). At the same time, the user information of successfully authenticated users needs to be stored in the security context of SecurityContextHolder for authorization verification of subsequent requests.S10-2 is the authentication failure branch: If the authentication logic fails (e.g., incorrect username / password, LDAP service connection timeout, invalid JWT token signature), the Handler will throw the corresponding authentication exception (e.g., BadCredentialsException, AuthenticationServiceException). After MultiplexAuthManager catches the exception, it maps it to a unified error code and error description based on the exception type. The error code must follow the company's unified specifications (e.g., 1001 represents incorrect username / password, 1002 represents authentication service unavailable, 1003 represents invalid token). The error description must be clear and easy to understand, avoiding the use of technical jargon (e.g., converting "BCrypt password comparison failed" to "username or password incorrect"). Finally, the error code and error description are encapsulated into a JSON format response (e.g., {"code":1001,"msg":"username or password incorrect","data":null}) and returned to the frontend. At the same time, a detailed error log is recorded, including request parameters, token information, exception stack trace, etc., to help backend developers locate the cause of the failure. Regardless of whether authentication is successful or not, the response must include a cross-origin response header (such as Access-Control-Allow-Origin) to ensure that the front-end cross-origin request can receive the response result normally.

[0084] In summary, this invention achieves unified authentication and single sign-on across multiple systems through Spring Security, significantly optimizing the operational efficiency of enterprise IT architecture. It completely resolves the pain point of employees repeatedly logging into OA, ERP, CRM, and GitLab systems, improving office convenience. Furthermore, it significantly reduces the configuration, maintenance, and version iteration costs for operations teams by centrally managing authentication parameters across systems through a configuration center and encapsulating differentiated authentication logic through interfaces. Simultaneously, it strengthens the security and stability of the authentication process by relying on standardized token structures, secure encryption algorithms (BCrypt, RS256), robust exception handling, and dynamic permission control. Its modular and scalable design architecture can also quickly adapt to new systems or authentication types without modifying the core logic, providing efficient support for system integration and security upgrades during enterprise digital transformation.

[0085] Figure 4 This is a block diagram of a SpringSecurity single sign authentication multiplexing system according to an embodiment of this application.

[0086] like Figure 4 As shown, the Spring Security single sign-on multiplexing system 10 includes: an acquisition module 100, a configuration initialization module 200, a route distribution module 300, and an authentication execution module 400.

[0087] The acquisition module 100 is configured to acquire multi-system authentication configuration information; the configuration initialization module 200 is configured to perform configuration loading and initialization according to the multi-system authentication configuration information, construct a multi-path authentication configuration object, and develop and register a request filter and a multi-path authentication processor based on SpringSecurity; the routing distribution module 300 is configured to listen to an authentication access point through the request filter, receive an authentication request, construct a unified authentication token, perform matching and searching in the multi-path authentication processor according to a system identifier in the unified authentication token, and obtain a matching result, wherein the matching result includes: handing over to a corresponding single-path authentication processor for processing if the matching is successful, and handing over to a default general authentication processor for processing if the matching fails; and the authentication execution module 400 is configured to perform authentication logic based on the matching result and return authentication credentials, wherein the authentication credentials include: authentication success credentials or authentication error information.

[0088] It should be noted that the foregoing explanation and description of the embodiment of the method for multiplexing single-point authentication of SpringSecurity also applies to the embodiment of the system for multiplexing single-point authentication of SpringSecurity, which will not be described here again.

[0089] The system for multiplexing single-point authentication of SpringSecurity provided by the embodiment of the present application collects, processes and encapsulates multi-system authentication configuration in a centralized manner, integrates authentication rules and key parameters scattered in each system into a multi-path authentication configuration object, supports dynamic configuration updating without system restart, greatly reduces configuration redundancy and operation and maintenance costs, and adapts to the business expansion demand in enterprise digital transformation; realizes accurate routing matching relying on a system identifier in a unified authentication token, replaces traditional traversal matching and hard-coded judgment mode, and improves routing response speed by more than 50%, effectively avoids authentication delay in a large-scale multi-system scenario, and guarantees high-concurrency access stability; adopts hierarchical decoupling design to enable single-path authentication logic to be independently developed and hot-plugged, and only needs to develop a corresponding processor and register for a new system, cooperates with the default general authentication processor to realize seamless compatibility of un-preconfigured systems, shortens the online period of new business from weeks to days, and comprehensively improves the adaptation flexibility, maintainability and response efficiency of the single-point authentication system, significantly reduces the development and operation and maintenance costs of multi-system integration, and provides stable support for high-reliability single-point authentication in complex scenarios. Thus, the problems of weak adaptability and poor expansibility in the prior art are solved.

[0090] Figure 5 A structural schematic diagram of an electronic device is provided for the embodiment of the present application. The electronic device can include:

[0091] The memory 501, the processor 502, and the computer program stored in the memory 501 and executable on the processor 502.

[0092] The processor 502 implements the single point authentication multiplexing method of Spring Security provided in the above embodiments when executing the program.

[0093] Further, the electronic device further comprises:

[0094] The communication interface 503 is configured to communicate between the memory 501 and the processor 502.

[0095] The memory 501 is configured to store a computer program executable on the processor 502.

[0096] The memory 501 can include a high-speed RAM (Random Access Memory) memory, and can further include a non-volatile memory, for example, at least one disk memory.

[0097] If the memory 501, the processor 502 and the communication interface 503 are independently implemented, the communication interface 503, the memory 501 and the processor 502 can be connected to each other through a bus and complete communication between each other. The bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component) bus or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For the convenience of representation, Figure 5 In the figure, only one thick line is used to represent, but it does not mean that there is only one bus or one type of bus.

[0098] Optionally, in a specific implementation, if the memory 501, the processor 502 and the communication interface 503 are integrated on a chip, the memory 501, the processor 502 and the communication interface 503 can complete communication between each other through an internal interface.

[0099] The processor 502 can be a CPU (Central Processing Unit), or an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiments of the present application.

[0100] The embodiments of the present application further provide a computer readable storage medium, which stores a computer program, and the program is executed by the processor to implement the single point authentication multiplexing method of Spring Security as above.

[0101] Furthermore, the embodiments of the present application also provide a computer program product comprising computer programs or instructions, which, when executed, implement the above-mentioned single sign-on multiplexing method of Spring Security.

[0102] In the description of the present specification, the description of the terms "one embodiment", "some embodiments", "an example", "a specific example", or "some examples" and the like means that the specific features, structures, materials or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present application. In the present specification, the illustrative expressions of the above terms are not necessarily directed to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any appropriate manner in any one or more embodiments or examples. Furthermore, the person skilled in the art can combine and combine the different embodiments or examples described in the present specification and the features of the different embodiments or examples, without contradiction.

[0103] In addition, the terms "first", "second" are only for descriptive purposes and cannot be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined with "first", "second" can explicitly or implicitly include at least one of the features. In the description of the present application, the meaning of "a plurality of" is at least two, for example, two, three, etc., unless otherwise explicitly specified.

[0104] Any process or method descriptions in flow charts or described elsewhere herein can be understood as representing code modules, segments, or portions of code which include one or more executable instructions for implementing specific logic functions (or steps) in the process, and the preferred embodiments of the application include additional implementations in which the functions described with or without reference to flow charts are implemented by computer software using, for example, object code formatting or otherwise, and in which the various components, modules, engines, and sections can generally be implemented by computer software, by hardware, by other implementation tools, or by combinations of them. The computer software can be stored in any type of non-transitory computer-readable media or memory devices or storage devices (e.g., look-up tables, etc.) and can include one or more software layers or components, such as libraries, drivers, bootstrappers, operating system layers, cross-platform layers, virtual machines, etc.

[0105] It should be understood that parts of the present application can be implemented in hardware, software, firmware, or a combination thereof. In the above-described embodiments, a plurality of steps or methods can be implemented by software or firmware stored in a memory and executed by appropriate instructions. As in another embodiment, if implemented by hardware, any one or a combination of the following technologies known in the art can be used: discrete logic circuit with logic gate circuit for implementing logic functions on data signals, application specific integrated circuit with appropriate combination logic gate circuit, programmable gate array (PGA), field programmable gate array (FPGA), etc.

[0106] Those skilled in the art can understand that all or part of the steps of the method carried out by the above-mentioned embodiments can be completed by programs instructing relevant hardware, and the programs can be stored in a computer readable storage medium. When the program is executed, it includes one of the steps of the method embodiment or a combination thereof.

[0107] Although the embodiments of the present application have been shown and described above, it should be understood that the above-mentioned embodiments are exemplary and cannot be understood as limiting the present application. Those skilled in the art can make changes, modifications, replacements and variations to the above-mentioned embodiments within the scope of the present application.

Claims

1. A single sign-on multiplexing method in Spring Security, characterized in that, include: Obtain multi-system authentication configuration information; Based on the multi-system authentication configuration information, configuration loading and initialization are performed to build an authentication configuration management platform; Based on the aforementioned authentication configuration management platform, a configuration parsing algorithm is used to determine the priority of authentication configurations. Combined with conflict risk detection, an authentication configuration priority evaluation result is obtained. The configuration parsing algorithm formula is as follows: ； ； in, No. The priority score of each authentication configuration; As the system importance weight; Assess the system's importance. Weights for path matching accuracy; Score the accuracy of path matching; To configure timeliness weights; To configure timeliness scores; For configuration and The conflict risk value; For the first The set of URL patterns covered by each authentication configuration; For the first The set of URL patterns covered by each authentication configuration; This is the weighting coefficient for HTTP method overlap. HTTP method overlap; This is the weighting factor for the overlap of request header parameters; Based on the authentication configuration priority evaluation result, the authentication configuration is initialized in real time through a dynamic loading mechanism to determine the overlap of request header parameters. Conflict risks and loading status are identified, an authentication ready signal and corresponding configuration status push information are generated, a multi-path authentication configuration object is constructed, and a request filter and multi-path authentication processor based on Spring Security are developed and registered. The system listens for authentication access points through the request filter, receives authentication requests, constructs a unified authentication token, and performs a matching search in the multi-path authentication processor based on the system identifier in the unified authentication token. If a match is successful, the request is handled by the corresponding single-path authentication processor; otherwise, it is handled by the default general authentication processor. This process includes: constructing a unified authentication token; embedding the system identifier, user identity information, and request context data from the authentication request into the unified authentication token; extracting the valid system identifier field using a token standardization algorithm; inputting the valid system identifier field into the identifier matching index of the multi-path authentication processor to generate a processor matching result; and using a priority matching strategy, if a match is successful, the request is directly handled by the corresponding single-path authentication processor; if a match fails, the default general authentication processor is triggered. If the valid system identifier field is empty, it is directly classified as a matching failure scenario and handled by the default general authentication processor. Based on the matching result, the authentication logic is executed and the authentication credentials are returned, wherein the authentication credentials include: authentication success credentials or authentication error information.

2. The Spring Security single-signal authentication multiplexing method according to claim 1, characterized in that, Construct a multi-authentication configuration object, develop and register Spring Security-based request filters and multi-authentication handlers, including: Construct a mechanism for parsing and dynamically loading multi-channel authentication configuration objects; Based on the aforementioned parsing and dynamic loading mechanism, the metadata of authentication rules from multiple systems is standardized and injected into dependencies. Combined with the Spring Security configuration model, an extensible multi-way authentication configuration object is generated. Based on the multi-path authentication configuration object, the authentication request filtering logic and multi-path processor scheduling strategy are encapsulated in a component-based manner. The request filter registration is completed through the Spring Security FilterChainProxy extension point, and the dynamic binding between the multi-path authentication processor and the default general authentication processor is realized based on the HandlerMapping mechanism.

3. The Spring Security single-signal authentication multiplexing method according to claim 1, characterized in that, Based on the matching result, authentication logic is executed, and authentication credentials are returned. These credentials include either authentication success credentials or authentication error information, including: Construct the authentication logic execution context and credential generation template; Based on the authentication logic execution context and credential generation template, combined with the identity information in the unified authentication token and the authentication rule configuration of the corresponding system, it is determined whether the authentication pass conditions are met and an authentication verification result is generated. Based on the authentication verification result, the credential encryption module and the error message formatting module generate and return authentication success credentials or standardized authentication error messages.

4. A Spring Security single-signal authentication multiplexing system, characterized in that, include: The acquisition module is used to obtain multi-system authentication configuration information; The configuration initialization module is used to load and initialize the configuration based on the multi-system authentication configuration information, and to build an authentication configuration management platform. Based on the aforementioned authentication configuration management platform, a configuration parsing algorithm is used to determine the priority of authentication configurations. Combined with conflict risk detection, an authentication configuration priority evaluation result is obtained. The configuration parsing algorithm formula is as follows: ； ； in, No. The priority score of each authentication configuration; As the system importance weight; Assess the system's importance. Weights for path matching accuracy; Score the accuracy of path matching; To configure timeliness weights; To configure timeliness scores; For configuration and The conflict risk value; For the first The set of URL patterns covered by each authentication configuration; For the first The set of URL patterns covered by each authentication configuration; This is the weighting coefficient for HTTP method overlap. HTTP method overlap; This is the weighting factor for the overlap of request header parameters; Based on the authentication configuration priority evaluation result, the authentication configuration is initialized in real time through a dynamic loading mechanism to determine the overlap of request header parameters. Conflict risks and loading status are identified, an authentication ready signal and corresponding configuration status push information are generated, a multi-path authentication configuration object is constructed, and a request filter and multi-path authentication processor based on Spring Security are developed and registered. The routing and distribution module is used to listen to the authentication access point through the request filter, receive authentication requests, construct a unified authentication token, and perform a matching search in the multi-path authentication processor based on the system identifier in the unified authentication token to obtain the matching result. If the matching is successful, it is handed over to the corresponding single-path authentication processor for processing; if the matching fails, it is handed over to the default general authentication processor for processing. The process includes: constructing a unified authentication token; embedding the system identifier, user identity information, and request context data from the authentication request into the unified authentication token; using a token standardization algorithm to extract the valid system identifier field; inputting the valid system identifier field into the identifier matching index of the multi-path authentication processor to generate a processor matching result; using a priority matching strategy, if the matching is successful, it is directly handed over to the corresponding single-path authentication processor for processing; if the matching fails, the default general authentication processor is triggered. If the valid system identifier field is empty, it is directly classified as a matching failure scenario and handed over to the default general authentication processor for processing. The authentication execution module is used to execute authentication logic based on the matching result and return authentication credentials, wherein the authentication credentials include: authentication success credentials or authentication error information.

5. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement a Spring Security single-point authentication multiplexing method as described in any one of claims 1-3.

6. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When a computer program or instruction is executed, it implements a Spring Security single-signal authentication multiplexing method as described in any one of claims 1-3.

7. A computer program product, comprising a computer program or instructions, characterized in that, When a computer program or instruction is executed, it implements a Spring Security single-signal authentication multiplexing method as described in any one of claims 1-3.

Images