Isomeric subsystem modification-free single sign-on method and system

Abstract

The application provides a heterogeneous subsystem transformation-free single sign-on method and system, which comprises the following steps: S1, generating a session pointer after unified portal authentication, and issuing a token containing only the pointer; S2, writing the pointer and user object mapping into shared storage shared by all parties, and configuring automatic renewal; S3, writing the token into a domain shared Cookie by the portal front end, and relaying the token through a multi-authentication header when loading the subsystem; S4, intercepting the request by the subsystem, preferentially analyzing the pointer when the switch is on, and transparently returning to local authentication when an exception occurs; S5, addressing by a consistent key serializer, cross-serializing and analyzing the original bytes into a generic key-value mapping to extract the username; S6, matching the local user according to the username, automatically creating a disabled account if the username is not hit, and releasing after injecting the context; S7, renewing the session by the portal; and S8, globally redirecting to the login page by the top-level framework when the session is invalid, and adaptively rendering by the front end according to the nesting state.

Description

Technical Field

[0001] This invention relates to the field of distributed system security technology, specifically to a method and system for single sign-on without modification for heterogeneous subsystems. Background Technology

[0002] As enterprise IT infrastructure continues to evolve, a large number of business subsystems developed using different technology stacks and delivered by different software vendors often coexist within an enterprise. To improve user experience and strengthen centralized management, a single sign-on (SSO) mechanism is typically introduced to integrate these heterogeneous subsystems.

[0003] Most mainstream single sign-on solutions are based on mature protocols such as CAS, OAuth2, OIDC, and SAML. However, these standard protocols require each business subsystem to rebuild its original authentication layer and introduce corresponding protocol client dependencies. For a large number of legacy subsystems within an enterprise with "unmodifiable source code," missing documentation, or extremely high modification costs, it is difficult to meet the "no-modification" access requirements in real-world engineering scenarios.

[0004] Furthermore, existing solutions still have shortcomings in terms of security and state management: some solutions directly encapsulate plaintext fields such as user unique identifiers, role and permission lists into the token, which not only increases the risk of leakage and tampering during transmission, but also makes it difficult for the server to perform immediate permission revocation, active cancellation, and dynamic on-demand renewal on the token because the token itself contains a state. In the scenario of session expiration, subsystems displayed in an embedded form often directly redirect to their own login page in their local view, resulting in a fragmented and isolated local login state, lacking a unified lifecycle federated management and re-authentication mechanism across the entire portal.

[0005] To address the challenges of accessing heterogeneous systems, Chinese Patent Publication No. CN120979727A discloses a single sign-on (SSO) method for heterogeneous systems. This method generates a globally unique SSO identifier, performs unified identity authentication based on the user's mobile phone number, and employs a distributed authentication and dual-token mechanism to achieve SSO for heterogeneous systems. Subsystems retain independent login authentication, sensitive information is not centrally stored, and Kafka and Redis are used for information synchronization and caching. While this solution, to some extent, maintains the independence of subsystems and avoids centralized leakage of sensitive information, it relies on the introduction of a message middleware (Kafka) and a caching component for data synchronization, resulting in complex system deployment and interaction topology. More importantly, when the technology stacks of different heterogeneous subsystems are inconsistent with the unified platform, the problem of object serialization format differences in shared storage remains unresolved. Forcibly deserializing business objects written by the unified platform on the subsystem side introduces strong compile-time class dependencies, leading to project coupling; without deserialization, session data is unreadable. Furthermore, this solution fails to address the issue of partial nested logins that occur when embedded subsystems experience session expiration. Therefore, how to achieve secure, lightweight, and highly fault-tolerant single sign-on access without modifying the source code of the heterogeneous subsystem business controller remains a technical challenge that urgently needs to be solved. Summary of the Invention

[0006] To address the shortcomings of existing technologies, the purpose of this invention is to provide a method and system for single sign-on without modification for heterogeneous subsystems.

