Login method and apparatus

Abstract

This disclosure proposes a login method and apparatus. The method includes: responding to a login request from a first client, determining a list of accessible subsystems based on a user identifier, generating a login token, and returning the token and user attribute information containing the subsystem list to the client; after the user selects a target subsystem, the client opens the login interface through an integration adapter, and when the subsystem uses token authentication, sends the token and adapted user permission information to a second server; the second server requests the first server to verify the token, and upon successful verification, automatically fills in login information to complete the login, and provides corresponding business services based on user permissions. This avoids users repeatedly entering account passwords in multiple systems, eliminating the security risks caused by password reuse and weak passwords; user data is centrally managed by the first server, eliminating the need for manual maintenance by each subsystem, significantly improving the efficiency and accuracy of permission synchronization during organizational changes.

Description

Technical Field

[0001] This disclosure relates to the field of Internet technology, and in particular to a login method and apparatus. Background Technology

[0002] As enterprises deepen their digital transformation and their business scale continues to expand, various information systems (such as Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), Office Automation (OA), and Human Resource Management (HRM)) are widely deployed to support the operational needs of different functional areas. However, these systems are usually independently developed and deployed by different vendors based on heterogeneous technology stacks (such as Java, .NET, and PHP), lacking a unified identity authentication and user management mechanism among them.

[0003] In this environment, users often need to log in with different accounts and passwords when accessing multiple business systems. This not only leads to cumbersome operation processes and a fragmented user experience, but also significantly increases security risks such as credential leakage, account theft, and lateral movement because users frequently reuse passwords or set weak passwords for ease of memorization. Summary of the Invention

[0004] This disclosure provides a login method and apparatus to at least partially solve one of the technical problems in the related art. The technical solution of this disclosure is as follows:

[0005] According to a first aspect of the present disclosure, a login method is provided, applied to a first server for login authentication, comprising: in response to receiving a login request from a first client for login, determining a list of accessible subsystems matching the login user identifier based on a login user identifier carried in the first login request, and generating a login token for accessing at least one subsystem in the list of accessible subsystems; sending the login token and user attribute information associated with the login user identifier to the first client to display the list of accessible subsystems carried in the user attribute information on the first client; wherein the list of accessible subsystems is used by the first client in response to a selection operation to determine a target subsystem from the at least one subsystem, and through integration of the target subsystem. The adapter opens the login interface of the target subsystem and, in response to the target subsystem's authentication method being token authentication, sends the login token and user permission information adapted to the target subsystem to the second server of the target subsystem; it receives a token verification request sent by the second server of the target subsystem, verifies the login token in the token verification request to obtain a verification result, and sends the verification result to the second server; wherein, the verification result is used to indicate that, if the login token verification passes, the login user permissions and login information are determined according to the user permission information, so as to fill in the login information on the login interface to complete the login, and provide corresponding business processing services on the second client of the target subsystem according to the login user permissions.

[0006] According to a second aspect of the present disclosure, a login method is provided, applied to a first client for login, comprising: in response to a login operation, sending a login request to a first server for login authentication; wherein the first login request is used by the first server to determine a list of accessible subsystems matching the login user identifier based on a login user identifier carried in the first login request, and to generate a login token for accessing at least one subsystem in the list of accessible subsystems, and to send the login token and user attribute information associated with the login user identifier to the first client; receiving the login token and the user attribute information sent by the first server, and displaying the list of accessible subsystems carried in the user attribute information; in response to a selection operation on the list of accessible subsystems, determining a target subsystem from the at least one subsystem, and accessing the target subsystem through the target subsystem... The system's integration adapter opens the login interface of the target subsystem and, in response to the target subsystem's authentication method being token authentication, sends the login token and user permission information adapted to the target subsystem to the second server of the target subsystem. The login token is used by the second server of the target subsystem to generate a token verification request and send the request to the first server to verify the login token in the verification request, obtain a verification result, and send the verification result to the second server. The verification result indicates that, if the login token verification passes, the login user's permissions and login information are determined based on the user permission information. The login information is then filled into the login interface to complete the login, and corresponding business processing services are provided to the second client of the target subsystem based on the login user's permissions.

[0007] According to a third aspect of the present disclosure, a login device is provided, applied to a first server for login authentication. A generation module is configured to, in response to receiving a login request from a first client for login, determine a list of accessible subsystems matching the login user identifier carried in the first login request, and generate a login token for accessing at least one subsystem in the list of accessible subsystems. A sending module is configured to send the login token and user attribute information associated with the login user identifier to the first client, so as to display the list of accessible subsystems carried in the user attribute information on the first client. The list of accessible subsystems is used by the first client in response to a selection operation to determine a target subsystem from the at least one subsystem, and access the target subsystem. The integrated adapter opens the login interface of the target subsystem and, in response to the target subsystem's authentication method being token authentication, sends the login token and user permission information adapted to the target subsystem to the second server of the target subsystem. The receiving module receives a token verification request sent by the second server of the target subsystem, verifies the login token in the token verification request to obtain a verification result, and sends the verification result to the second server. The verification result indicates that, if the login token verification passes, the login user's permissions and login information are determined based on the user permission information. The login information is then filled into the login interface to complete the login, and corresponding business processing services are provided to the second client of the target subsystem based on the login user's permissions.

[0008] According to a fourth aspect of the present disclosure, a login device is provided, applied to a first client for login, comprising: a first sending module, configured to send a login request to a first server for login authentication in response to a login operation; wherein the first login request is used by the first server to determine a list of accessible subsystems matching the login user identifier carried in the first login request, and to generate a login token for accessing at least one subsystem in the list of accessible subsystems, and to send the login token and user attribute information associated with the login user identifier to the first client; a receiving module, configured to receive the login token and the user attribute information sent by the first server, and to display the list of accessible subsystems carried in the user attribute information; and a selection module, configured to determine a target subsystem from the at least one subsystem in response to a selection operation on the list of accessible subsystems. The system opens the login interface of the target subsystem through the integration adapter of the target subsystem, and in response to the target subsystem's authentication method being token authentication, sends the login token and user permission information adapted to the target subsystem to the second server of the target subsystem; wherein, the login token is used by the second server of the target subsystem to generate a token verification request and send the token verification request to the first server to verify the login token in the token verification request, obtain a verification result, and send the verification result to the second server. The verification result is used to indicate that if the login token verification is successful, the login user permissions and login information are determined according to the user permission information, so as to fill the login information on the login interface to complete the login, and provide corresponding business processing services on the second client of the target subsystem according to the login user permissions.

