Login method and apparatus, and electronic device and storage medium

Abstract

The present disclosure is applied to the technical field of the Internet, and particularly relates to the technical field of login. Provided is a login method. The method is applied to a target application, which comprises a login entry for at least one identity source, wherein the identity source represents an application, which can be logged in to, other than the target application. The method comprises: in response to a user selecting a login entry for a target identity source from among at least one identity source, acquiring preset configuration information for the target identity source; on the basis of the preset configuration information, executing a login authentication procedure corresponding to a login mode of the target identity source, wherein the target identity source authenticates login information of the user to obtain first user information; and in response to the first user information from the target identity source, determining a target application account of the user for a target application. Further provided in the present disclosure are a login apparatus, an electronic device, and a storage medium.

Description

Login methods, devices, electronic devices and storage media Technical Field

[0001] This disclosure relates to the field of Internet technology, particularly to the field of login technology, and more specifically, to a login method, apparatus, electronic device, medium, and program product. Background Technology

[0002] Login is the starting point for system authentication and authorization. Only after a user logs in can various services be provided based on their authentication information. With the development of software technology, numerous internet and enterprise applications have emerged. Users of these systems need to remember their account passwords, which undoubtedly creates a significant burden. To solve this problem, third-party login is generally adopted, utilizing login protocols such as OAuth2 or OIDC to achieve third-party social login. However, using third-party login requires developing a separate login process for each login protocol, making it difficult to reuse existing processes. Summary of the Invention

[0003] In view of the above problems, this disclosure provides a login method, apparatus, electronic device, medium, and program product.

[0004] According to one aspect of this disclosure, a login method is provided, applied to a target application, wherein the target application includes a login entry point for at least one identity source, the identity source representing a loginable application other than the target application; the method includes:

[0005] In response to a user selecting a login entry for a target identity source from at least one identity source, obtain preset configuration information for the target identity source;

[0006] The login authentication process corresponding to the login method of the target identity source is executed according to the preset configuration information, wherein the target identity source authenticates the user's login information to obtain the first user information;

[0007] In response to the first user information from the target identity source, determine the user's target application account for the target application, and use the target application account to log in to the target application.

[0008] According to another aspect of this disclosure, a login device is provided for a target application, wherein the target application includes a login entry point for at least one identity source, the identity source representing a loginable application other than the target application; the device includes:

[0009] The acquisition module is used to obtain preset configuration information for the target identity source in response to the user selecting the login entry of at least one identity source.

[0010] The execution module is used to execute the login authentication process corresponding to the login method of the target identity source according to the preset configuration information, wherein the target identity source authenticates the user's login information to obtain the first user information;

[0011] The determination module is used to determine the user's target application account for the target application in response to the first user information from the target identity source, so as to log in to the target application using the target application account.

[0012] According to another aspect of this disclosure, an electronic device is provided, comprising:

[0013] One or more processors;

[0014] Memory, used to store one or more computer programs.

[0015] In this process, one or more processors execute one or more computer programs to implement the steps of the above method.

[0016] According to another aspect of this disclosure, a computer-readable storage medium is provided that stores a computer program or instructions thereon, wherein the computer program or instructions, when executed by a processor, implement the steps of the above-described method.

[0017] According to another aspect of this disclosure, a computer program product is provided, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method.

[0018] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0019] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0020] Figure 1 is a schematic diagram of a login interface for a target application according to an embodiment of the present disclosure;

[0021] Figure 2 is a flowchart of a login method according to an embodiment of the present disclosure;

[0022] Figure 3 is a schematic diagram of a configuration template for OIDC protocol login according to an embodiment of this disclosure;

[0023] Figure 4 is a flowchart of the login authentication process for OAuth protocol login according to an embodiment of this disclosure;

[0024] Figure 5 is a login authentication flowchart for OIDC protocol login according to an embodiment of this disclosure;

[0025] Figure 6 is a login authentication flowchart for SAML protocol login according to an embodiment of this disclosure;

[0026] Figure 7 is a login authentication flowchart for LDAP protocol login according to an embodiment of the present disclosure;

[0027] Figure 8 is a login authentication flowchart for protocol login based on form filling according to an embodiment of this disclosure;

[0028] Figure 9 is a schematic diagram of a target application account determination method according to an embodiment of the present disclosure;

[0029] Figure 10 is a flowchart of establishing association relationships using a manual association method according to an embodiment of the present disclosure;

[0030] Figure 11 is a schematic diagram of an account association interface according to an embodiment of the present disclosure;

[0031] Figure 12 is a flowchart of establishing association relationships using an automatic association method according to an embodiment of the present disclosure;

[0032] Figure 13 is a schematic diagram of processing registration information using a registration strategy according to an embodiment of the present disclosure;

[0033] Figure 14 is a flowchart of a local login method according to an embodiment of the present disclosure;

[0034] Figure 15 is a flowchart of a login method according to another embodiment of the present disclosure;

[0035] Figure 16 is a schematic diagram of a login method according to an embodiment of the present disclosure;

[0036] Figure 17 is a block diagram of a login device according to an embodiment of the present disclosure; and

[0037] Figure 18 is a block diagram of an electronic device suitable for implementing the methods described above, according to an embodiment of the present disclosure. Detailed Implementation

[0038] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this disclosure. Based on the described embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure. It should be noted that throughout the accompanying drawings, the same elements are represented by the same or similar reference numerals. In the following description, some specific embodiments are used for descriptive purposes only and should not be construed as limiting this disclosure in any way, but are merely examples of embodiments of this disclosure. Conventional structures or configurations will be omitted where they may cause confusion in understanding this disclosure. It should be noted that the shapes and dimensions of the components in the figures do not reflect actual size and proportion, but are only schematic representations of the embodiments of this disclosure.

[0039] Unless otherwise defined, the technical or scientific terms used in the embodiments of this disclosure shall have the ordinary meaning as understood by those skilled in the art. The terms "first," "second," and similar terms used in the embodiments of this disclosure do not indicate any order, quantity, or importance, but are merely used to distinguish different components.

[0040] In the embodiments disclosed herein, the collection, updating, analysis, processing, use, transmission, provision, disclosure, and storage of data (e.g., including but not limited to user personal information) comply with relevant laws and regulations, are used for legitimate purposes, and do not violate public order and good morals. In particular, necessary measures have been taken to prevent unauthorized access to user personal information data and to safeguard user personal information security, network security, and national security.

[0041] In the embodiments disclosed herein, user authorization or consent is obtained before acquiring or collecting user personal information.

[0042] Login is the starting point for system authentication and authorization. Only after a user logs in can the system provide services such as "checking my orders" and "creating my device" based on the authentication information. With the development of software technology, a large number of internet and enterprise applications have emerged. Users of these systems need to remember their account passwords, which undoubtedly creates a significant burden. Internet applications offer a solution: third-party login. This utilizes OAuth2 or OIDC protocols to implement third-party social login. For example, a website, such as website A, can be designed and developed according to the OAuth2 protocol provided by a third party. A third-party login button can be generated on website A's login page. When a user clicks this button, they are redirected to a special login page provided by the third party. They enter their third-party account and password or scan a QR code using a third-party mobile app. Finally, the system returns to website A with some authentication information. Website A recognizes the authentication information carried by the third party and allows the user to log in.

[0043] It should be noted that because different third-party logins use different login protocols, a separate login authentication process needs to be developed for each different login protocol, making it difficult to reuse existing processes.

[0044] To address the aforementioned technical issues, this disclosure provides a login method that abstracts identity sources outside its own user system into identity sources and configures corresponding parameters for different login methods (such as protocol login and form-filled login). Based on these parameters, the identity source verifies the user's identity. After the identity source verifies the user's identity, all login methods can use the same process, eliminating the need to develop a complete process for each login protocol and achieving partial process reuse.

[0045] The login method of this disclosure can be applied to a target application, which can be an application for which login is desired. The target application includes a login entry point for at least one identity source, which can be a loginable application other than the target application.

[0046] For example, if the target application can be application 1, then the identity source can be any loginable application other than application 1, such as application 2, application 3, etc.

[0047] It should be noted that the target application can be considered as a local identity source.

[0048] Figure 1 is a schematic diagram of a login interface for a target application according to an embodiment of the present disclosure.