[0007] According to one aspect of the present invention, a method for single sign-on without modification for heterogeneous subsystems includes: Step S1: After the unified portal authentication is successful, a globally unique session pointer is generated, and a pointer token containing only the session pointer and not the user's plaintext business attributes is issued. Step S2: The unified portal writes the mapping relationship between the session pointer and the complete logged-in user object as a session entry with automatic renewal attribute into the shared session storage shared by the unified portal and each access subsystem. Step S3: The portal frontend writes the pointer token to the domain-shared cookie of each subsystem, which covers the scope of each subsystem; when loading a subsystem through an embedded frame, the pointer token is synchronously relayed to the subsystem request through multiple authentication headers, and passing it through hyperlink parameters is prohibited. Step S4: The access subsystem intercepts the request through the front-end dual-mode authentication interception module. If the integration configuration switch is enabled, the session pointer in the request is extracted; if the switch is disabled, the token is invalid, or the session is not hit, the system transparently falls back to the local authentication mode of the subsystem to the business layer. Step S5: The access subsystem uses the same key serializer addressing as the unified portal to retrieve the raw bytes from the shared session storage, parses them across serialization into a decoupled generic key-value mapping structure, and extracts the required username field through path navigation; Step S6: The access subsystem queries the local user database based on the extracted username. If a match is found, the local user is reused; otherwise, a mapped account with password login disabled is automatically created. Then, the local user identifier is injected into the context and the business request is allowed. Step S7: The unified portal centrally monitors and automatically renews shared sessions; when the subsystem interceptor returns an unauthorized state, the portal front-end controls the top-level framework to globally redirect to the unified login page; at the same time, the front-end adaptively switches the page rendering mode based on the window nesting state.

[0008] Preferably, step S1 specifically includes: The unified portal receives the authentication credentials submitted by the terminal and performs authentication. After successful authentication, it generates a globally unique session pointer corresponding to the currently authenticated user entity and issues a pointer token. The payload declaration of the pointer token includes the session pointer but does not include the plaintext of the user's business attributes. The plaintext of the user's business attributes is decoupled from the pointer token and stored independently by the server.

[0009] Preferably, step S2 specifically includes: The unified portal writes the mapping relationship between session pointers and logged-in user objects into a shared session storage that is shared by the unified portal and each access subsystem, according to a predetermined session key format. The shared session storage is a remote dictionary service, and the unified portal and each access subsystem are connected to the same instance and the same database number. The session key adopts the format of "prefix:session pointer" and has an automatically renewable validity period.

[0010] Preferably, step S3 specifically includes: The unified portal frontend writes the pointer token into the scope of the shared cookie between the portal and each access subsystem. When a user accesses any access subsystem through the portal, the unified portal frontend loads the subsystem page through an embedded frame and makes the request initiated by the subsystem carry the pointer token. The pointer token is relayed in the request message header through a first preset authentication request header and a second preset authentication request header, and the pointer token excludes the hyperlink query parameter carrying path during the transmission process.

[0011] Preferably, step S4 specifically includes: When the integration mode configuration switch is on, it operates in portal token mode, that is, it parses the session pointer in the pointer token carried in the request. When the integration mode configuration switch is off, the token parsing fails, or the shared session is missed or expires, it falls back to the subsystem local token mode for authentication. The integration mode configuration switch only applies to the interceptor and configuration layer. The way the subsystem business controller obtains the user identifier remains unchanged. In case of integration failure, setting the switch to off will allow the subsystem to immediately resume independent operation, and the rollback has zero impact.

[0012] Preferably, step S5 specifically includes: Login user objects are read from shared session storage using a generic key-value mapping method based on session pointers. The unified portal uses a first serialization protocol to write session values ​​into the shared session storage. The access subsystem configures a dedicated reading channel on its side using a second serialization protocol, and the key serializer of the dedicated reading channel is consistent with that of the unified portal. The retrieved raw bytes are parsed into a generic key-value mapping according to a general structure, and the required fields are extracted by navigating layer by layer in the manner of "map → user → userName".

[0013] Preferably, step S6 specifically includes: The system queries the local user database based on the username extracted from the logged-in user object. If a match is found, the username is reused directly. If no match is found, a local user record is automatically created based on the username. The user identifier is then injected into the request context and the business request is allowed. When automatically creating a local user record, only the username, nickname, and password fields are set to empty to disable local password login. The nickname field is synchronized as needed during subsequent accesses.