[0009] According to a fifth aspect of the present disclosure, an electronic device is provided, comprising: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to execute the instructions to implement a login method as described in a first aspect of the present disclosure, or to implement a login method as described in a second aspect of the present disclosure.

[0010] According to a sixth aspect of the present disclosure, a computer-readable storage medium is provided, wherein when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to perform a login method as described in a first aspect embodiment of the present disclosure, or to perform a login method as described in a second aspect embodiment of the present disclosure.

[0011] According to a seventh aspect of the present disclosure, a computer program product is provided, comprising: a computer program that, when executed by a processor, implements the login method as described in the first aspect of the present disclosure, or implements the login method as described in the second aspect of the present disclosure.

[0012] The technical solutions provided by the embodiments of this disclosure bring at least the following beneficial effects: In this technical solution, when the first server receives a login request from the first client, it determines the list of accessible subsystems based on the login user identifier and generates a login token for cross-system authentication to support unified login and avoid users repeatedly authenticating in multiple subsystems. This token, along with global user attribute information, is sent to the first client, allowing the client to intuitively display the business systems the user is authorized to access. When a user selects a target subsystem, the system automatically opens the login interface of that target subsystem through a pre-built integration adapter. If the target subsystem uses token authentication, the system sends user permission information adapted to that subsystem to the second server of that subsystem. The second server of the target subsystem then proactively initiates a token verification request to the first server. This verifies the token's validity while simultaneously determining the login user's permissions and login information based on the user permission information, automatically filling in the login information to complete authentication, and providing corresponding business processing services in the second client. This avoids users repeatedly entering their account and password in multiple heterogeneous systems, eliminating the need for password-related authentication. Security risks arising from reuse or weak password policies are mitigated. Meanwhile, user data is centrally managed by a primary server, eliminating the need for manual maintenance in each subsystem and significantly improving the efficiency and accuracy of permission synchronization during organizational restructuring. Specifically, the integration adapter for the target subsystem acquires the target subsystem's permission mapping information and, based on this mapping, accurately filters a subset of user attributes relevant to that subsystem from global user attribute information. This subset is then structurally transformed according to the target subsystem's semantic rules, dynamically generating user permission information adapted to that subsystem. This eliminates the need for subsystems of different technology types to pre-store or hard-code user permissions. Furthermore, user permission information includes at least one of the following: local role, job identifier, and local user identifier, obtained by transforming the user attribute subset based on permission configuration information. This avoids redundant storage or manual maintenance of user roles and job information in each subsystem. When organizational structure or user attributes change, permission information can be dynamically generated and take effect in real time during the authentication process, significantly improving the consistency, security, and operational efficiency of permission management.

[0013] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0014] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0015] Figure 1 This is a flowchart illustrating the login method shown in the first embodiment of this disclosure; Figure 2 This is a schematic flowchart of the login method shown in the second embodiment of this disclosure; Figure 3 This is a schematic flowchart of the login method shown in the third embodiment of this disclosure; Figure 4 This is a schematic flowchart of the login method shown in the fourth embodiment of this disclosure; Figure 5 This is a schematic flowchart of the login method shown in the fifth embodiment of this disclosure; Figure 6 This is a flowchart illustrating the login method shown in the sixth embodiment of this disclosure; Figure 7 This is a schematic diagram of the structure of the unified login system shown in the embodiments of this disclosure; Figure 8 This is a schematic diagram illustrating the effect of the list of accessible subsystems shown in the embodiments of this disclosure; Figure 9 This is a schematic diagram illustrating the principle of the subsystem integration method shown in the embodiments of this disclosure; Figure 10 This is a schematic diagram illustrating the adaptive adaptation of subsystem permissions after a change in user role, as shown in an embodiment of this disclosure. Figure 11 This is a schematic flowchart of the login method shown in the embodiments of this disclosure; Figure 12 This is a schematic diagram of the login device shown in the seventh embodiment of this disclosure; Figure 13 This is a schematic diagram of the login device shown in the eighth embodiment of this disclosure; Figure 14 This is a schematic diagram of the structure of an electronic device shown in an exemplary embodiment of the present disclosure. Detailed Implementation

[0016] To enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings.

[0017] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0018] It should be noted that the collection, storage, use, processing, transmission, provision and disclosure of user personal information involved in the technical solution disclosed herein are all carried out with the consent of the user, and all comply with the provisions of relevant laws and regulations, and do not violate public order and good morals.

[0019] In related technologies, a unified user management system (UUMS) is established. UUMS centrally stores, maintains, and manages user information across all application systems. User authentication is handled entirely by UUMS, while user access control is handled by each individual application system. This approach has several problems: 1. While each subsystem doesn't need to maintain or store complete user information, it does need to synchronize basic user data (such as user ID and department); 2. There is no control over user access permissions to subsystems; 3. Unified login is difficult to achieve for older, unmodifiable systems; 4. Changes in user roles and positions leading to permission changes cannot be transmitted to each subsystem through the unified login system, requiring individual permission adjustments within each subsystem.

[0020] To address any of the above problems, this disclosure proposes a login method and apparatus.

[0021] The login method and apparatus of this disclosure are described below with reference to the accompanying drawings.

[0022] Figure 1 This is a flowchart illustrating the login method shown in the first embodiment of this disclosure.

[0023] It should be noted that, in this embodiment of the disclosure, the login method is configured in a login device as an example. The login device can be applied to a first server for login authentication so that the first server can perform the login function.

[0024] like Figure 1 As shown, the login method includes: Step 110: In response to receiving a login request from a first client for login, determine a list of accessible subsystems that match the login user identifier carried in the first login request, and generate a login token for accessing at least one subsystem in the list of accessible subsystems.

[0025] To achieve unified identity authentication and system access control for users across multiple system environments, one possible approach is to send a login request to a first server used for unified authentication after a user initiates a login operation on the first client. Upon receiving the login request containing the login user's identifier, the first server queries relevant permission data based on the login user identifier to determine all business subsystems that the user is currently authorized to access, and generates a list of accessible subsystems. The first client could be, for example, a mobile app or browser, and the login user identifier could be, for example, an employee ID, email address, or a globally unique ID. Simultaneously, the first server issues a login token with time-limited validity, scope restrictions, and tamper-proof capabilities. This login token is associated with the list of accessible subsystems and can serve as a credential for subsequent cross-system access.