[0049] As shown in Figure 1, the login interface of the target application includes login entry points for three identity sources, such as Application 1, Application 2, and Application 3. When logging into the target application on this login interface, users can enter their account and password for the target application in the input box, or enter their mobile phone number to log in locally via SMS verification code; additionally, users can click on any of Application 1, Application 2, or Application 3 to log in via a third-party platform. When a user clicks on any of Application 1, Application 2, or Application 3, the login method provided in this disclosure can be executed.

[0050] Figure 2 is a flowchart of a login method according to an embodiment of the present disclosure.

[0051] As shown in Figure 2, the login method of this embodiment 200 includes operations S210 to S230.

[0052] In operation S210, in response to the user selecting the login entry of the target identity source from at least one identity source, the system obtains the preset configuration information for the target identity source.

[0053] During operation S220, a login authentication process corresponding to the login method of the target identity source is executed according to the preset configuration information. The target identity source authenticates the user's login information to obtain the first user information.

[0054] The first user information can be the user information stored in the target identity source.

[0055] In operation S230, in response to the first user information from the target identity source, the user's target application account for the target application is determined, so as to log in to the target application using the target application account.

[0056] The user acknowledges and agrees to the acquisition and use of the first user information, and all such acquisitions and uses comply with relevant laws and regulations and do not violate public order and good morals.

[0057] The target identity source can be one of at least one identity source. For example, if a user selects the login entry for application 1 in Figure 1, application 1 can be identified as the target identity source, and preset configuration information for application 1 can be obtained.

[0058] The preset configuration information may include target login parameters, which represent the parameters required for the login method of the target identity source.

[0059] Executing a login authentication process corresponding to the login method of the target identity source based on preset configuration information may include: executing a login authentication process corresponding to the login method of the target identity source based on the target login parameters.

[0060] The preset configuration information can be pre-configured using a target configuration template for the target identity source. The target configuration template can include identity source parameters to be configured for the identity source and login parameters to be configured for the login method. The target login parameters can be the parameter information corresponding to the login parameters to be configured that were entered in the configuration template above.

[0061] The configurable identity source parameters can be general parameters, such as at least one of the following: identity source name, identity source icon, identity source description, whether to enable, redirect address, identity source account mapping field, user information mapping field, and target application account registration strategy. The "enable" parameter controls the activation and deactivation of the identity source; when disabled, the identity source ceases to function, for example, by uniformly suspending third-party logins. The "redirect address" parameter is used for certain identity sources that, after completing the authentication process, require redirection to a specific frontend address. This address often has special logic, and the backend carries the generated token during redirection. The "identity source account mapping field" parameter is used to return the user's information on the target identity source after successful login. Based on this information, a unique identifier for the user on the target identity source is determined and mapped for subsequent checks to determine if the user has previously logged in using that target identity source. The "User Information Mapping Field" parameter, which is to be configured for the user's information at the target identity source, may need to be mapped to the target application as basic account information. Allowed mapping fields include: username, name, email, and phone number. Mapping supports multi-level JSON retrieval and basic string processing. The "Target Application Account Registration Policy" parameter, which is to be configured for the target identity source, determines the account association method after successful login using the target identity source. This includes whether automatic or manual association is used, whether automatic association is based on username or direct account creation, and the basic account information to be considered when registering a new account, such as username, name, phone number, email, role, organization, account type, account level, and account validity period. These are determined by the configured registration policy.

[0062] The login parameters to be configured vary depending on the login method.

[0063] For example, login methods may include: OAuth protocol login, OIDC protocol login, Security Assertion Markup Language protocol login, Lightweight Directory Access Protocol login, or form-filling login.

[0064] The login parameters to be configured for OAuth protocol login may include: client identifier, client password, redirect address, user interface call address, and authorization code interface call address.

[0065] OAuth is an open standard that allows users to grant third-party applications access to resources stored by a user on a website. OAuth2 is a mainstream social login protocol, supporting four authorization modes: username / password, client-side, authorization code, and simplified. Due to its higher security, authorization code is generally used for social login. The OAuth2 login protocol in this embodiment can use the authorization code mode.

[0066] It's important to note that the client identifier and client password in the login parameters to be configured for OAuth protocol login need to be granted OAuth2 access by applying to an IDP (identity provider). Upon successful application, the IDP will assign a client ID and client secret, which will serve as credentials for the service provider (SP) in the OAuth2 authorization code mode interaction. The IDP can be the identity source, and the SP can be the target application. The redirect address is the callback address filled in when applying for OAuth2 access from the IDP, ensuring successful redirection after login. The authorization code interface call address is provided by the IDP and is used to call the IDP's authorization code interface during the login authentication process. The user interface call address is also provided by the IDP and is used to call the IDP's user interface during the login authentication process.

[0067] The login parameters to be configured for OIDC protocol login may include: authorization code interface call address, client identifier, client password, and redirection address.

[0068] OIDC (Open ID Connect) is an authentication protocol that extends the OAuth2 protocol. Its main components include the basic framework of OAuth2 plus a unique user workflow. The OIDC protocol allows the client service (SP) to verify the user's identity using the client ID and client secret. Since OIDC evolved from the OAuth2 protocol, the application process required by OAuth2 also involves requesting and allocating client IDs and client secrets from the IDP. The authorization code API call address and redirect address in the login parameters to be configured for OIDC protocol login have the same meaning as those in OAuth protocol login, and will not be elaborated further here.

[0069] The login parameters to be configured for the Secure Assertion Markup Language protocol login may include: identity source name, user interface call address, and signature information.

[0070] SAML (Security Assertion Markup Language) is an XML-based open-source standard data format used for exchanging authentication and authorization data between Identity Providers (IDPs) and Service Providers (SPs). SAML is commonly used for web-based Single Sign-On (SSO). The SAML protocol requires prior approval from the IDP, and SAML then distributes keys.

[0071] It should be noted that the user interface call address in the login parameters to be configured for the Security Assertion Markup Language protocol login has the same meaning as the user interface call address mentioned above, and will not be repeated here. The signature information may include the signature method and the key allocated by SAML, so that the signature can be encrypted using the key allocated by SAML, facilitating IDP authentication.

[0072] The login parameters to be configured for Lightweight Directory Access Protocol (DLAP) login may include: protocol address, user directory location, administrator's directory location, administrator's password, and search criteria.

[0073] LDAP (Lightweight Directory Access Protocol) uses a descriptive language for definition. For example, an LDAP search described in this language might be: "Search the company mailing directory for all individuals with email addresses whose company name contains '××'. Please return their email addresses." A common use of LDAP is single sign-on, allowing users to use the same password across multiple services. It's typically used for logging into company intranets, enabling users to log in once on a company computer and automatically log in again on the intranet.

[0074] It should be noted that the user directory location in the login parameters to be configured for Lightweight Directory Access Protocol (Lightweight Directory Access Protocol) represents the storage location of the user's directory, used to determine the search location when searching for users. The administrator's directory location represents the storage location of the administrator's directory with search user permissions; the user directory location and the administrator's directory location can be the same or different. The administrator's password represents the login password of the administrator with search user permissions. Search criteria are used to perform searches based on these conditions; for example, the search criteria can be one of the fields, such as username, employee ID, etc.

[0075] The login parameters to be configured for form-filling login include: identity source address, login name attribute name, password attribute name, password encryption algorithm, Hypertext Transfer Protocol (HTTP) method, and HTTP content type. For identity sources that do not support standard protocols, form-filling login can be used.

[0076] It should be noted that the login parameters to be configured for form-filling login can also include additional attribute names. These additional attribute names can be expanded according to actual needs, such as department attribute names, system attribute names, etc. The above protocol can cover more than 90% of scenarios, and new protocols can be added by creating new templates in the future.

[0077] Since the required login parameters vary depending on the login method, configuration templates and login authentication processes can be designed separately for different login methods.

[0078] Figure 3 is a schematic diagram of a configuration template for OIDC protocol login according to an embodiment of this disclosure.

[0079] As shown in Figure 3, this configuration template includes configurable identity source parameters for the identity source and configurable login parameters for the OIDC protocol. The configurable identity source parameters include the identity source name, application icon, description, associated application, account registration policy, whether to enable it, and the login redirect address. The application icon is the identity source icon mentioned above; it can be uploaded by dragging and dropping an image or by clicking the "Upload" button. The description is the identity source description, used for a detailed description of the identity source. The associated application determines the specific login method; for example, if the associated application is a mini-program, then mini-program login is used; if the associated application is a webpage, then webpage login is used. The account registration policy can be "Default User Policy," "Default Identity Source Policy," or a pre-configured policy such as "1112" or "111." The configurable login parameters include the authorization code API call address, client identifier, redirect address, and client password.