[0014] Preferably, step S7 specifically includes: Session Lifecycle Federation: The unified portal monitors the remaining duration of tokens. When the remaining duration is lower than a preset threshold, it automatically refreshes the validity period of session entries in the shared session storage. The access subsystem does not maintain renewal logic, but only passively shares the session's existence status. When a session expires or is actively canceled, if the shared session is not found, an unauthorized status is returned. After receiving the unauthorized status, the unified portal frontend redirects the entire parent framework to the unified portal login page. Portal front-end dual-state adaptive and embedded framework: The unified portal front-end switches between "portal shell mode" and "pure subpage mode" depending on whether it is embedded; when a subsystem page needs to close its own tab, it sends a close notification to the parent portal through the cross-window message protocol, and the portal executes the tab closure, thus forming a lightweight parent-child window collaboration.

[0015] According to another aspect of the present invention, a single sign-on system for heterogeneous subsystems without modification includes: Module M1: After successful authentication through the unified portal, a globally unique session pointer is generated, and a pointer token containing only the session pointer and without any plaintext user business attributes is issued. Module M2: The unified portal writes the mapping relationship between session pointers and complete logged-in user objects as session entries with automatic renewal attributes into the shared session storage shared by the unified portal and various access subsystems; Module M3: The portal frontend writes the pointer token to the scope of the domain-shared cookie of each subsystem; when loading a subsystem through an embedded frame, the pointer token is synchronously relayed to the subsystem request through multiple authentication headers, and passing it through hyperlink parameters is prohibited. Module M4: The access subsystem intercepts requests through the front-end dual-mode authentication interception module. If the integration configuration switch is enabled, the session pointer in the request is extracted; if the switch is disabled, the token is invalid, or the session is not hit, the system transparently falls back to the subsystem's local authentication mode to the business layer. Module M5: The access subsystem uses the same key serializer addressing as the unified portal, retrieves the raw bytes from the shared session storage, parses them across serialization into a decoupled generic key-value mapping structure, and extracts the required username field through path navigation; Module M6: The access subsystem queries the local user database based on the extracted username. If a match is found, the local user is reused; otherwise, a mapped account with password login disabled is automatically created. The local user identifier is then injected into the context and the business request is allowed. Module M7: A unified portal for centralized monitoring and automatic renewal of shared sessions; when a subsystem interceptor returns an unauthorized status, the portal front-end controls the top-level framework to globally redirect to the unified login page; simultaneously, the front-end adaptively switches the page rendering mode based on the window nesting state.

[0016] Preferably, the module M1 specifically includes: The unified portal receives the authentication credentials submitted by the terminal and performs authentication. After successful authentication, it generates a globally unique session pointer corresponding to the currently authenticated user entity and issues a pointer token. The payload declaration of the pointer token includes the session pointer but does not include the plaintext of the user's business attributes. The plaintext of the user's business attributes is decoupled from the pointer token and stored independently by the server.

[0017] Compared with the prior art, the present invention has the following beneficial effects: This invention utilizes a collaborative design of "needle token + shared session + token relay + dual-mode interception" to enable each access subsystem to complete single sign-on access without introducing a new authentication framework or modifying the business controller. It only requires placing a dual-mode authentication interception module before its request link. Furthermore, it achieves session lifecycle federation by cross-serialization reading of shared sessions using generic key-value mapping, domain-shared cookies and dual authentication header relay tokens, and unified redirection of the parent framework. This overcomes the unified login integration barrier in scenarios where the source code of heterogeneous and vendor legacy systems cannot be modified, and achieves truly non-modifiable and zero-intrusive access.

[0018] This invention solves the problems of unreadable sessions caused by inconsistent serialization protocols of different technology stacks (such as FastJson2 and Jackson) and fragile integration caused by strong references to portal classes by adopting a generic key-value mapping method to read shared sessions across serialization and decoupling the token from the logged-in user object. In addition, the token does not carry plaintext business fields and supports immediate cancellation and on-demand renewal.

[0019] This invention solves the problem of tokens being easily leaked by referrer pages and access logs when passed via hyperlink parameters by using domain-shared cookies and dual authentication header relay tokens.

[0020] This invention solves the problems of switching between multi-subsystem federation and dual-mode deployment in production environments and the need for immediate rollback in case of integration failures by adopting an integrated mode configuration switch and automatic rollback to local token mode when the token is invalid.

[0021] This invention solves the problems of isolated local login states and lack of unified re-authentication across the entire portal by adopting unified redirection of the parent frame and dual-state adaptiveness of the portal front end. Attached Figure Description