[0026] In some embodiments, such as Figure 2 As shown, step 110 may include the following steps: Step 1101: In response to receiving a login request sent by the first client for login, query and verify the login access information that matches the login user identifier based on the login user identifier.

[0027] As an example, when the first server receives a login request from the first client, it extracts the login user identifier and queries the corresponding login access information based on the login user identifier. The login access information may include, but is not limited to, account status and login status. This can effectively block illegal or high-risk login attempts, such as login by a former employee's account, access outside of working hours, or access from an abnormal geographical location.

[0028] Step 1102: In response to the login access information being verified, query the list of accessible subsystems that match the login user's identifier.

[0029] Furthermore, after confirming that a user meets the login access requirements, the system queries the set of business subsystems that the user is authorized to access, forming a list of accessible subsystems. It should be noted that this list of accessible subsystems is calculated based on the user's organizational affiliation, job title, role, project permissions, and other attributes, combined with the access control policies of each subsystem. This ensures that only users who have passed security access are allowed access to the business systems they are authorized to use, preventing unauthorized access.

[0030] Step 120: Send a login token and user attribute information associated with the logged-in user identifier to the first client to display the list of access subsystems carried by the user attribute information to the first client.

[0031] The access subsystem list is used by the first client in response to the selection operation to determine the target subsystem from at least one subsystem, open the login interface of the target subsystem through the integration adapter of the target subsystem, and send a login token and user permission information adapted to the target subsystem to the second server of the target subsystem in response to the authentication method of the target subsystem being token authentication.

[0032] Then, the first server returns the generated login token and the global user attribute information associated with the login user identifier to the first client. The user attribute information may include, but is not limited to: user ID, user name, affiliated organization, affiliated position, a list of roles associated with the affiliated position, global roles, employee type, and a list of accessible subsystems. The first client parses the list of accessible subsystems contained in the user attribute information and displays the subsystems in the list of accessible subsystems in the form of icons, menus, or cards on the user interface for the user to select, so as to realize an intuitive presentation and interactive guidance of the systems available to the user.

[0033] As one possible implementation, when a user clicks on a subsystem on the first client, the first client will identify the subsystem as the target subsystem and call the pre-set integration adapter corresponding to the target subsystem to open the login interface of the target subsystem. If the target subsystem supports token authentication instead of traditional account password authentication, the client will send the login token and user permission information adapted to the target subsystem to the second server of the target subsystem through the integration adapter. The second server is the backend service of the target subsystem itself.

[0034] In some embodiments, such as Figure 3 As shown, user permission information is determined using the following steps: Step 1201: Obtain the permission mapping information of the target subsystem.

[0035] After the user selects a target subsystem, the first client loads the corresponding permission mapping information for that subsystem by calling the subsystem's integration adapter. It should be noted that the permission mapping information is used to convert global user attribute information such as global roles, organizational positions, or user identifiers into local permission elements that the target subsystem can recognize and process. These local permission elements include local roles, position identifiers, and local user identifiers. It should also be noted that the permission mapping information is configured by the system administrator when the subsystem is connected and is bound to the subsystem's unique identifier.

[0036] Step 1202: Based on the permission mapping information, filter out the subset of user attributes associated with the target subsystem from the user attribute information.

[0037] Based on the permission mapping information of the target subsystem, the global attribute fields referenced in the permission mapping information are analyzed by the integration adapter, and relevant fields are extracted from the user attribute information according to the global attribute fields to generate a subset of user attributes. For example, if the mapping rule includes "global_role" and "org_position", then the role and position fields are extracted from the user attribute information to generate a subset of user attributes.

[0038] Step 1203: Based on the permission mapping information, transform the user attribute subset to obtain user permission information that is compatible with the target subsystem.

[0039] To achieve automatic adaptation of permissions across systems, as one possible approach, the integration adapter of the target subsystem performs structured mapping and format conversion on the selected subset of user attributes based on the specific conversion rules defined in the permission mapping information, generating user permission information that meets the permission requirements of the target subsystem.

[0040] In some embodiments, such as Figure 4 As shown, step 1203 may include the following steps: Step 12031: Based on the role mapping rules in the permission configuration information, convert the global roles in the user attribute subset into local roles supported by the target subsystem.

[0041] As an example, a user is assigned one or more global roles, such as "Finance Specialist" or "Regional Manager." The integration adapter of the target subsystem, based on the role mapping rules predefined in the target subsystem's permission configuration information, accurately converts the global roles contained in the user attribute subset into local roles recognizable by the target subsystem. For example, the global role "Finance Specialist" is converted into the local role "FIN_01." This solves the problem of inconsistent role naming and definitions across different systems and avoids permission mismatches due to semantic differences.

[0042] Step 12032: Based on the job mapping rules in the permission configuration information, convert the organizational jobs in the user attribute subset into job identifiers that can be recognized by the target subsystem.

[0043] It is important to understand that, due to the different coding methods or naming conventions for job positions in each subsystem, the integration adapter of the target subsystem converts the original job information in the user attribute subset into a standardized job identifier that can be recognized by the target subsystem based on the job mapping rules preset in the permission configuration information.

[0044] Step 12033: Based on the identifier mapping rules in the permission configuration information, convert the global user identifier in the user attribute subset into the local user identifier required by the target subsystem.

[0045] To avoid login failures due to incompatible user account formats, as an example, the integration adapter of the target subsystem generates a local user identifier that meets the requirements of the target subsystem from the global user identifier in the user attribute subset according to the identifier mapping rules in the permission configuration information.

[0046] Step 12034: Generate user permission information based on at least one of the local role, job identifier, and local user identifier.

[0047] Furthermore, the integration adapter of the target subsystem combines at least one of the local role, job identifier, and local user identifier to generate the final user permission information, thereby ensuring the accuracy of permissions while guaranteeing the integration flexibility and compatibility of various subsystems.

[0048] Furthermore, it should be noted that in actual enterprise operations, user access permissions to various subsystems may be dynamically modified due to reasons such as temporary authorization, role delegation, and role adjustments. For example, temporarily granting an employee approval permissions in the financial system, or disabling a role after organizational restructuring. In this scenario, the user permission information generated based on historical mapping rules may not match the current actual permission configuration of the target subsystem.

[0049] Therefore, user permission information is compared with the permission configuration information of the target subsystem to determine whether the generated local roles, job identifiers, or user identifiers are consistent with the currently allowed permission scope of the target subsystem. When an inconsistency is detected, the user permission information is updated based on the permission configuration information of the target subsystem. For example, it may be automatically replaced with the default valid role, changed to basic job permissions, or a compliance identifier may be regenerated according to the new mapping rules.