[0080] According to embodiments of this disclosure, the above method may further include, in response to a parameter configuration operation for a target identity source, displaying a target configuration template for the target identity source in a configuration interface, wherein the target configuration template includes identity source parameters to be configured for the target identity source and login parameters to be configured for the login method, one identity source corresponds to one login method, and one login method has a corresponding configuration template and login authentication process; and generating preset configuration information for the target identity source based on the parameter information input in the target configuration template.

[0081] One identity source corresponds to one login method, and one login method has a corresponding configuration template and login authentication process. It can be understood that different identity sources can use different login methods, and different login methods can be understood as using different login protocols. Different login protocols have different configuration templates and login authentication processes.

[0082] For example, two identity sources can correspond to two login methods. Identity source 1 can correspond to login method a, such as OIDC protocol login, while identity source 2 can correspond to login method b, such as OAuth protocol login. Furthermore, login method a using the OIDC protocol has a corresponding configuration template and login authentication process, and login method b using the OAuth protocol has a corresponding configuration template and login authentication process.

[0083] For example, if the login method for the target identity source is OIDC protocol login, the configuration template shown in Figure 3 can be displayed on the configuration interface. Users can configure the corresponding parameters to generate preset configuration information for the target identity source.

[0084] By developing configuration templates for each login protocol, identity sources using the same protocol only need to be configured according to the template parameters. For example, if a new login entry using OIDC protocol identity source 1 is needed, and the target application has already configured an OIDC protocol login template, referencing identity source 1 only requires configuring the template parameters, without needing to redevelop the authentication process.

[0085] Different login methods correspond to different login authentication processes. Regardless of the login authentication process used, the purpose is to have the identity source confirm the user's identity. The target application recognizes this "confirmation" and needs to obtain the first user information after recognition. This first user information is information related to the user stored by the identity source.

[0086] For example, when the login method of the target identity source is OAuth protocol login, the login authentication process corresponding to the login method of the target identity source according to the preset configuration information may include: responding to the callback request, obtaining the authorization code of the target identity source by calling the authorization code interface according to the authorization code interface call address; and sending the client identifier, client password, redirect address and authorization code to the target identity source so that the target identity source can verify the client identifier, client password, redirect address and authorization code, and returning an access token if the verification is successful. Here, the callback request is sent by the target identity source based on the authentication of the user's login information; and sending the client identifier, client password and access token to the target identity source by calling the user interface according to the user interface call address so that the target identity source can verify the access token, and returning the first user information for the user if the verification is successful.

[0087] Figure 4 is a flowchart of the login authentication process for OAuth protocol login according to an embodiment of this disclosure.

[0088] As shown in Figure 4, user 401 selects one of the login portals for at least one identity source on the front-end page of the target application to obtain the target identity source 402; then the front-end page of the target application executes operation S410 to redirect to the target identity source, and then executes operations S420 to S480.

[0089] During operation S420, the target identity source displays the identity source login interface so that user 401 can enter login information, which may include account information.

[0090] When operating S430, the target identity source verifies the account information, and returns an authorization code after successful verification.

[0091] When operating S440, the target application backend calls the authorization code interface to obtain the authorization code and sends the client identifier, client secret, redirect address and authorization code.

[0092] When operating S450, the target identity source verifies the client identifier, client password, redirect address, and authorization code, and returns an access token if the verification is successful.

[0093] When operating S460, the target application backend calls the user interface to obtain an access token and sends the client identifier, client secret, and access token.

[0094] When operating S470, the target identity source verifies the access token, and returns the first user information after successful verification.

[0095] When operating S480, the target application backend obtains the first user information in order to carry out subsequent processes based on the first user information.

[0096] For example, when the login method of the target identity source is OIDC protocol login, the login authentication process corresponding to the login method of the target identity source according to the preset configuration information may include: responding to the callback request, obtaining the authorization code of the target identity source by calling the authorization code interface according to the authorization code interface call address; and sending the client identifier, client password, redirection address and authorization code to the target identity source so that the target identity source can verify the client identifier, client password, redirection address and authorization code, and returning an access token and an identification token if the verification is successful. Here, the callback request is sent by the target identity source based on the authentication of the user's login information; parsing the identification token sent by the target identity source to obtain the first user information.

[0097] Figure 5 is a flowchart of the login authentication process for OIDC protocol login according to an embodiment of this disclosure.

[0098] As shown in Figure 5, user 501 selects one of the login entrances of at least one identity source on the front-end page of the target application to obtain the target identity source 502; then the front-end page of the target application executes operation S510 to redirect to the target identity source 502, and then executes operations S520 to S560.

[0099] When operating S520, the target identity source displays the identity source login interface so that user 501 can enter login information, which may include account information.

[0100] When operating the S530, the target identity source verifies the account information, and returns an authorization code after successful verification.

[0101] When operating S540, the target application backend calls the authorization code interface to obtain the authorization code and sends the client identifier, client secret, redirect address and authorization code.

[0102] When operating the S550, the target identity source verifies the client identifier, client password, redirect address, and authorization code. If the verification is successful, it returns an access token and an identity token, where the identity token includes the first user information.

[0103] When operating S560, the target application backend obtains the access token and the identification token, and parses the identification token to obtain the first user information, so as to carry out subsequent processes based on the first user information.

[0104] For example, when the login method of the target identity source is Secure Assertion Markup Language Protocol (SAMR) login, the login authentication process corresponding to the login method of the target identity source is executed according to the preset configuration information, including: generating an authorization request based on the identity source name, user interface call address, and signature information; sending the authorization request to the target identity source so that the target identity source can parse the authorization request and perform identity authentication on the target application based on the signature information; authenticating the user's login information if the identity authentication is successful; generating and returning the authentication result if the login information authentication is successful, wherein the authentication result includes the user's first user information; and parsing the authentication result to obtain the first user information.

[0105] Figure 6 is a login authentication flowchart for SAML protocol login according to an embodiment of this disclosure.

[0106] As shown in Figure 6, user 601 selects one of the login portals for an identity source from at least one identity source on the front-end page of the target application, obtains the target identity source 602, and then executes operations S610 to S660.

[0107] When operating S610, the target application backend generates an authorization request based on the target identity source's identity source name, user interface call address, and signature information, and sends it to the target application frontend page.

[0108] When operating S620, the target application's front-end page is redirected to the target identity source based on the authorization request.

[0109] During operation S630, the target identity source parses the authorization request and verifies the signature information. If the verification is successful, the login interface is displayed so that the user 601 can enter login information, which may include account information.

[0110] When operating S640, the target identity source verifies the account information. After successful verification, the authentication result is returned, which may include the first user information.

[0111] When operating the S650, the target application's front-end page receives the authentication result and calls the back-end for parsing.

[0112] When operating the S660, the target application backend parses the authentication result to obtain the first user information, so as to carry out subsequent processes based on the first user information.

[0113] For example, when the login method of the target identity source is Lightweight Directory Access Protocol (HDLP) login, the login authentication process corresponding to the login method of the target identity source, based on the preset configuration information, includes: obtaining the identity source account and identity source password entered by the user on the login interface; sending a first connection request to the server for the protocol address based on the administrator's directory location and password, so that the server can authenticate the administrator's account and password, and establish a connection with the target application if the authentication is successful; sending search criteria, user directory location, and identity source account to the server so that the server can search for users based on the search criteria, user directory location, and identity source account, and return the searched user information; generating the username required for HDLP login based on the searched user information, and sending a second connection request to the server based on the username and identity source password, so that the server can authenticate the username and identity source password, and return the first user information for the user if the authentication is successful.

[0114] Figure 7 is a login authentication flowchart for LDAP protocol login according to an embodiment of the present disclosure.

[0115] As shown in Figure 7, user 701 enters the LDAP account and LDAP password 702 on the LDAP login interface displayed on the front-end page of the target application, and then executes operations S710 to S780.

[0116] When operating S710, the target application backend obtains the LDAP account and LDAP password.

[0117] When operating the S720, the target application backend sends a first connection request to the LDAP server based on the administrator's directory location and password. The first connection request is used to connect as an administrator.