[0022] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 A schematic diagram of the single sign-on system architecture to avoid modifications; Figure 2 A schematic diagram of the single sign-on authentication sequence to avoid modification; Figure 3 This is a schematic diagram of the dual-mode authentication interception and session parsing process. Detailed Implementation

[0023] The present invention will now be described in detail with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the present invention, but do not limit the invention in any way. It should be noted that those skilled in the art can make several changes and improvements without departing from the concept of the present invention. These all fall within the scope of protection of the present invention.

[0024] Example 1: This embodiment provides a method for single sign-on without modification for heterogeneous subsystems, such as... Figures 1-3 As shown, the method includes: Step S1: After the unified portal authentication is successful, a globally unique session pointer is generated, and a pointer token containing only the session pointer and not the user's plaintext business attributes is issued.

[0025] Specifically, the unified portal receives the identity verification credentials submitted by the terminal and performs authentication; after successful authentication, it generates a globally unique session pointer corresponding to the currently authenticated user entity and issues a pointer token; wherein, the payload declaration of the pointer token contains the session pointer but does not contain the plaintext of the user business attributes, and the plaintext of the user business attributes is decoupled from the pointer token and stored independently by the server.

[0026] Step S2: The unified portal writes the mapping relationship between the session pointer and the complete logged-in user object as a session entry with automatic renewal attribute into the shared session storage shared by the unified portal and each access subsystem.

[0027] Specifically, the unified portal writes the mapping relationship between session pointers and logged-in user objects into a shared session storage that is shared by the unified portal and each access subsystem, according to a predetermined session key format. The shared session storage is a remote dictionary service (Redis), and the unified portal and each access subsystem are connected to the same instance and the same database number. The session key adopts the format of "prefix:session pointer" and has an automatically renewable validity period.

[0028] Step S3: The portal frontend writes the pointer token to the domain-shared cookie of each subsystem, which covers the scope of each subsystem; when loading a subsystem through an embedded frame, the pointer token is synchronously relayed to the subsystem request through multiple authentication headers, and passing it through hyperlink parameters is prohibited.

[0029] Specifically, the unified portal frontend writes the pointer token into the domain-shared cookie that covers the scope of the portal and each access subsystem. When a user accesses any access subsystem through the portal, the unified portal frontend loads the subsystem page through an embedded frame and makes the request initiated by the subsystem carry the pointer token. The pointer token is relayed in the request message header through a first preset authentication request header and a second preset authentication request header to adaptively adapt to the preset request header recognition rules of different access subsystems. The pointer token excludes the hyperlink query parameter carrying path during the transmission process.

[0030] Step S4: The access subsystem intercepts the request through the front-end dual-mode authentication interception module. If the integration configuration switch is enabled, the session pointer in the request is extracted; if the switch is disabled, the token is invalid, or the session is not hit, the system transparently falls back to the local authentication mode of the subsystem to the business layer.

[0031] Specifically, when the integration mode configuration switch is on, it operates in portal token mode, that is, it parses the session pointer in the pointer token carried by the request; when the integration mode configuration switch is off, the token parsing fails, or the shared session is missed or expires, it falls back to the subsystem local token mode for authentication; the integration mode configuration switch only affects the interceptor and configuration layer, and the way the subsystem business controller obtains the user identifier remains unchanged. In the event of an integration failure, simply turning the switch off will allow the subsystem to immediately resume independent operation, and the rollback has zero impact.

[0032] Step S5: The access subsystem uses the same key serializer addressing as the unified portal to retrieve the raw bytes from the shared session storage, parses them across serialization into a decoupled generic key-value mapping structure, and extracts the required username field through path navigation.

[0033] Specifically, the unified portal uses a first serialization protocol to write session values ​​to shared session storage. The access subsystem configures a dedicated read channel (dedicated RedisTemplate) using a second serialization protocol. The key serializer of this dedicated read channel is identical to that of the unified portal (both are string serializers), enabling it to correctly read session keys and retrieve raw bytes. The retrieved raw bytes are parsed into a generic key-value map (Map) according to a general structure, and then the required fields are extracted using a hierarchical navigation method of "map → user → userName". This strategy allows the access subsystem to correctly parse the logged-in user object without referencing any class definitions from the unified portal. It has zero engineering dependencies, can be independently compiled and deployed, and avoids session unreadable issues caused by inconsistencies in serialization protocols across different technology stacks.