[0050] Step 130: Receive the token verification request sent by the second server of the target subsystem, verify the login token in the token verification request to obtain the verification result, and send the verification result to the second server.

[0051] The verification result is used to indicate that if the login token verification is successful, the login user's permissions and login information are determined based on the user permission information, so that the login information can be filled in on the login interface to complete the login, and corresponding business processing services can be provided on the second client of the target subsystem according to the login user's permissions.

[0052] Furthermore, to enhance the security of cross-system authentication and prevent token forgery, the second server of the target subsystem, upon receiving user permission information and a login token, does not directly trust the validity of the login token. Instead, it initiates a token verification request to the first server of unified authentication. The first server verifies the login token in the token verification request, such as verifying the integrity, validity, scope, and revocation status of the login token, generates a verification result, and returns the verification result to the second server.

[0053] Furthermore, when the verification result confirms that the token is valid, the second server determines the user's specific permission scope and login information in this system based on the user's permission information. Subsequently, the system automatically fills in the login information in the login interface without requiring the user to enter the credentials again, and determines the accessible functional modules, data range, etc. based on the logged-in user's permissions, providing personalized business services in the second client. The login information may include, but is not limited to, username, display name, etc.

[0054] The login method of this embodiment, when the first server receives a login request from the first client, determines a list of accessible subsystems based on the login user identifier and generates a login token for cross-system authentication to support unified login and avoid users repeatedly authenticating in multiple subsystems. The token, along with global user attribute information, is sent to the first client, allowing the client to intuitively display the business systems the user is authorized to access. When the user selects a target subsystem, the system automatically opens the login interface of that target subsystem through a pre-configured integration adapter. If the target subsystem uses token authentication mode, the system sends a login request to the second server of that target subsystem. The system sends user permission information adapted to the target subsystem, and the second server of the target subsystem proactively initiates a token verification request to the first server. This verifies the validity of the token, determines the login user's permissions and login information based on the user permission information, automatically fills in the login information to complete authentication, and provides corresponding business processing services in the second client. This avoids users repeatedly entering their account passwords in multiple heterogeneous systems and eliminates security risks caused by password reuse or weak password policies. At the same time, user data is centrally managed by the first server, eliminating the need for manual maintenance in each subsystem, significantly improving the efficiency and accuracy of permission synchronization during organizational structure changes.

[0055] The above are various method embodiments executed by the first server for login authentication. This application also proposes another login method executed by the first client for login.

[0056] Figure 5 This is a flowchart illustrating the login method shown in the fifth embodiment of this disclosure.

[0057] It should be noted that, in this embodiment of the disclosure, the login method is configured in a login device as an example. The login device can be applied to a first client for login, so that the first client performs the login function.

[0058] like Figure 5 As shown, the login method may include the following steps: Step 510: In response to the login operation, a login request is sent to the first server used for login authentication.

[0059] The first login request is used by the first server to determine a list of accessible subsystems that match the login user identifier carried in the first login request, generate a login token for accessing at least one subsystem in the list of accessible subsystems, and send the login token and user attribute information associated with the login user identifier to the first client.

[0060] To achieve unified identity authentication and system access control for users across multiple system environments, one possible implementation involves the following approach: When a user initiates a login operation on a first client, a login request is sent to a first server used for unified authentication. Upon receiving the login request containing the user's identifier, the first server queries relevant permission data based on this identifier to determine all business subsystems the user is currently authorized to access and generates a list of accessible subsystems. The first client could be, for example, a mobile app or browser, and the user identifier could be, for example, an employee ID, email address, or a globally unique ID. Simultaneously, the first server issues a login token with time-limited validity, scope restrictions, and tamper-proof capabilities. This token is associated with the list of accessible subsystems and serves as credential for subsequent cross-system access. The first server then sends the login token and user attribute information containing the list of accessible subsystems to the first client. This user attribute information may include, but is not limited to, user ID, user name, organization, job title, a list of roles associated with that job title, global roles, employee type, and the list of accessible subsystems.

[0061] In some embodiments, such as Figure 6 As shown, step 510 may include: Step 5101: In response to the input operation of the login user identifier, send the login user identifier to the first server.

[0062] The login user identifier is used to request the corresponding login method.

[0063] To improve the security of login authentication, as one possible approach is to have the first server dynamically return a login method that matches the user's login identifier after the user enters the login identifier.

[0064] As an example, when a user enters a login user identifier in the interface of the first client and triggers a query operation, the first client sends the login user identifier to the first server used for login authentication. After receiving the login user identifier, the first server determines the login method that the user should use, such as password login, SMS verification code login, QR code login, etc., based on the preset security policy, user attributes, or historical behavior.

[0065] Step 5102: Receive the login method sent by the first server.

[0066] Furthermore, the first client receives the login method sent by the first server, and the first client can adjust the login interface elements according to the login method, such as displaying a password box, SMS input area or QR code.

[0067] Step 5103: In response to the login operation, generate a login request based on the login method and the login user identifier.

[0068] Next, after the user completes the input of the corresponding login method and triggers the login operation, the first client generates a login request based on the obtained login method and login user identifier. The content of the login request varies depending on the login method. For example, if the login method is password login, the login request includes the username and encrypted password; if the login method is SMS verification code login, the login request includes the verification code. Thus, by dynamically generating login requests according to the login method, it ensures that the authentication data accurately matches the verification logic, and flexibly supports multiple login authentication methods under a unified interface, significantly improving security, compatibility, and user experience.

[0069] Step 5104: Send a login request to the first server.

[0070] Next, the client sends the generated login request to the first server, which performs the final authentication to improve the security of login authentication.

[0071] Step 520: Receive the login token and user attribute information sent by the first server, and display the list of access subsystems carried by the user attribute information.

[0072] As one possible implementation, the first client receives the login token and user attribute information sent by the first server. The first client parses the list of accessible subsystems contained in the user attribute information and displays the subsystems in the list of accessible subsystems in the form of icons, menus or cards on the user interface for the user to select, so as to realize the intuitive presentation and interactive guidance of the systems available to the user.

[0073] Step 530: In response to the selection operation of the access subsystem list, the target subsystem is determined from at least one subsystem, and the login interface of the target subsystem is opened through the integration adapter of the target subsystem. In response to the authentication method of the target subsystem being token authentication, a login token and user permission information adapted to the target subsystem are sent to the second server of the target subsystem.