[0118] When operating the S730, the target identity source verifies the administrator account and password, and establishes a connection with the target application after successful verification.

[0119] When operating the S740, the target application backend sends search criteria, user directory location, and identity source account.

[0120] When operating the S750, the target identity source searches for users based on search criteria, user directory location, and identity source account, and returns the searched user information.

[0121] When operating the S760, the target application backend generates the LDAP username required for LDAP login based on the searched user information, and sends a second connection request to the LDAP server based on the LDAP username and LDAP password. The second connection request is used to connect as a regular user.

[0122] When operating the S770, verify the LDAP account and LDAP password, and establish a connection with the target application after successful verification.

[0123] When operating S780, the searched user information is determined to be the first user information, so that subsequent processes can be carried out based on the first user information.

[0124] For example, when the login method of the target identity source is form-filling login, the login authentication process corresponding to the login method of the target identity source is executed according to the preset configuration information, including: in response to obtaining the identity source account and identity source password, converting and encrypting the identity source account and identity source password according to the preset configuration information to obtain the processed account and processed password; sending the processed account and processed password to the target identity source according to the identity source address so that the target identity source can verify the processed account and processed password; if the verification is successful, returning a verification result including the first user information.

[0125] Figure 8 is a flowchart of the login authentication process for protocol login with form filling according to an embodiment of this disclosure.

[0126] As shown in Figure 8, user 801 enters the source account and source password 802 on the front-end page of the target application, and then performs operations S810 to S840.

[0127] When operating S810, the target application backend converts and encrypts the identity source account and identity source password according to the preset configuration information for the target identity source, and obtains the processed account and processed password.

[0128] When operating the S820, the processed account and processed password are sent to the target identity source based on the identity source address.

[0129] During operation of S830, the target identity source verifies the processed account and the processed password. If the verification is successful, a verification result including the first user information is returned.

[0130] When operating S840, the target application backend receives the verification result to obtain the first user information, so as to carry out subsequent processes based on the first user information.

[0131] The first user information can be user information stored in the target identity source, and the target application account can be the account that the user registered in the target application.

[0132] The first user information may include the identity source account stored in the target identity source; the target application may include an account association table, which includes at least one target application account and an identity source account associated with the target application account.

[0133] For example, determining a user's target application account for a target application may include: searching for the target application account associated with the identity source account in the account association table; if the account association table contains the target application account associated with the identity source account, obtaining the user's target application account; if the account association table does not contain the target application account associated with the identity source account, establishing the association between the identity source account and the target application.

[0134] According to embodiments of this disclosure, the preset configuration information also includes an account association method. The account association method may include automatic association or manual association.

[0135] For example, establishing the association between a source account and a target application can include establishing the association between the source account and the target application based on the account association method.

[0136] Figure 9 is a schematic diagram of a target application account determination method according to an embodiment of the present disclosure.

[0137] As shown in Figure 9, based on the identity source account 911 contained in the first user information 910, the target application account associated with the identity source account 911 is searched in the account association table 920. If an associated account exists, the target application account 940 is obtained; if no associated account exists, the account association method 930 for the identity source is determined. If the account association method is manual association, the target application account 940 is obtained manually; if the account association method is automatic association, the target application account 940 is obtained automatically, and the account association table 920 is updated using the target application account 940 and the identity source account 911.

[0138] Manual association refers to a situation where, after a user logs in through the target identity source, it is determined that this is their first time using the target identity source and they have not bound the target application before. They are then required to manually bind the target application account. At this time, the backend will carry the association information and redirect to an address on the frontend. The user will see an interactive interface in their browser where they can enter their account and password. This interface also supports registration, making it convenient for users who do not have the target application account and password to register and associate.

[0139] Figure 10 is a flowchart of establishing association relationships using a manual association method according to an embodiment of the present disclosure.

[0140] As shown in Figure 10, this embodiment 1000 includes operations S1010 to S1050.

[0141] When operating S1010, the account association interface is displayed.

[0142] In operation S1020, account analysis is performed based on at least one target application account and the association information entered by the user on the account association interface to obtain a second analysis result.

[0143] In operation S1030, based on the second analysis result, it is determined whether at least one target application account exists that targets the user. If it exists, operation S1050 is executed; otherwise, operation S1040 is executed.

[0144] In operation S1040, a target application account for the user is registered according to the registration policy for the target identity source.

[0145] In operation S1050, establish the association between the target application account and the identity source account for the user.

[0146] Figure 11 is a schematic diagram of an account association interface according to an embodiment of the present disclosure.

[0147] As shown in Figure 11, the account association interface includes the association of existing accounts and also supports registration for users without accounts. After registration, the account can be associated. If a user has an account for the target application, they can directly enter their username and password and click "Bind Now." The system then analyzes the entered account against the existing target application account. If the analysis shows that the existing target application account contains the entered account, it means the entered account is indeed the target application account, and the association between the target application account and the identity source account can be established. If the analysis shows that the existing target application account does not contain the entered account, it means the entered account is not the target application account, and account registration is required. Account registration must be based on the target identity source's registration strategy, and account management follows after registration.

[0148] Automatic association means that after a user logs in through a target identity source, regardless of whether it's their first time logging in, they won't be redirected to an interactive interface to enter their username and password. Instead, the backend performs some logical processing to automatically log the user in. The logical processing first determines whether the automatic association mode is based on field matching to check if the user already exists, or whether a new user will be created regardless. If the automatic association mode is based on field matching, the relevant fields are extracted and compared with the fields in the user table of the database. Generally, non-nullable or unique fields in the account table are compared, such as username, email, and phone number. If no user is found, a new user will be registered and the account will be associated. If the automatic association mode is to create a new user regardless, a new user will be directly registered and the account will be associated.

[0149] Figure 12 is a flowchart of establishing association relationships using an automatic association method according to an embodiment of the present disclosure.

[0150] As shown in Figure 12, this embodiment 1200 includes operations S1210 to S1240.

[0151] In operation S1210, account analysis is performed based on at least one target application account and first user information to obtain the first analysis result.

[0152] In operation S1220, based on the first analysis result, it is determined whether at least one target application account exists that targets the user. If it exists, operation S12400 is executed; otherwise, operation S1230 is executed.

[0153] In operation S1230, a target application account for the user is registered according to the registration policy for the target identity source.

[0154] In operation S1240, establish the association between the target application account and the identity source account for the user.

[0155] During user registration, the problem of insufficient registration information may arise, such as missing usernames, email addresses, roles, and organizations. In such cases, a registration strategy can be abstracted to describe how various pieces of user information are processed during registration.

[0156] For example, a registration strategy can be a collection of multiple account information strategies. The input to the registration strategy is initial registration information, and the output is final registration information. Initial registration information can be form information entered by the user during normal registration, or it can be the initial user information from the target identity source. Therefore, registration strategies can be applied to both normal registration scenarios and external identity source scenarios. Registration strategies can include: username strategy, name strategy, password strategy, email strategy, mobile phone number strategy, organization strategy, role strategy, user type strategy, user level strategy, expiration time strategy, etc. The final registration information is the registration information after the initial registration information has been processed by the registration strategy.

[0157] Figure 13 is a schematic diagram of processing registration information using a registration strategy according to an embodiment of the present disclosure.

[0158] As shown in Figure 13, the initial registration information 1320 is determined based on the registration information 1310_1 submitted by the user through the form or the user's identity information 1310_2 from an external identity source. The initial registration information 1320 is processed by registration strategies, such as username strategy, name strategy, password strategy, email strategy, mobile phone number strategy, organization strategy 1330, role strategy, user type strategy, user level strategy, and expiration time strategy, to obtain the final registration information 1310. The final registration information 1340 is used for registration to obtain the target application account 1350.

[0159] For each strategy in the registration strategy, five configuration methods can be set, such as default value, fixed value, random value, lookup table and custom.

[0160] Default values ​​indicate that the initial registration information is preferred. If the initial registration information is empty, a supplementary value can be specified as an alternative. For example, assuming the name policy in the registration strategy is "default value" and the supplementary value is "new user," if a user fills in the name "A" during registration, then the user's final registered name will be "A." If the user does not fill in a name during registration, or if filling in a name is not allowed, then the user's final registered name will be "new user." Default values ​​are generally used for regular registrations because regular registrations can obtain a lot of initial information filled in by the user. Registrations from external identity sources obtain less user information, and using only supplementary values ​​makes it difficult to distinguish account information. It should be noted that user type policies, user level policies, and expiration time policies do not support default values.