[0034] Understandably, session parsing reads session entries using a generic MAP, without relying on the class definition of a unified portal, thus avoiding inconsistencies in serialization protocols across different technology stacks.

[0035] Step S6: The access subsystem queries the local user database based on the extracted username. If a match is found, the local user is reused; otherwise, a mapped account with password login disabled is automatically created. Subsequently, the local user identifier is injected into the context and the business request is allowed.

[0036] Specifically, the system queries the local user database of the user extracted from the logged-in user object. If a match is found, the user is reused directly. If no match is found, a local user record is automatically created based on the username. Only the username, nickname, and password fields are set to empty to disable local password login. The nickname field is synchronized as needed during subsequent accesses. The user identifier is then injected into the request context (request attributes and thread-level context) and the business request is allowed. The subsystem business controller is completely unaware of the above authentication process and still reads the user identifier from the request attributes in the original way.

[0037] Step S7: The unified portal centrally monitors and automatically renews shared sessions; when the subsystem interceptor returns an unauthorized state, the portal front-end controls the top-level framework to globally redirect to the unified login page; at the same time, the front-end adaptively switches the page rendering mode based on the window nesting state.

[0038] Specifically, (1) Session lifecycle federation: The unified portal monitors the remaining duration of the token. When the remaining duration is lower than the preset threshold (e.g., 20 minutes), it automatically refreshes the validity period of the session entries in the shared session storage. The access subsystem does not maintain the renewal logic and only passively shares the session's existence status. When the session expires or is actively canceled, the dual-mode authentication interception module of the access subsystem returns a 401 unauthorized status when it reads the shared session but fails to find the correct one. After receiving a 401, the unified portal frontend does not perform a local login redirection of the subsystem, but redirects the parent framework to the unified portal login page (parent.location.href), thereby triggering a re-authentication for the entire unified portal scope and preventing isolated local login states in the embedded subsystem.

[0039] Understandably, the business controller code of the heterogeneous subsystem is not modified throughout the entire process; single sign-on is only recorded in the dual-mode authentication module at the front end of the request chain.

[0040] (2) Portal front-end dual-state adaptive and embedded framework: The unified portal front-end switches between "portal shell mode" (rendering side navigation, top bar and multiple tabs) and "pure subpage mode" (rendering only the main area) depending on whether it is embedded (i.e. whether the window self reference window.self and the top-level reference window.top are consistent, and cross-domain access exceptions are also considered as being embedded). This allows the same set of routing components to run as both a portal shell and an embedded subsystem page. When a subsystem page needs to close its own tab, it sends a close notification to the parent portal through the cross-window message protocol (postMessage), and the portal executes the tab closure, forming a lightweight parent-child window collaboration.

[0041] Example 2: This embodiment provides a single sign-on method for heterogeneous subsystems without modification. In simple terms, after unified portal authentication, a token carrying only a session pointer is issued → The session pointer and the logged-in user object are written to shared session storage → The portal frontend writes the token to a domain shared cookie and relays it to the subsystem via an embedded framework and dual authentication header → The subsystem's front-end dual-mode authentication interception module prioritizes parsing the session pointer according to the integrated mode switch → The session is read across serialization using generic key-value mapping → Access is granted after mapping by username or automatically creating a local user → If the token is invalid, it reverts to the local token mode; expired sessions are uniformly redirected by the parent framework. The tokens, session pointers, and logged-in user objects generated in each step are all used in subsequent steps.

[0042] Step S1, Unified Portal Authentication and Pointer Token Issuance: The unified portal receives login credentials submitted by user terminals and performs identity authentication. After successful authentication, the token issuance module generates a globally unique session pointer and issues a token that carries only this session pointer and does not contain user details. The token is a stateless signed token (JWT / HS512), whose declaration only contains the session pointer (login_user_key) and the issuer identifier, and does not contain plaintext business fields such as user identifier, role, or permissions. The logged-in user object (including user identifier, username, nickname, role set, and permission set) is stored in the server-side shared session storage, thus decoupling the token from the logged-in user object.

[0043] Step S2, Shared session write: The unified portal's shared session writing module writes the mapping relationship between session pointers and logged-in user objects into a shared session storage accessible by the unified portal and various access subsystems, using a predefined session key format. The shared session storage is a remote dictionary service (Redis), with the unified portal and various access subsystems connected to the same instance and database ID. The session key uses the format "prefix:session pointer" and has an automatically renewable expiration period.