[0074] The login token is used by the second server of the target subsystem to generate a token verification request and send the token verification request to the first server to verify the login token in the token verification request, obtain the verification result, and send the verification result to the second server. The verification result is used to indicate that if the login token verification is successful, the login user's permissions and login information are determined according to the user permission information, so as to fill in the login information on the login interface to complete the login, and provide corresponding business processing services on the second client of the target subsystem according to the login user's permissions.

[0075] As one possible implementation, when a user clicks on a subsystem on the first client, the first client will identify the subsystem as the target subsystem and call the pre-set integration adapter corresponding to the target subsystem to open the login interface of the target subsystem. If the target subsystem supports token authentication instead of traditional account password authentication, the client will send the login token and user permission information adapted to the target subsystem to the second server of the target subsystem through the integration adapter. The second server is the backend service of the target subsystem itself.

[0076] As another possible implementation, in order to be compatible with subsystems that still use traditional authentication modes, when the integrated adapter identifies that the authentication mode of the target subsystem is password authentication, it retrieves the password information that matches the user identification information from the security credential storage; then, it automatically fills the password information and username and other information into the login interface of the target subsystem, thereby completing the automatic login of the login interface.

[0077] Furthermore, to enhance the security of cross-system authentication and prevent token forgery, the second server of the target subsystem, upon receiving user permission information and a login token, does not directly trust the validity of the login token. Instead, it initiates a token verification request to the first server of unified authentication. The first server verifies the login token in the token verification request, such as verifying the integrity, validity, scope, and revocation status of the login token, generates a verification result, and returns the verification result to the second server.

[0078] Furthermore, when the verification result confirms the token's validity, the second server determines the user's specific permission scope and login information within the system based on the user's permission information. Subsequently, the system automatically fills in the login information in the login interface, eliminating the need for the user to re-enter credentials, and determines the accessible functional modules and data range based on the logged-in user's permissions, providing personalized business services in the second client. The login information may include, but is not limited to, username and display name.

[0079] In order to achieve seamless redirection for login to heterogeneous subsystems, when the first client opens the login interface of the target subsystem through the integration adapter of the target subsystem, it can obtain the integration configuration of the target subsystem through the integration adapter of the target subsystem and determine the login interface address of the target subsystem according to the integration configuration. Based on the login interface address, the browser page is automatically redirected or embedded in the current interface of the first client, thereby opening the login interface of the target subsystem.

[0080] Based on any of the above embodiments, the login method of this disclosure may further include the following steps: Step 1: Build a unified login system for storing, maintaining, and managing user information and authenticating user logins. In this embodiment of the disclosure, a unified login system is used to store, maintain, and manage user information and for user login authentication; such as Figure 7 As shown, the unified login system may include the following modules: Organizational structure management: Maintaining information about organizational structure and departments; User Management: Maintaining basic user information, affiliated organization, affiliated position, assigned user role, login medium information, etc., and also responsible for user login authentication; Job Management: Maintain job information within the system; Role management: Maintains role information within the system, as well as information on subsystems accessible to each role; Subsystem Management: Maintain integrated subsystem information, including system description, access path, integration method, permission data mapping, extended data, etc. See step 2 for details; Subsystem adaptation: Used for adaptation and connection with subsystems, see step 3 for details.

[0081] This solution employs a two-tier access control system. After a user logs in to the unified login system, such as... Figure 8 As shown, the system only displays a list of subsystems that the current user can access. Users can enter by selecting the corresponding subsystem. Resource management and access control within each subsystem are maintained by the respective subsystem.

[0082] Step 2: Construct a subsystem management module to maintain subsystem information. Subsystem information includes the following: Subsystem ID: A globally unique identifier that serves as the primary key for all associated configurations. Subsystem Description: A concise and accurate business description used to display in the subsystem selection card or list to help users quickly identify the subsystem; Subsystem icons: Subsystem icon information, image format, used for display in the subsystem selection interface; Subsystem access URL: Subsystem access path; Subsystem login URL: The access path for the subsystem login interface; Subsystem Login Extended Parameters: Extended parameter configuration. This data is used in the subsystem adaptation layer and can be customized as needed, such as user information mapping, job information mapping, role information mapping, etc.

[0083] Subsystem logout URL: The access path for the subsystem user logout interface.

[0084] Subsystem sign-out extended parameters: Extended parameter configuration. This data is used in the subsystem adaptation layer and can be arbitrarily defined with the required customized parameters.