[0161] Fixed-value representation allows you to ignore initial registration information and consistently fill in a single value. For example, if the role strategy in the registration policy is a "fixed value" with the value "regular user," and a user registers with the role "administrator," then the user's final registered role will be "regular user." Fixed-value representation is used when you want to enforce constraints on account information during a specific registration process. Username, email, and phone number strategies are account information with unique value characteristics and do not support fixed-value representation.

[0162] Random value indicates that a value is randomly entered regardless of the initial registration information. Assuming the password policy in the registration strategy is "random value," a random value will be generated and used as the user's password regardless of whether a password is entered during registration. Randomness can be applied in scenarios such as wanting users logging in with a specific external identity to be able to log in only with that external identity and not with system-generated associated accounts. Random values ​​are not supported for email, phone number, organization, role, user type, user level, or expiration time policies.

[0163] A lookup table represents a table that provides data for comparison. During registration, the data to be compared is retrieved from this lookup table. Assuming the username policy in the registration strategy is a "lookup table," and username comparison information has been uploaded (e.g., "A" corresponds to "Aa"), then when "A" registers, the final username in the user table will be "Aa." The lookup table is crucial for mapping username policies, role policies, and organizational policies, allowing for account mapping based on external identity information. It can also restrict logins from external identity sources. For example, if a particular external identity source is only configured with username comparisons for "A1," "A2," and "A3," then only these three users from that external identity source can log in to the system. Other accounts, lacking a comparison relationship, will be unable to log in, significantly improving security.

[0164] Custom representations use custom functions to handle initial registration information. Assuming the name strategy in the registration policy is "custom," the custom function requires adding "_application1" to the end of all names, indicating that the account was logged in and registered from the external identity source "application1." Customization allows the system to customize accounts logged in from a specific identity source. Changing the account's email address, phone number, organization, role, user type, user level, or expiration time through functions is not allowed.

[0165] By introducing a user registration strategy, registration can be performed according to the strategy after successful login from an external identity source. Different identity sources often have different user registration methods, and even the same identity source may modify its user registration strategy. Abstracting the user registration strategy can better support similar requirements.

[0166] According to embodiments of this disclosure, the above method may further include, before determining the user's target application account for the target application: performing unified data processing on the first user information using a preset information template to obtain user data.

[0167] The preset information template may include at least one field. Specifically, processing the first user information using the preset information template to obtain user data may include: for each of the at least one field, if it is determined that the first user information includes field data for that field, extracting the field data and adding it to the preset information template to obtain the user data. The user data may be in JSON format.

[0168] For example, the preset information template includes fields 1, 2, and 3. Using the preset information template to perform unified data processing on the first user information, the resulting user data may include: extracting information for field 1 from the first user information and filling it into the field 1 position; extracting information for field 2 from the first user information and filling it into the field 2 position; extracting information for field 3 from the first user information and filling it into the field 3 position; and integrating the filled data to obtain the user data.

[0169] It should be noted that for any field, if the first user information does not contain information corresponding to that field, then data filling for that field will be skipped. For example, for field 4, if the first user information does not contain information for field 4, then data filling for field 4 will be skipped.

[0170] Since the format and content of the first user information provided by different external identity sources are different, the data is uniformly processed by using a preset information template to facilitate subsequent use.

[0171] Figure 14 is a flowchart of a local login method according to an embodiment of the present disclosure.

[0172] As shown in Figure 14, the local login method of this embodiment 1400 includes operations S1410 to S1470.

[0173] In operation S1410, obtain login information for the user.

[0174] Login information can be the target application account and password entered by the user on the login page, or it can be a mobile phone number and SMS verification code. It can also be login information from the target identity source.

[0175] In operation S1420, the user's second user information is obtained based on the login information.

[0176] The second user information is the user information stored by the target application. When the login information includes the target application's account, the second user information can be obtained using the target application's account.

[0177] The user acknowledges and agrees to the acquisition and use of the second user information, and all such acquisitions comply with relevant laws and regulations and do not violate public order and good morals.

[0178] In operation S1430, determine whether a login password exists. If it exists, proceed to operation S1440; otherwise, proceed to operation S1450.

[0179] For example, if the login information includes the target application account and password, then password verification is required; if the login information includes a mobile phone number and SMS verification code, then password verification is not required; and if the login information is obtained from the target identity source, then password verification is also not required.

[0180] In operation S1440, verify if the login password is correct. If correct, proceed to operation S1450; if incorrect, proceed to operation S1470.

[0181] In operation S1450, verify whether the login account is valid. If valid, proceed to operation S1460; if invalid, proceed to operation S1470.

[0182] Verifying account validity can include checking if the account is frozen, disabled, has an incorrect role, or is associated with a disabled organization. If the validity check passes, a token or session is generated, and the user information is stored in the cache.

[0183] Successfully logged into the target application while operating S1460.

[0184] The final step in the login process can be setting cookies, setting sessions, returning token information, or redirecting to a specific address.

[0185] During operation S1470, login to the target application failed.

[0186] Figure 15 is a flowchart of a login method according to another embodiment of the present disclosure.

[0187] As shown in Figure 15, the login method of this embodiment 1500 includes an external identity source login process 1510 and a local identity source login process 1520.

[0188] In the external identity source login process 1510, user 1501 selects one of the identity source login entrances on the front-end page of the target application to obtain the target identity source 1502, and then performs operations S1511 to S1516.

[0189] In operation S1511, the target login protocol is determined from the login protocol 1503 based on the identification information of the target identity source 1502.

[0190] In operation S1512, the user's login information is authenticated using the login authentication process corresponding to the target login protocol, and the first user information 1504 is output. The first user information 1504 may include the identity source account stored in the target identity source.

[0191] During authentication using the target login protocol, if the target login protocol is OAuth2, OIDC, or SAML2.0, the user needs to be redirected to the IDP page first. After the user enters their username and password or scans a QR code and the IDP authenticates the user, they are redirected back to the target application. If it is LDAP or a form-filling service, the user can directly enter their username and password to log in on the target application's front-end page.

[0192] In operation S1513, determine whether the source account is associated with the target application account. If they are associated, proceed to operation S1516; otherwise, proceed to operations S1514 through S1515.

[0193] In operation S1514, the target application account is registered according to the registration policy of the target identity source.

[0194] In operation S1515, establish the association between the source identity account and the target application account.

[0195] During operation S1516, the target application account was obtained.

[0196] In the local identity source login process 1510, based on the login information entered by user 1501 on the front-end page of the target application, such as the target application account and password, or mobile phone number and SMS verification code, operations S1521 to S1526 are executed.

[0197] In operation S1521, the target application account is obtained based on the login information.

[0198] In operation S1522, query the second user information based on the target application account.

[0199] It should be noted that the target application account in step S1522 can come from operation S1521 or operation S1516.

[0200] In operation S1523, determine whether it is a passwordless login. If yes, proceed to operation S1525; otherwise, proceed to operation S1524.

[0201] In operation S1524, verify the password. If the verification is successful, proceed with operation S1525.

[0202] In operation S1525, verify the account validity. If the verification is successful, proceed with operation S1526.

[0203] After operating S1526, the login success page was displayed.

[0204] It should be noted that the local identity source login process refers to logging in using the target application's account and password, or using a mobile phone number and SMS verification code.

[0205] By integrating the external identity source login process into the local identity source login process, a unified user model can be used, facilitating other management and statistical needs, while other parts of the target application do not need to concern themselves with where the user comes from. Furthermore, all login protocols will follow the same process after information authentication is completed, achieving partial process reuse.

[0206] Figure 16 is a schematic diagram of a login method according to an embodiment of the present disclosure.

[0207] As shown in Figure 16, the login method in this embodiment includes an external identity source login process and a local identity source login process.