[0044] Step S3, Domain Sharing Cookie and Token Relay: The unified portal frontend writes a token to a domain-shared cookie that covers the scope of the portal and each access subsystem. When a user accesses any access subsystem through the portal, the token relay module in the portal frontend loads the subsystem page via an embedded frame, and the request initiated by the subsystem carries the token. The token relay module carries both the first authentication header (Authorization) and the second authentication header (X-XSRF-TOKEN) in the subsystem request, both carrying the same token to adapt to the different subsystems' recognition habits of authentication headers; the key name of the domain-shared cookie is consistent with the second authentication header. The token is not passed through hyperlink parameters, avoiding the risk of leakage via referrer pages and logs.

[0045] Step S4, Dual-mode authentication interception: When the integration mode configuration switch is enabled, the dual-mode authentication interception module in the access subsystem prioritizes the portal token mode: parsing the session pointer in the token carried in the request. When the integration mode configuration switch is disabled, token parsing fails, or the shared session is missed or expired, it falls back to the subsystem's local token mode for authentication. This switch only affects the interceptor and configuration layer; the way the subsystem's business controller obtains the user identifier remains unchanged. In case of integration failure, simply turning the switch off allows the subsystem to immediately resume independent operation, with zero impact from rollback.

[0046] Step S5, Session Resolution – Reading Generic Key-Value Maps Across Serializations: The dual-mode authentication interception module calls the session parsing module to read the logged-in user object from the shared session storage using a generic key-value mapping method based on the session pointer. This reading does not depend on the class definition of the unified portal.

[0047] Specifically, the unified portal uses a first serialization protocol to write session values ​​to shared session storage. The access subsystem configures a dedicated read channel (dedicated RedisTemplate) using a second serialization protocol. The key serializer of this dedicated read channel is identical to that of the unified portal (both are string serializers), enabling correct reading of session keys and retrieval of raw bytes. The session parsing module parses the retrieved bytes into a generic key-value map (Map) according to a general structure, and then extracts the required fields using a hierarchical navigation method: "map → user → userName". This strategy allows the access subsystem to correctly parse the logged-in user object without referencing any class definitions from the unified portal. It has zero engineering dependencies, can be independently compiled and deployed, and avoids session unreadable issues caused by inconsistent serialization protocols across different technology stacks.

[0048] Step S6, User Mapping – Local Hit Reuse or Automatic Creation: The dual-mode authentication interception module calls the user mapping module to query the subsystem's local user database based on the username extracted from the logged-in user object. If a match is found, the username is reused directly; otherwise, a local user record is automatically created based on that username—only the username, nickname, and password fields are set to empty to disable local password login. The nickname field is synchronized as needed during subsequent accesses. The user identifier is then injected into the request context (request attributes and thread-level context) and the business request is allowed. The subsystem business controller is completely unaware of the above authentication process and still reads the user identifier from the request attributes in the original way.

[0049] Step S7, rollback local token, session lifecycle federation, and portal frontend bi-state adaptation: (1) Session lifecycle federation: The unified portal monitors the remaining duration of the token. When the remaining duration is lower than the preset threshold (e.g., 20 minutes), the validity period of the session entries in the shared session storage is automatically refreshed. The access subsystem does not maintain the renewal logic and only passively shares the session's existence status. When the session expires or is actively canceled, the dual-mode authentication interception module of the access subsystem reads the shared session but fails to hit and returns an unauthorized status. After receiving the unauthorized status, the portal frontend does not perform a local login redirection of the subsystem, but redirects the parent framework as a whole to the portal login page (parent.location.href), thereby triggering a re-authentication for the entire portal scope and preventing isolated local login states in embedded subsystems.

[0050] (2) Portal front-end dual-state adaptive and embedded framework: The portal front-end switches between "portal shell mode" (rendering side navigation, top bar and multiple tabs) and "pure subpage mode" (rendering only the main area) depending on whether it is embedded (i.e. whether the window self reference window.self and the top-level reference window.top are consistent, and cross-domain access exceptions are also considered as being embedded). This allows the same set of routing components to run as both a portal shell and an embedded subsystem page. When a subsystem page needs to close its own tab, it sends a close notification to the parent portal through the cross-window message protocol (postMessage), and the portal executes the tab closure, forming a lightweight parent-child window collaboration.