[0085] Step 3: Integrate the subsystems and associate permission data. like Figure 9 As shown, the unified login system integrates subsystems through an adaptation layer, customizing integration code for each subsystem. It supports diverse integration methods, including traditional token verification and password auto-fill. For permission association within subsystems, it supports association by user ID as well as by other information such as job title or role. I. System Integration Method: (1) Token verification method integration subsystem; Integrating subsystems via token verification is the primary integration method, suitable for situations where the subsystem can be modified to a certain extent. This integration method requires modifications in two aspects. Add the corresponding subsystem integration adapter to the unified login system, and add the corresponding subsystem configuration information; The subsystem needs to extend the check-in logic within the system to support token verification; The specific implementation process is as follows: After a user logs in to the unified login system, the system will display a list of subsystems and generate a token. When the user selects a subsystem, the unified login system will open the subsystem interface and send the token to the subsystem. After receiving the token, the subsystem will call the token verification interface of the unified login system. If the token verification is successful, the subsystem login is complete. (2) Password filling method integrated subsystem The password filling method is mainly used when no modifications can be made. This integration method only requires adding the corresponding subsystem integration adapter to the unified login system, adding the corresponding subsystem configuration information, and configuring user mapping and user passwords in the subsystem login extended parameters. The specific implementation process is as follows: After a user logs in to the unified login system, the system will display a list of subsystems. When the user selects a subsystem, the unified login system will open the subsystem login interface, query the subsystem user information mapped to the currently logged-in user, and input the subsystem user information into the login interface to complete the auto-fill and login. II. Permission Data Association Access control data association refers to how to determine the permissions of a user logged into a subsystem when entering the subsystem. Traditional unified login systems typically use user IDs for association, which requires ensuring user consistency and necessitates synchronizing basic user information across all subsystems. This solution supports association via user IDs, but also allows association via roles or positions, eliminating the need for user information synchronization and reducing the workload of system integration. Meanwhile, when permission information is associated with roles or positions, if a user's position or role changes, resulting in adjustments to the user's permissions, the unified login system in this solution can transmit these changes to each subsystem through the subsystem integration adapter, thereby achieving automatic adaptation and adjustment of user permission changes in the subsystems. (1) Associate permission data by user ID Linking permission data using user ID is suitable for situations where user information in a subsystem is synchronized with the unified login system. Implementation process: When a user logs in to the unified login system and selects a subsystem, the unified login system will send the current user ID to the subsystem. The operation permissions in the subsystem are the permissions corresponding to that user ID. (2) Associate permission data through roles Associating permission data with roles is suitable for situations where resource permissions are bound to user roles within a subsystem. Implementation process: When a user logs in to the unified login system, the system will query the user's corresponding role list. When a user selects a subsystem, the unified login system will convert the role information according to the role mapping table defined in the subsystem's login extended parameters (if it exists, it will be mapped; otherwise, the original role list will be saved). The system will then pass the user's basic information and the converted role list to the subsystem. At this point, the subsystem no longer uses its internal user information but instead uses the user information passed by the unified login system, and its permissions are matched according to the role list passed by the unified login system. (3) Linking permission data through job information Linking permission data using job information is suitable for situations where resource permissions are bound to user jobs in a subsystem. Implementation process: When a user logs in to the unified login system, the system will query the user's corresponding job information. When a user selects a subsystem, the unified login system will convert the job information according to the job information mapping table defined in the subsystem's login extended parameters (if it exists, it will be mapped; otherwise, the original job information will be saved). The system will then pass the user's basic information and the converted job information to the subsystem. At this point, the subsystem no longer uses its internal user information but instead uses the user information passed by the unified login system, and its permissions are matched according to the job information passed by the unified login system. III. Automated Adaptation and Adjustment of Permissions When permission information is associated with roles or positions, if a user's position or role changes, resulting in adjustments to user permissions, the unified login system in this solution can transmit these changes to each subsystem through a subsystem integration adapter, achieving automated adaptation and adjustment of user permission changes within the subsystems. Users only need to modify the user's corresponding role or position information in the unified login system as needed and then log in again to the corresponding subsystem. Unlike traditional unified login systems, which require modifying the user's corresponding permission information in each subsystem, this solution simplifies the process. Taking a change in user position as an example, the execution process is as follows: Figure 10 As shown.

[0086] Step 4: Implement a unified login process like Figure 11 As shown, the specific process for implementing unified login in this solution is as follows (taking token verification as an example): (1) When a user accesses the same login system client and performs a login operation, the system will verify the user's login information, login status, off-duty (vacation) status, query the subsystem information that the user can access, generate a login token, and return the token and user information to the client. The user information should include the user ID, name, affiliated organization, affiliated position, a list of roles associated with the affiliated position, a list of accessible subsystems, etc. (2) The same login client displays a list of subsystems that the current user can access; (3) When a user selects a subsystem, the same login system calls the system integration adapter corresponding to that subsystem, opens the subsystem page, calls the subsystem login logic, and sends the user information and token to the subsystem. (4) After receiving the token, the subsystem calls the interface of the unified login system to verify the token's validity. After the verification is successful, the system's permissions are processed, and the login information within the subsystem is generated. At this point, the subsystem login is complete, and the user can conduct business normally in the subsystem.

[0087] With the above Figures 1 to 4 Corresponding to the login method provided in the embodiments, this disclosure also provides a login device. Since the login device provided in the embodiments of this disclosure corresponds to the login method provided in the above embodiments, the implementation method of the login method is also applicable to the login device provided in the embodiments of this disclosure, and will not be described in detail in the embodiments of this disclosure.

[0088] Figure 12 This is a schematic diagram of the login device shown in the seventh embodiment of this disclosure. It should be noted that the login device of this embodiment can be applied to a first server used for login authentication.

[0089] like Figure 12 As shown, the login device 1200 includes: a generation module 1210, a sending module 1220, and a receiving module 1230.

[0090] The generation module 1210 is configured to, in response to receiving a login request from a first client for login, determine a list of accessible subsystems matching the login user identifier carried in the first login request, and generate a login token for accessing at least one subsystem in the list of accessible subsystems; the sending module 1220 is configured to send the login token and user attribute information associated with the login user identifier to the first client, so as to display the list of accessible subsystems carried in the user attribute information to the first client; wherein the list of accessible subsystems is used by the first client in response to a selection operation to determine a target subsystem from at least one subsystem, and to open the target subsystem through the integration adapter of the target subsystem. The login interface, and in response to the target subsystem's authentication method of token authentication, sends a login token and user permission information adapted to the target subsystem to the second server of the target subsystem; the receiving module 1230 is used to receive the token verification request sent by the second server of the target subsystem, verify the login token in the token verification request to obtain the verification result, and send the verification result to the second server; wherein, the verification result is used to indicate that if the login token verification is successful, the login user's permissions and login information are determined according to the user permission information, so as to fill in the login information on the login interface to complete the login, and provide corresponding business processing services on the second client of the target subsystem according to the login user's permissions.

[0091] As one possible implementation, user permission information is generated using the following modules: acquisition module, filtering module, and conversion module.

[0092] The module includes an acquisition module for acquiring permission mapping information of the target subsystem; a filtering module for filtering a subset of user attributes associated with the target subsystem from the user attribute information based on the permission mapping information; and a conversion module for converting the subset of user attributes based on the permission mapping information to obtain user permission information that is compatible with the target subsystem.

[0093] As one possible implementation, the conversion module is used to convert global roles in the user attribute subset into local roles supported by the target subsystem according to the role mapping rules in the permission configuration information; to convert organizational positions in the user attribute subset into position identifiers recognized by the target subsystem according to the position mapping rules in the permission configuration information; and to convert global user identifiers in the user attribute subset into local user identifiers required by the target subsystem according to the identifier mapping rules in the permission configuration information. User permission information is generated based on at least one of the local roles, position identifiers, and local user identifiers.

[0094] As one possible implementation, the login device also includes an update module.

[0095] The update module is used to compare user permission information with the permission configuration information of the target subsystem to determine whether the user permission information is consistent with the permission configuration information; in response to the inconsistency between the user permission information and the permission configuration information, the user permission information is updated using the permission configuration information.

[0096] As one possible implementation, the generation module 1210 is used to, in response to receiving a login request sent by a first client for login, query and verify login access information that matches the login user identifier based on the login user identifier; and in response to the login access information passing the verification, query the list of accessible subsystems that match the login user identifier.