[0208] The login process for external identity sources includes: User 1601 selects the target identity source on the login interface 1602 of the target application and sends the target identity source ID to the protocol receiving module 1604. The protocol receiving module 1604 uses the target identity source ID to obtain the target login parameters from the protocol template storage unit 1603. Then, the protocol receiving module 1604 sends the target login parameters to the protocol execution module 1605. The protocol execution module 1605 executes the login authentication process according to the target login parameters, obtains the first user information, and sends it to the user information unification module 1606. The information unification module 1606 unifies the first user information to obtain consistent user information and identity source accounts, and sends them to the identity source association analysis module 1607. The identity source management module 1607 searches for the associated target application account in the identity information storage unit 1608 based on the identity source account. If an associated target application account exists, it proceeds to the information integration module 1616; otherwise, it proceeds to the registration strategy module 1609. The registration strategy module 1609 retrieves the target identity source ID from the registration strategy storage unit 1610. The registration strategy for the identity source is as follows: If the registration strategy is manual association, the user 1601 enters account information on the account association interface 1611, then enters the manual association processing module 1612 to process the account information, and finally enters the account analysis module 1613. If the registration strategy is automatic association, the user directly enters the account analysis module 1613. The account analysis module 1613 performs account analysis. If the analysis result shows that a target application account exists for the user, the user enters the association module 1615 to establish the association relationship between the target application account and the identity source account. Write the information to the identity information storage unit 1609; if the analysis result indicates that there is no target application account for the user, then proceed to the registration module 1614. The registration module 1614 registers the target application account according to the registration strategy and writes it to the user storage unit 1618. Then, it sends the registered target application account to the association module 1615 to establish the association between the registered target application account and the identity source account and writes it to the identity information storage unit 1609. After that, the association module 1615 sends the target application account to the login information integration module 1616, and then proceeds to the local identity source login process.

[0209] The local identity source login process includes: the login information integration module 1616 determines the user ID or username based on the target account and sends it to the login module 1617; the login module 1617 retrieves user information from the user storage unit 1618 based on the user ID or username and sends the user information to the session module 1619, which writes it to the session storage unit 1620; simultaneously, the login module 1617 sends the user information to the redirection module 1621, which determines whether redirection is needed. If redirection is not needed, the module enters the front-end control interface 1622 after login and returns it to the user 1601; if redirection is needed, the module enters the specified page 1623 and returns it to the user 1601.

[0210] Additionally, when a user directly logs in using their local identity source, the process can include: user 1624 entering login information on login interface 1625; login information integration module 1616 determining the user ID or username based on the login information and sending it to login module 1617; login module 1617 retrieving user information from user storage unit 1618 based on user ID or username and sending the user information to session module 1619; session module 1619 writing the information to session storage unit 1620; simultaneously, login module 1617 sending the user information to redirection module 1621; redirection module 1621 determining whether redirection is needed; if no redirection is needed, it enters the front-end control login interface 1622 and returns it to user 1624; if redirection is needed, it enters the specified page 1623 and returns it to user 1624.

[0211] Figure 17 is a block diagram of a login device according to an embodiment of the present disclosure.

[0212] As shown in Figure 17, the login device of this embodiment is applied to a target application, wherein the target application includes a login entry point for at least one identity source, and the identity source represents a loginable application other than the target application. The login device 1700 includes: an acquisition module 1710, an execution module 1720, and a determination module 1730.

[0213] The acquisition module 1710 is used to acquire preset configuration information for the target identity source in response to the user selecting the login entry of the target identity source from at least one identity source.

[0214] The execution module 1720 is used to execute a login authentication process corresponding to the login method of the target identity source according to the preset configuration information, wherein the target identity source authenticates the user's login information to obtain the first user information.

[0215] The determination module 1730 is used to determine the user's target application account for the target application in response to the first user information from the target identity source, so as to log in to the target application using the target application account.

[0216] According to embodiments of this disclosure, the login device further includes a display module and a generation module.

[0217] The display module is used to respond to parameter configuration operations for the target identity source. It displays the target configuration template for the target identity source in the configuration interface. The target configuration template includes the identity source parameters to be configured for the target identity source and the login parameters to be configured for the login method. One identity source corresponds to one login method, and one login method has a corresponding configuration template and login authentication process.

[0218] The generation module is used to generate preset configuration information for the identity source based on the parameter information input in the target configuration template.

[0219] According to embodiments of this disclosure, the configurable parameters for an identity source include at least one of the following: identity source name, identity source icon, identity source description, whether enabled, redirect address, identity source account mapping field, user information mapping field, and target application account registration strategy.

[0220] According to embodiments of this disclosure, login methods include: OAuth protocol login, OIDC protocol login, Security Assertion Markup Language protocol login, Lightweight Directory Access Protocol login, or form-filling login.

[0221] According to embodiments of this disclosure, the configurable login parameters for OAuth protocol login include: client identifier, client password, redirect address, user interface call address, and authorization code interface call address; the configurable login parameters for OIDC protocol login include: authorization code interface call address, client identifier, client password, and redirect address; the configurable login parameters for Security Assertion Markup Language protocol login include: identity source name, user interface call address, and signature information; the configurable login parameters for Lightweight Directory Access Protocol login include: protocol address, user directory location, administrator's directory location, administrator's password, and search criteria; and the configurable login parameters for form-filling login include: identity source address, login name attribute name, password attribute name, password encryption algorithm, Hypertext Transfer Protocol method, and Hypertext Transfer Protocol content type.

[0222] According to embodiments of this disclosure, the execution module includes a first acquisition submodule and a first sending submodule.

[0223] The first acquisition submodule is used to respond to the callback request by obtaining the authorization code of the target identity source through the authorization code interface called according to the authorization code interface call address; and sending the client identifier, client password, redirect address and authorization code to the target identity source so that the target identity source can verify the client identifier, client password, redirect address and authorization code. If the verification is successful, an access token is returned. The callback request is sent by the target identity source based on the authentication of the user's login information.

[0224] The first sending submodule is used to send the client identifier, client password and access token to the target identity source through the user interface called according to the user interface call address, so that the target identity source can verify the access token and return the first user information for the user if the verification is successful.

[0225] According to embodiments of this disclosure, the execution module further includes: a second acquisition submodule and a first parsing submodule.

[0226] The second acquisition submodule is used to respond to the callback request by obtaining the authorization code of the target identity source through the authorization code interface called according to the authorization code interface call address; and sending the client identifier, client password, redirect address and authorization code to the target identity source so that the target identity source can verify the client identifier, client password, redirect address and authorization code. If the verification is successful, the access token and identification token are returned. The callback request is sent by the target identity source based on the authentication of the user's login information.

[0227] The first parsing submodule is used to parse the identifier token sent by the target identity source to obtain the first user information.

[0228] According to embodiments of this disclosure, the execution module further includes: a first generation submodule, a second sending submodule, and a second parsing submodule.

[0229] The first generation submodule is used to generate an authorization request based on the identity source name, user interface call address, and signature information.

[0230] The second sending submodule is used to send an authorization request to the target identity source so that the target identity source can parse the authorization request and perform identity authentication on the target application based on the signature information. If the identity authentication is successful, the user's login information is authenticated. If the login information authentication is successful, the authentication result is generated and returned, wherein the authentication result includes the user's first user information.

[0231] The second parsing submodule is used to parse the authentication result and obtain the first user information.

[0232] According to embodiments of this disclosure, the execution module further includes: a third acquisition submodule, a third sending submodule, a fourth sending submodule, and a second generation submodule.

[0233] The third acquisition submodule is used to acquire the user's source account and source password entered on the login interface.

[0234] The third sending submodule is used to send a first connection request to the server at the protocol address based on the administrator's directory location and password, so that the server can authenticate the administrator's account and password, and establish a connection with the target application if the authentication is successful.

[0235] The fourth sending submodule is used to send search criteria, user directory location, and source account to the server, so that the server can search for users based on the search criteria, user directory location, and source account, and return the searched user information.

[0236] The second generation submodule is used to generate the username required for Lightweight Directory Access Protocol (LCAP) login based on the searched user information, and send a second connection request to the server based on the username and source password so that the server can authenticate the username and source password. If the authentication is successful, the first user information for the user is returned.

[0237] According to embodiments of this disclosure, the execution module further includes a processing submodule and a fifth sending submodule.

[0238] The processing submodule is used to respond to the acquisition of the source account and source password, and to convert and encrypt the source account and source password according to the preset configuration information to obtain the processed account and processed password.

[0239] The fifth sending submodule is used to send the processed account and processed password to the target identity source according to the identity source address, so that the target identity source can verify the processed account and processed password. If the verification is successful, the verification result including the first user information is returned.

[0240] According to embodiments of this disclosure, the first user information includes an identity source account stored in the target identity source; the target application includes an account association table, which includes at least one target application account and an identity source account associated with the target application account.