[0051] The present invention also provides a single sign-on system for heterogeneous subsystems without modification. The single sign-on system for heterogeneous subsystems without modification can be implemented by executing the process steps of the single sign-on method for heterogeneous subsystems without modification. That is, those skilled in the art can understand the single sign-on method for heterogeneous subsystems without modification as a preferred embodiment of the single sign-on system for heterogeneous subsystems without modification.

[0052] Those skilled in the art will understand that, besides implementing the system and its various devices, modules, and units provided by this invention in the form of purely computer-readable program code, the same functions can be achieved entirely through logical programming of the method steps, enabling the system and its various devices, modules, and units to function in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, the system and its various devices, modules, and units provided by this invention can be considered a hardware component, and the devices, modules, and units included therein for implementing various functions can also be considered structures within the hardware component; alternatively, the devices, modules, and units for implementing various functions can be considered both software modules implementing the method and structures within the hardware component.

[0053] Specific embodiments of the present invention have been described above. It should be understood that the present invention is not limited to the specific embodiments described above, and those skilled in the art can make various changes or modifications within the scope of the claims, which do not affect the essence of the present invention. Unless otherwise specified, the embodiments and features described in this application can be arbitrarily combined with each other.

Claims

1. A method for single sign-on without modification in a heterogeneous subsystem, characterized in that, include: Step S1: After the unified portal authentication is successful, a globally unique session pointer is generated, and a pointer token containing only the session pointer and not the user's plaintext business attributes is issued. Step S2: The unified portal writes the mapping relationship between the session pointer and the complete logged-in user object as a session entry with automatic renewal attribute into the shared session storage shared by the unified portal and each access subsystem. Step S3: The portal frontend writes the pointer token to the scope, overriding the domain-shared cookie of each subsystem; When loading a subsystem via an embedded frame, the pointer token is synchronously relayed to the subsystem request through multiple authentication headers, and passing it via hyperlink parameters is prohibited. Step S4: The access subsystem intercepts the request through the front-end dual-mode authentication interception module. If the integration configuration switch is enabled, the session pointer in the request is extracted; if the switch is disabled, the token is invalid, or the session is not hit, the system transparently falls back to the local authentication mode of the subsystem to the business layer. Step S5: The access subsystem uses the same key serializer addressing as the unified portal to retrieve the raw bytes from the shared session storage, parses them across serialization into a decoupled generic key-value mapping structure, and extracts the required username field through path navigation; Step S6: The access subsystem queries the local user database based on the extracted username. If a match is found, the local user is reused; otherwise, a mapped account with password login disabled is automatically created. Then, the local user identifier is injected into the context and the business request is allowed. Step S7: The unified portal centrally monitors and automatically renews shared sessions; when the subsystem interceptor returns an unauthorized state, the portal front-end controls the top-level framework to globally redirect to the unified login page; at the same time, the front-end adaptively switches the page rendering mode based on the window nesting state.

2. The method according to claim 1, characterized in that, Step S1 specifically includes: The unified portal receives the authentication credentials submitted by the terminal and performs authentication. After successful authentication, it generates a globally unique session pointer corresponding to the currently authenticated user entity and issues a pointer token. The payload declaration of the pointer token includes the session pointer but does not include the plaintext of the user's business attributes. The plaintext of the user's business attributes is decoupled from the pointer token and stored independently by the server.

3. The method according to claim 1, characterized in that, Step S2 specifically includes: The unified portal writes the mapping relationship between session pointers and logged-in user objects into a shared session storage that is shared by the unified portal and each access subsystem, according to a predetermined session key format. The shared session storage is a remote dictionary service, and the unified portal and each access subsystem are connected to the same instance and the same database number. The session key adopts the format of "prefix:session pointer" and has an automatically renewable validity period.

4. The method according to claim 1, characterized in that, Step S3 specifically includes: The unified portal frontend writes the pointer token into the scope of the shared cookie between the portal and each access subsystem. When a user accesses any access subsystem through the portal, the unified portal frontend loads the subsystem page through an embedded frame and makes the request initiated by the subsystem carry the pointer token. The pointer token is relayed in the request message header through a first preset authentication request header and a second preset authentication request header, and the pointer token excludes the hyperlink query parameter carrying path during the transmission process.