[0097] The login method of this embodiment, when the first server receives a login request from the first client, determines the list of accessible subsystems based on the login user identifier, dynamically generates a login token containing the list of accessible subsystems, and sends the token along with global user attribute information to the first client, enabling the client to intuitively display the business systems the user is authorized to access. When the user selects a target subsystem, the system automatically opens the login interface of the target subsystem through a pre-set integration adapter. If the target subsystem uses token authentication mode, the system sends user permission information adapted to the target subsystem to the second server of that target subsystem. The second server of the target subsystem then proactively initiates a token verification request to the first server. This verifies the token's validity while determining the login user's permissions and login information based on the user permission information, automatically filling in the login information to complete authentication, and providing corresponding business processing services in the second client. This avoids the user repeatedly entering account passwords in multiple heterogeneous systems, eliminating security risks caused by password reuse or weak password policies. Simultaneously, user data is centrally managed by the first server, eliminating the need for manual maintenance in each subsystem, significantly improving the efficiency and accuracy of permission synchronization during organizational structure changes.

[0098] With the above Figure 5 Corresponding to the login method provided in the embodiments, this disclosure also provides a login device. Since the login device provided in the embodiments of this disclosure corresponds to the login method provided in the above embodiments, the implementation method of the login method is also applicable to the login device provided in the embodiments of this disclosure, and will not be described in detail in the embodiments of this disclosure.

[0099] Figure 13 This is a schematic diagram of the login device shown in the eighth embodiment of this disclosure. It should be noted that the login device of this embodiment can be applied to a first client for login.

[0100] like Figure 13 As shown, the login device 1300 includes: a first sending module 1310, a receiving module 1320, and a selection module 1330.

[0101] The first sending module 1310 is used to send a login request to a first server for login authentication in response to a login operation. The first login request is used by the first server to determine a list of accessible subsystems matching the login user identifier carried in the first login request, generate a login token for accessing at least one subsystem in the list, and send the login token and user attribute information associated with the login user identifier to the first client. The receiving module 1320 is used to receive the login token and user attribute information sent by the first server and display the list of accessible subsystems carried in the user attribute information. The selection module 1330 is used to determine a target subsystem from at least one subsystem in response to a selection operation on the list of accessible subsystems, and then... The integration adapter of the target subsystem opens the login interface of the target subsystem and, in response to the target subsystem's authentication method being token authentication, sends a login token and user permission information adapted to the target subsystem to the second server of the target subsystem. The login token is used by the second server of the target subsystem to generate a token verification request and send it to the first server to verify the login token in the token verification request, obtain the verification result, and send the verification result to the second server. The verification result is used to indicate, if the login token verification passes, the login user's permissions and login information are determined based on the user permission information, so that the login information is filled in on the login interface to complete the login, and corresponding business processing services are provided on the second client of the target subsystem according to the login user's permissions.

[0102] As one possible implementation, the first sending module 1310 is used to send the login user identifier to the first server in response to the input operation of the login user identifier; wherein, the login user identifier is used to request the corresponding login method; receive the login method sent by the first server; in response to the login operation, generate a login request based on the login method and the login user identifier; and send the login request to the first server.

[0103] As one possible implementation, module 1330 is selected to obtain the integration configuration of the target subsystem through the integration adapter of the target subsystem, and determine the login interface address of the target subsystem based on the integration configuration; based on the login interface address, page redirection or embedded loading is triggered to open the login interface of the target subsystem.

[0104] As one possible implementation, the selection module 1330 is also used to determine that the authentication method of the target subsystem is password authentication through the integration adapter, and to query the password information that matches the user identification information; wherein, the password information is used to fill the login interface to complete the login.

[0105] The login method of this embodiment, when the first server receives a login request from the first client, determines the list of accessible subsystems based on the login user identifier, dynamically generates a login token containing the list of accessible subsystems, and sends the token along with global user attribute information to the first client, enabling the client to intuitively display the business systems the user is authorized to access. When the user selects a target subsystem, the system automatically opens the login interface of the target subsystem through a pre-set integration adapter. If the target subsystem uses token authentication mode, the system sends user permission information adapted to the target subsystem to the second server of that target subsystem. The second server of the target subsystem then proactively initiates a token verification request to the first server. This verifies the token's validity while determining the login user's permissions and login information based on the user permission information, automatically filling in the login information to complete authentication, and providing corresponding business processing services in the second client. This avoids the user repeatedly entering account passwords in multiple heterogeneous systems, eliminating security risks caused by password reuse or weak password policies. Simultaneously, user data is centrally managed by the first server, eliminating the need for manual maintenance in each subsystem, significantly improving the efficiency and accuracy of permission synchronization during organizational structure changes.

[0106] In an exemplary embodiment, an electronic device is also proposed.

[0107] The electronic devices include: processor; Memory used to store processor-executable instructions; The processor is configured to execute instructions to implement the login method as proposed in any of the foregoing embodiments.

[0108] As an example, Figure 14 This is a schematic diagram of the structure of an electronic device 1400 as shown in an exemplary embodiment of this disclosure, as follows: Figure 14 As shown, the above-mentioned electronic device 1400 may further include: The memory 1410 and the processor 1420 are connected by a bus 1430, which connects the different components (including the memory 1410 and the processor 1420). The memory 1410 stores a computer program, which implements the login method described in this embodiment when the processor 1420 executes the program.

[0109] Bus 1430 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0110] Electronic device 1400 typically includes a variety of electronic device readable media. These media can be any available media that can be accessed by electronic device 1400, including volatile and non-volatile media, removable and non-removable media.

[0111] Memory 1410 may also include computer system readable media in the form of volatile memory, such as random access memory (RAM) 1440 and / or cache memory 1450. Electronic device 1400 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 1460 may be used to read and write non-removable, non-volatile magnetic media (… Figure 14 Not shown; usually referred to as a "hard drive"). Although Figure 14 As not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 1430 via one or more data media interfaces. Memory 1410 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of this disclosure.

[0112] A program / utility 1480 having a set (at least one) of program modules 1470 may be stored, for example, in memory 1410. Such program modules 1470 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 1470 typically perform the functions and / or methods described in the embodiments of this disclosure.

[0113] Electronic device 1400 can also communicate with one or more external devices 1490 (e.g., keyboard, pointing device, display 1491, etc.), and with one or more devices that enable a user to interact with electronic device 1400, and / or with any device that enables electronic device 1400 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed via input / output (I / O) interface 1492. Furthermore, electronic device 1400 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 1493. As shown, network adapter 1493 communicates with other modules of electronic device 1400 via bus 1430. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 1400, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0114] The processor 1420 performs various functional applications and data processing by running programs stored in the memory 1410.