[0241] According to embodiments of this disclosure, the determining module includes a lookup submodule.

[0242] The search submodule is used to search the account association table for the target application account associated with the identity source account, and obtain the target application account for the user.

[0243] According to embodiments of this disclosure, the preset configuration information also includes account association methods.

[0244] According to embodiments of this disclosure, the login device further includes an establishment module.

[0245] The module is used to establish the association between the source account and the target application based on the account association method, when the account association table does not contain a target application account associated with the source account.

[0246] According to embodiments of this disclosure, account association methods include manual association or automatic association.

[0247] According to embodiments of this disclosure, the establishment module further includes a first account analysis submodule, a first establishment submodule, and a first registration submodule.

[0248] The first account analysis submodule is used to perform account analysis based on at least one target application account and first user information, when the account association method is determined to be automatic association, and to obtain the first analysis result.

[0249] The first submodule is used to establish an association between the target application account for the user and the identity source account when the first analysis results show that at least one target application account includes a target application account for the user.

[0250] The first registration submodule is used to register a target application account for the user according to the registration strategy for the target identity source, and to establish an association between the target application account for the user and the identity source account, when the first analysis results show that at least one target application account does not include a target application account for the user.

[0251] According to embodiments of this disclosure, the establishment module further includes a display submodule, a second account analysis submodule, a second establishment submodule, and a second registration submodule.

[0252] The display submodule is used to display the account association interface.

[0253] The second account analysis submodule is used to perform account analysis based on at least one target application account and the association information entered by the user in the account association interface, and obtain the second analysis result.

[0254] The second establishment submodule is used to establish the association between the target application account for the user and the identity source account when the second analysis results show that at least one target application account includes a target application account for the user.

[0255] The second registration submodule is used to register a target application account for the user and establish an association between the target application account for the user and the identity source account, in the case that the second analysis results show that at least one target application account does not include a target application account for the user.

[0256] According to embodiments of this disclosure, the login device further includes a data unification module.

[0257] The data unification module is used to process the first user information using a preset information template before determining the user's target application account for the target application, thereby obtaining user data.

[0258] According to embodiments of this disclosure, the preset information template includes at least one field.

[0259] According to embodiments of this disclosure, the data unification module includes an extraction submodule.

[0260] The extraction submodule is used to extract field data and add it to a preset information template for each field in at least one field, provided that the first user information includes field data for that field, to obtain user data.

[0261] According to embodiments of this disclosure, the login device further includes a login module, which includes a fourth acquisition submodule and a login submodule.

[0262] The fourth acquisition submodule is used to obtain the user's second user information based on the target application account, wherein the second user information includes the user's information stored in the target application.

[0263] The login submodule is used to verify the target application account based on the second user information, and log in to the target application if the target application account is verified.

[0264] Any one or more of the modules, submodules, units, and subunits according to embodiments of the present disclosure, or at least part of the functions of any one or more of them, can be implemented in one module. Any one or more of the modules, submodules, units, and subunits according to embodiments of the present disclosure can be implemented by dividing them into multiple modules. Any one or more of the modules, submodules, units, and subunits according to embodiments of the present disclosure can be at least partially implemented as hardware circuitry, such as Field Programmable Gate Arrays (FPGAs), Programmable Logic Arrays (PLAs), Systems-on-Chip, Systems-on-Substrate, Systems-on-Package, Application-Specific Integrated Circuits (ASICs), or implemented in hardware or firmware by any other reasonable means of integrating or packaging circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, one or more of the modules, submodules, units, and subunits according to embodiments of the present disclosure can be at least partially implemented as computer program modules, which, when run, can perform corresponding functions.

[0265] For example, any plurality of the acquisition module 1710, execution module 1720, and determination module 1730 may be combined into one module / unit / subunit, or any one of these modules / units / subunits may be split into multiple modules / units / subunits. Alternatively, at least a portion of the functionality of one or more of these modules / units / subunits may be combined with at least a portion of the functionality of other modules / units / subunits and implemented in one module / unit / subunit. According to embodiments of this disclosure, at least one of the acquisition module 1710, execution module 1720, and determination module 1730 may be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or any other reasonable means of integrating or packaging circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of the acquisition module 1710, the execution module 1720, and the determination module 1730 may be implemented at least partially as a computer program module that can perform corresponding functions when the computer program module is run.

[0266] It should be noted that the login device part in the embodiments of this disclosure corresponds to the login method part in the embodiments of this disclosure. For a detailed description of the login device part, please refer to the login method part, which will not be repeated here.

[0267] Figure 18 is a block diagram of an electronic device suitable for implementing the methods described above according to an embodiment of the present disclosure. The electronic device shown in Figure 18 is merely an example and should not be construed as limiting the functionality and scope of the embodiments of the present disclosure.

[0268] As shown in FIG18, an electronic device 1800 according to an embodiment of the present disclosure includes a processor 1801, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1802 or a program loaded from a storage portion 1808 into a random access memory (RAM) 1803. The processor 1801 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 1801 may also include onboard memory for caching purposes. The processor 1801 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of the present disclosure.

[0269] RAM 1803 stores various programs and data required for the operation of electronic device 1800. Processor 1801, ROM 1802, and RAM 1803 are interconnected via bus 1804. Processor 1801 performs various operations of the method flow according to embodiments of the present disclosure by executing programs in ROM 1802 and / or RAM 1803. It should be noted that the programs may also be stored in one or more memories other than ROM 1802 and RAM 1803. Processor 1801 may also perform various operations of the method flow according to embodiments of the present disclosure by executing programs stored in said one or more memories.

[0270] According to embodiments of this disclosure, the electronic device 1800 may further include an input / output (I / O) interface 1805, which is also connected to a bus 1804. The electronic device 1800 may also include one or more of the following components connected to the input / output (I / O) interface 1805: an input section 1806 including a keyboard, mouse, etc.; an output section 1807 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1808 including a hard disk, etc.; and a communication section 1809 including a network interface card such as a LAN card, modem, etc. The communication section 1809 performs communication processing via a network such as the Internet. A drive 1810 is also connected to the input / output (I / O) interface 1805 as needed. A removable medium 1811, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 1810 as needed so that computer programs read from it can be installed into the storage section 1808 as needed.

[0271] According to embodiments of this disclosure, the method flow according to embodiments of this disclosure can be implemented as a computer software program. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable storage medium, the computer program containing program code for performing the methods shown in the flowchart. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1809, and / or installed from removable medium 1811. When the computer program is executed by processor 1801, it performs the functions defined in the system of embodiments of this disclosure. According to embodiments of this disclosure, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0272] This disclosure also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs that, when executed, implement the method according to the embodiments of this disclosure.

[0273] According to embodiments of this disclosure, the computer-readable storage medium can be a non-volatile computer-readable storage medium. Examples include, but are not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this disclosure, the computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0274] For example, according to embodiments of this disclosure, a computer-readable storage medium may include one or more memories other than the ROM 1802 and / or RAM 1803 described above and / or ROM 1802 and RAM 1803.

[0275] Embodiments of this disclosure also include a computer program product comprising a computer program containing program code for performing the methods provided in the embodiments of this disclosure. When the computer program product is run on an electronic device, the program code is used to enable the electronic device to implement the login method provided in the embodiments of this disclosure.

[0276] When the computer program is executed by the processor 1801, it performs the functions defined in the system / apparatus of this disclosure embodiments. According to embodiments of this disclosure, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0277] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via the communication section 1809, and / or installed from a removable medium 1811. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0278] According to embodiments of this disclosure, program code for executing the computer programs provided in embodiments of this disclosure can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can execute entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0279] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions. Those skilled in the art will understand that the features described in the various embodiments of the present disclosure can be combined and / or combined in various ways, even if such combinations are not explicitly described in the present disclosure. In particular, the features described in the various embodiments of this disclosure may be combined and / or combined in various ways without departing from the spirit and teachings of this disclosure. All such combinations and / or combinations fall within the scope of this disclosure.

[0280] The embodiments of this disclosure have been described above. However, these embodiments are for illustrative purposes only and are not intended to limit the scope of this disclosure. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. Various substitutions and modifications can be made by those skilled in the art without departing from the scope of this disclosure, and all such substitutions and modifications should fall within the scope of this disclosure.

Claims