5. The method according to claim 1, characterized in that, Step S4 specifically includes: When the integration mode configuration switch is on, it operates in portal token mode, that is, it parses the session pointer in the pointer token carried in the request. When the integration mode configuration switch is off, the token parsing fails, or the shared session is missed or expires, it falls back to the subsystem local token mode for authentication. The integration mode configuration switch only applies to the interceptor and configuration layer. The way the subsystem business controller obtains the user identifier remains unchanged. In case of integration failure, setting the switch to off will allow the subsystem to immediately resume independent operation, and the rollback has zero impact.

6. The method according to claim 1, characterized in that, Step S5 specifically includes: Login user objects are read from shared session storage using a generic key-value mapping method based on session pointers. The unified portal uses a first serialization protocol to write session values ​​into the shared session storage. The access subsystem configures a dedicated reading channel on its side using a second serialization protocol, and the key serializer of the dedicated reading channel is consistent with that of the unified portal. The retrieved raw bytes are parsed into a generic key-value mapping according to a general structure, and the required fields are extracted by navigating layer by layer in the manner of "map → user → userName".

7. The method according to claim 1, characterized in that, Step S6 specifically includes: The system queries the local user database based on the username extracted from the logged-in user object. If a match is found, the username is reused directly. If no match is found, a local user record is automatically created based on the username. The user identifier is then injected into the request context and the business request is allowed. When automatically creating a local user record, only the username, nickname, and password fields are set to empty to disable local password login. The nickname field is synchronized as needed during subsequent accesses.

8. The method according to claim 1, characterized in that, Step S7 specifically includes: Session Lifecycle Federation: The unified portal monitors the remaining duration of tokens. When the remaining duration is lower than a preset threshold, it automatically refreshes the validity period of session entries in the shared session storage. The access subsystem does not maintain renewal logic, but only passively shares the session's existence status. When a session expires or is actively canceled, if the shared session is not found, an unauthorized status is returned. After receiving the unauthorized status, the unified portal frontend redirects the entire parent framework to the unified portal login page. Portal front-end dual-state adaptive and embedded framework: The unified portal front-end switches between "portal shell mode" and "pure subpage mode" depending on whether it is embedded; when a subsystem page needs to close its own tab, it sends a close notification to the parent portal through the cross-window message protocol, and the portal executes the tab closure, thus forming a lightweight parent-child window collaboration.

9. A single sign-on system for heterogeneous subsystems without modification, characterized in that, include: Module M1: After successful authentication through the unified portal, a globally unique session pointer is generated, and a pointer token containing only the session pointer and without any plaintext user business attributes is issued. Module M2: The unified portal writes the mapping relationship between session pointers and complete logged-in user objects as session entries with automatic renewal attributes into the shared session storage shared by the unified portal and various access subsystems; Module M3: The portal frontend writes pointer tokens to the scope, overriding the domain-shared cookies of each subsystem; When loading a subsystem via an embedded frame, the pointer token is synchronously relayed to the subsystem request through multiple authentication headers, and passing it via hyperlink parameters is prohibited. Module M4: The access subsystem intercepts requests through the front-end dual-mode authentication interception module. If the integration configuration switch is enabled, the session pointer in the request is extracted; if the switch is disabled, the token is invalid, or the session is not hit, the system transparently falls back to the subsystem's local authentication mode to the business layer. Module M5: The access subsystem uses the same key serializer addressing as the unified portal, retrieves the raw bytes from the shared session storage, parses them across serialization into a decoupled generic key-value mapping structure, and extracts the required username field through path navigation; Module M6: The access subsystem queries the local user database based on the extracted username. If a match is found, the local user is reused; otherwise, a mapped account with password login disabled is automatically created. The local user identifier is then injected into the context and the business request is allowed. Module M7: A unified portal for centralized monitoring and automatic renewal of shared sessions; when a subsystem interceptor returns an unauthorized status, the portal front-end controls the top-level framework to globally redirect to the unified login page; simultaneously, the front-end adaptively switches the page rendering mode based on the window nesting state.

10. The system according to claim 9, characterized in that, The module M1 specifically includes: The unified portal receives the authentication credentials submitted by the terminal and performs authentication. After successful authentication, it generates a globally unique session pointer corresponding to the currently authenticated user entity and issues a pointer token. The payload declaration of the pointer token includes the session pointer but does not include the plaintext of the user's business attributes. The plaintext of the user's business attributes is decoupled from the pointer token and stored independently by the server.

Images