[0115] It should be noted that the implementation process and technical principles of the electronic device in this embodiment are explained in the foregoing description of the login method of this disclosure embodiment, and will not be repeated here.

[0116] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, such as a memory including instructions, which can be executed by a processor of an electronic device to complete the login method proposed in any of the above embodiments. Optionally, the computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0117] In an exemplary embodiment, a computer program product is also provided, including a computer program / instructions, characterized in that the computer program / instructions, when executed by a processor, implement the login method proposed in any of the above embodiments.

[0118] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

[0119] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A login method, characterized in that, The first server used for login authentication includes: In response to receiving a login request from a first client for login, the system determines a list of accessible subsystems that match the login user identifier carried in the first login request, and generates a login token for accessing at least one subsystem in the list of accessible subsystems. The login token and user attribute information associated with the login user identifier are sent to the first client to display a list of access subsystems carried by the user attribute information on the first client; wherein, the list of access subsystems is used by the first client to determine a target subsystem from the at least one subsystem in response to a selection operation, open the login interface of the target subsystem through the integration adapter of the target subsystem, and send the login token and user permission information adapted to the target subsystem to the second server of the target subsystem in response to the authentication method of the target subsystem being token authentication; The system receives a token verification request from the second server of the target subsystem, verifies the login token in the token verification request to obtain a verification result, and sends the verification result to the second server. The verification result is used to indicate that if the login token verification is successful, the system determines the login user's permissions and login information based on the user permission information, fills in the login information on the login interface to complete the login, and provides corresponding business processing services to the second client of the target subsystem based on the login user's permissions.

2. The method according to claim 1, characterized in that, The user permission information is determined using the following steps: Obtain the permission mapping information of the target subsystem; Based on the permission mapping information, a subset of user attributes associated with the target subsystem is selected from the user attribute information; Based on the permission mapping information, the subset of user attributes is transformed to obtain user permission information that is compatible with the target subsystem.

3. The method according to claim 2, characterized in that, The step of transforming the subset of user attributes according to the permission mapping information to obtain user permission information adapted to the target subsystem includes: Based on the role mapping rules in the permission configuration information, the global roles in the user attribute subset are converted into local roles supported by the target subsystem; Based on the job mapping rules in the permission configuration information, the organizational jobs in the user attribute subset are converted into job identifiers that are recognized by the target subsystem; Based on the identifier mapping rules in the permission configuration information, the global user identifier in the user attribute subset is converted into the local user identifier required by the target subsystem; The user permission information is generated based on at least one of the local role, the job identifier, and the local user identifier.

4. The method according to claim 3, characterized in that, The method further includes: The user permission information is compared with the permission configuration information of the target subsystem to determine whether the user permission information is consistent with the permission configuration information. In response to the inconsistency between the user permission information and the permission configuration information, the user permission information is updated using the permission configuration information.

5. The method according to claim 1, characterized in that, In response to receiving a login request from a first client, the method of determining a list of accessible subsystems matching the login user identifier carried in the first login request includes: In response to receiving a login request from a first client for login, the system queries and verifies login access information that matches the login user identifier based on the login user identifier. In response to the login access information being verified, a list of accessible subsystems matching the login user identifier is queried.

6. A login method, characterized in that, Applied to the first client used for login, including: In response to a login operation, a login request is sent to a first server for login authentication; wherein, the first login request is used by the first server to determine a list of accessible subsystems that match the login user identifier carried in the first login request, generate a login token for accessing at least one subsystem in the list of accessible subsystems, and send the login token and user attribute information associated with the login user identifier to the first client. Receive the login token and user attribute information sent by the first server, and display the list of access subsystems carried by the user attribute information; In response to the selection operation of the access subsystem list, a target subsystem is determined from the at least one subsystem, and the login interface of the target subsystem is opened through the integration adapter of the target subsystem. In response to the authentication method of the target subsystem being token authentication, the login token and user permission information adapted to the target subsystem are sent to the second server of the target subsystem. The login token is used by the second server of the target subsystem to generate a token verification request and send the token verification request to the first server to verify the login token in the token verification request, obtain a verification result, and send the verification result to the second server. The verification result is used to indicate that if the login token verification is successful, the login user permissions and login information are determined according to the user permission information, so as to fill in the login information on the login interface to complete the login, and provide corresponding business processing services on the second client of the target subsystem according to the login user permissions.

7. The method according to claim 5, characterized in that, The step of responding to a login operation by sending a login request to a first server used for login authentication includes: In response to an input operation of a login user identifier, the login user identifier is sent to the first server; wherein, the login user identifier is used to request the corresponding login method; Receive the login method sent by the first server; In response to a login operation, a login request is generated based on the login method and the login user identifier; Send the login request to the first server.

8. The method according to claim 6, characterized in that, The step of opening the login interface of the target subsystem through the integration adapter of the target subsystem includes: The integration configuration of the target subsystem is obtained through the integration adapter of the target subsystem, and the login interface address of the target subsystem is determined according to the integration configuration. Based on the login interface address, a page redirect or embedded loading is triggered to open the login interface of the target subsystem.

9. The method according to any one of claims 6-8, characterized in that, The method further includes: The integrated adapter determines that the authentication method of the target subsystem is password authentication, and queries the password information that matches the user identification information; wherein, the password information is used to fill in the login interface to complete the login.

10. A login device, characterized in that, The first server used for login authentication includes: The generation module is configured to, in response to receiving a login request from a first client for login, determine a list of accessible subsystems that match the login user identifier carried in the first login request, and generate a login token for accessing at least one subsystem in the list of accessible subsystems. The sending module is configured to send the login token and user attribute information associated with the login user identifier to the first client, so as to display the access subsystem list carried by the user attribute information on the first client; wherein, the access subsystem list is used by the first client to determine the target subsystem from the at least one subsystem in response to a selection operation, and to open the login interface of the target subsystem through the integration adapter of the target subsystem, and to send the login token and user permission information adapted to the target subsystem to the second server of the target subsystem in response to the authentication method of the target subsystem being token authentication; The receiving module is configured to receive a token verification request sent by the second server of the target subsystem, verify the login token in the token verification request to obtain a verification result, and send the verification result to the second server; wherein, the verification result is used to indicate that if the login token verification is successful, the login user permissions and login information are determined according to the user permission information, so as to fill in the login information on the login interface to complete the login, and provide corresponding business processing services on the second client of the target subsystem according to the login user permissions.

Images