1. A login method, applied to a target application, wherein, The target application includes a login entry point with at least one identity source, whereby the identity source represents a loginable application other than the target application; the method includes: In response to a user selecting a login entry for a target identity source from at least one identity source, the system obtains preset configuration information for the target identity source. According to the preset configuration information, a login authentication process corresponding to the login method of the target identity source is executed, wherein the target identity source authenticates the user's login information to obtain the first user information; In response to the first user information from the target identity source, the user's target application account for the target application is determined, so as to log in to the target application using the target application account.

2. The method according to claim 1, further comprising: In response to the parameter configuration operation for the target identity source, a target configuration template for the target identity source is displayed on the configuration interface. The target configuration template includes identity source parameters to be configured for the identity source and login parameters to be configured for the login method. One identity source corresponds to one login method, and one login method has a corresponding configuration template and login authentication process. Based on the parameter information input into the target configuration template, preset configuration information for the target identity source is generated.

3. The method according to claim 2, wherein, The configurable parameters for the identity source include at least one of the following: identity source name, identity source icon, identity source description, whether to enable, redirect address, identity source account mapping field, user information mapping field, and target application account registration strategy.

4. The method according to claim 2, wherein, The login methods include: OAuth protocol login, OIDC protocol login, Security Assertion Markup Language protocol login, Lightweight Directory Access Protocol login, or form-filling login.

5. The method according to claim 4, wherein, The login parameters to be configured for the OAuth protocol login include: client identifier, client password, redirect address, user interface call address, and authorization code interface call address; The login parameters to be configured for the OIDC protocol login include: authorization code interface call address, client identifier, client password, and redirection address; The login parameters to be configured for the security assertion markup language protocol login include: identity source name, user interface call address, and signature information; The login parameters to be configured for the Lightweight Directory Access Protocol login include: protocol address, user directory location, administrator directory location, administrator password, and search criteria; The login parameters to be configured for the form-filling login include: identity source address, login name attribute name, password attribute name, password encryption algorithm, Hypertext Transfer Protocol method, and Hypertext Transfer Protocol content type.

6. The method according to claim 5, wherein, The step of executing the login authentication process corresponding to the login method of the target identity source according to the preset configuration information includes, in the case where the login method of the target identity source is the OAuth protocol login: In response to the callback request, the system obtains the authorization code of the target identity source by calling the authorization code interface according to the authorization code interface call address; and sends the client identifier, the client password, the redirect address and the authorization code to the target identity source so that the target identity source can verify the client identifier, the client password, the redirect address and the authorization code. If the verification is successful, an access token is returned. The callback request is sent by the target identity source based on the authentication of the user's login information. The user interface, invoked according to the user interface call address, sends the client identifier, the client password, and the access token to the target identity source, so that the target identity source can verify the access token. If the verification is successful, the first user information for the user is returned.

7. The method according to claim 5, wherein, The step of executing the login authentication process corresponding to the login method of the target identity source according to the preset configuration information includes, in the case where the login method of the target identity source is the OIDC protocol login: In response to the callback request, the system obtains the authorization code of the target identity source by calling the authorization code interface according to the authorization code interface call address; and sends the client identifier, the client password, the redirect address and the authorization code to the target identity source so that the target identity source can verify the client identifier, the client password, the redirect address and the authorization code. If the verification is successful, the system returns an access token and an identification token. The callback request is sent by the target identity source based on the authentication of the user's login information. The first user information is obtained by parsing the identifier token sent by the target identity source.

8. The method according to claim 5, wherein, The step of executing the login authentication process corresponding to the login method of the target identity source according to the preset configuration information includes, in the case where the login method of the target identity source is the Security Assertion Markup Language protocol login: An authorization request is generated based on the identity source name, the user interface call address, and the signature information; The authorization request is sent to the target identity source so that the target identity source can parse the authorization request and perform identity authentication on the target application based on the signature information. If the identity authentication is successful, the user's login information is authenticated. If the login information authentication is successful, an authentication result is generated and returned, wherein the authentication result includes the user's first user information. The authentication result is parsed to obtain the first user information.

9. The method according to claim 5, wherein, The step of executing the login authentication process corresponding to the login method of the target identity source according to the preset configuration information includes, in the case where the login method of the target identity source is the Lightweight Directory Access Protocol login: Obtain the user's source account and source password entered on the login interface; Based on the administrator's directory location and password, a first connection request is sent to the server targeting the protocol address, so that the server can authenticate the administrator's account and password, and establish a connection with the target application if the authentication is successful. The search criteria, the user directory location, and the identity source account are sent to the server so that the server can perform a user search based on the search criteria, the user directory location, and the identity source account, and return the searched user information. The system generates a username for logging into the Lightweight Directory Access Protocol based on the searched user information, and sends a second connection request to the server based on the username and the source password, so that the server can authenticate the username and the source password. If the authentication is successful, the server returns the first user information for the user.

10. The method according to claim 5, wherein, The step of executing the login authentication process corresponding to the login method of the target identity source according to the preset configuration information includes, in the case where the login method of the target identity source is the form-filled login: In response to obtaining the source account and source password, the source account and source password are converted and encrypted according to the preset configuration information to obtain the processed account and processed password. The processed account and processed password are sent to the target identity source according to the identity source address, so that the target identity source can verify the processed account and processed password. If the verification is successful, a verification result including the first user information is returned.

11. The method according to claim 1, wherein, The first user information includes the identity source account stored in the target identity source; the target application includes an account association table, which includes at least one target application account and an identity source account associated with the target application account; The step of determining the user's target application account for the target application includes: The target application account associated with the identity source account is obtained by searching the account association table.

12. The method according to claim 11, wherein, The preset configuration information also includes account association methods, and the method further includes: If it is determined that the account association table does not contain a target application account associated with the identity source account, an association relationship between the identity source account and the target application is established according to the account association method.

13. The method according to claim 12, wherein, The account association methods include manual association or automatic association; If the account association method is determined to be automatic association, account analysis is performed based on at least one target application account and the first user information to obtain the first analysis result; If the first analysis results indicate that at least one target application account includes a target application account for the user, then establish an association between the target application account for the user and the identity source account. If the first analysis results indicate that at least one target application account does not include a target application account for the user, then according to the registration strategy for the target identity source, a target application account for the user is registered, and an association is established between the target application account for the user and the identity source account.

14. The method according to claim 12, wherein, If the account association method is determined to be manual association... Displays the account association interface; Account analysis is performed based on at least one target application account and the association information entered by the user on the account association interface to obtain a second analysis result; If the second analysis results indicate that at least one target application account includes a target application account for the user, then establish an association between the target application account for the user and the identity source account. If the second analysis results indicate that at least one target application account does not include a target application account for the user, then according to the registration strategy for the identity source, a target application account for the user is registered, and an association is established between the target application account for the user and the identity source account.

15. The method of claim 1, further comprising, before determining the user's target application account for the target application: The first user information is processed using a preset information template to obtain user data.

16. The method according to claim 15, wherein, The preset information template includes at least one field. The process of unifying the first user information using a preset information template to obtain user data includes: For each of at least one field, if it is determined that the first user information includes field data for that field, the field data is extracted and added to the preset information template to obtain the user data.

17. The method according to claim 1, wherein, The step of logging into the target application using the target application account includes: The second user information of the user is obtained based on the target application account, wherein the second user information includes the user's information stored in the target application; The target application account is verified based on the second user information. If the target application account is successfully verified, the user logs into the target application.

18. A login device, applied to a target application, wherein, The target application includes a login entry point with at least one identity source, the identity source representing a loginable application other than the target application; the device includes: The acquisition module is used to acquire preset configuration information for the target identity source in response to the user selecting the login entry of at least one identity source. An execution module is used to execute a login authentication process corresponding to the login method of the target identity source according to the preset configuration information, wherein the target identity source authenticates the user's login information to obtain first user information; The determination module is configured to determine the user's target application account for the target application in response to the first user information from the target identity source, so as to log in to the target application using the target application account.

19. An electronic device comprising: One or more processors; Memory, used to store one or more programs. Wherein, when the one or more programs are executed by the one or more processors, the one or more processors implement the method of any one of claims 1 to 17.

20. A computer-readable storage medium having stored thereon executable instructions that, when executed by a processor, cause the processor to perform the method of any one of claims 1 to 17.

21. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1 to 17.

Images