Identity authentication method for distributed database clusters

Abstract

The present invention discloses an identity authentication method for distributed database clusters, belonging to the field of database security. The method comprises setting one host in the cluster as an authentication proxy server; the authentication proxy server receives proxy authentication requests from hosts in other clusters; the other hosts transmit the authentication information of the user currently attempting to log in to the authentication proxy server as a proxy authentication request; the authentication proxy server processes the current proxy authentication request through its own authentication system and feeds back the authentication result to the other hosts; after receiving the authentication result, the other hosts determine whether to allow the current user to log in based on the authentication result. Compared with existing database authentication methods, the use of an authentication proxy allows the authentication system to be shared with other systems while retaining the existing authentication process, allowing the distributed database clusters to share the same set of authentication processes. At the same time, the cluster responsible for the authentication proxy can continue to retain the functions of the database itself.

Description

Technical Field

[0001] The present invention relates to the field of database security, and more specifically, to an identity authentication method for distributed database clusters. Background Art

[0002] Mainstream database products, including MySQL and Oracle, all have mature, universal user authentication solutions, such as GSSAPI and LDAP. However, these solutions lack a standardized configuration format, or authentication systems are difficult to share, requiring operations and maintenance personnel to configure multiple parameters and perform repetitive configuration. In a clustered database, the database authentication module collects user-entered credentials, such as username and password, and forwards them to other authentication systems based on the authentication method. The system then waits for the response to determine whether the user is allowed to log in to the database. Authentication systems are categorized as local authentication or external authentication, depending on whether the workstation and the authenticated system (database) are on the same host. For example, local authentication for the database and operating system are local authentication, while LDAP is external authentication. Local authentication offers the advantage of speed, but data cannot be shared; external authentication offers the advantage of data sharing. However, each authentication method has unique parameters, making a universal configuration process difficult. Some authentication methods, such as local authentication for databases, are dependent on the local environment, making them difficult to share or implement in high availability (HA) scenarios. Therefore, it is necessary to design a new authentication approach specifically for distributed database clusters. Summary of the Invention

[0003] One of the purposes of the present invention is to address the shortcomings and provide an identity authentication method for distributed database clusters, in the hope of solving technical problems in the existing technology such as the difficulty in forming a universal configuration process, difficulty in sharing, and difficulty in constructing HA scenarios.

[0004] In order to solve the above technical problems, the present invention adopts the following technical solutions.

[0005] The present invention provides an identity authentication method for distributed database clusters, which includes the following steps.

[0006] Step A: Set a host in the distributed database cluster as an authentication proxy server; and have the authentication proxy server receive proxy authentication requests from hosts in other distributed database clusters.

[0007] Step B: The host in the other distributed database cluster transmits the authentication information of the user currently attempting to log in as the proxy authentication request to the authentication proxy server.

[0008] Step C: The authentication proxy server processes the current proxy authentication request through its own authentication system and feeds back the authentication result to the other host. Upon receiving the proxy authentication request, the authentication proxy server first reads the host name list from the driver's custom properties and determines whether the host name list contains the authentication proxy server's local name. If so, it returns an authentication failure; otherwise, it continues processing the current proxy authentication request.

[0009] Step D: After receiving the authentication result, the other hosts determine whether to allow the current user to log in based on the authentication result.

[0010] As a preferred embodiment, a further technical solution is that: a blacklist and / or a whitelist is provided in the authentication proxy server, and hosts using the authentication proxy in the other distributed database clusters are filtered through the blacklist and / or the whitelist.

[0011] A further technical solution is that before transmitting the proxy authentication request to the authentication proxy server, the host in the other distributed database cluster first performs IP filtering on the user currently attempting to log in, and then transmits the proxy authentication request after the IP filtering passes, otherwise the login fails.

[0012] A further technical solution is: after other hosts receive the authentication result, if the authentication is successful, they further determine whether the user currently trying to log in is locked out. If not, the authentication is deemed successful by default, otherwise the login fails.

[0013] A further technical solution is: the host set as the authentication proxy server in the distributed database cluster, and other hosts all include other authentication means in addition to proxy authentication, and the other authentication means include any one or more of LDAP authentication, Kerberos authentication, PAM pluggable authentication module, and GSSAPI authentication; the hosts in the distributed database cluster nest the other authentication means with proxy authentication.

[0014] Compared with the existing technology, one of the beneficial effects of the present invention is: compared with the existing database authentication method, the use of an authentication agent can share the authentication system with other systems while retaining the existing authentication process, so that the same set of authentication processes can be shared among distributed database clusters. Moreover, since the distributed database itself is easy to configure HA, the host responsible for the authentication agent can also enjoy the advantages of multi-active, and at the same time, the cluster responsible for the authentication agent can continue to retain the functions of the database itself. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 A flowchart illustrating a method according to an embodiment of the present invention. DETAILED DESCRIPTION

[0016] This invention provides a new authentication method based on existing database authentication methods. This approach leverages existing databases, allowing one or more hosts in a cluster to use their own authentication system to concurrently provide authentication proxy services for other hosts in the cluster or for other clusters. Clusters performing proxy authentication continue to use their existing authentication configurations, making them independent from one another. This external authentication allows for simultaneous authentication across multiple clusters. Furthermore, the clusters themselves configure HA (High Availability) authentication proxying to provide a multi-active environment. Because authentication is a fast and independent operation, it does not significantly impact performance or functionality.

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

[0018] refer to Figure 1 As shown, one embodiment of the present invention is an identity authentication method for distributed database clusters, which is implemented by the following steps:

[0019] S1. Set a host in the distributed database cluster as an authentication proxy server; and have the authentication proxy server receive proxy authentication requests from hosts in other distributed database clusters.

[0020] S2. The host in the other distributed database cluster transmits the authentication information of the user currently attempting to log in as the proxy authentication request to the authentication proxy server.

[0021] In this step, preferably, the host in the other distributed database cluster first performs IP filtering on the user currently attempting to log in before transmitting the proxy authentication request to the authentication proxy server. The proxy authentication request is transmitted only after the IP filtering passes, otherwise the login fails.

[0022] S3. The authentication proxy server processes the current proxy authentication request through its own authentication system and feeds back the authentication result to other hosts.

[0023] In this step, when the above-mentioned authentication proxy server receives the above-mentioned proxy authentication request, it first reads the host name list from the custom properties of the driver, and determines whether the above-mentioned host name list contains the local name of the authentication proxy server. If the judgment result is yes, it returns authentication failure, otherwise it continues to process the current proxy authentication request.

[0024] Furthermore, a blacklist and / or a whitelist may be pre-set in the authentication proxy server, and the hosts using the authentication proxy in the distributed database cluster may be filtered through the blacklist and / or the whitelist.

[0025] S4. After receiving the above authentication result, other hosts determine whether to allow the current user to log in based on the above authentication result.

[0026] As mentioned above, the design of proxy authentication in the present invention does not affect the original authentication method of the database cluster. Therefore, in the distributed database cluster referred to above in this embodiment, the host configured as the authentication proxy server and other hosts all include other authentication means in addition to proxy authentication. The other authentication means include LDAP authentication, Kerberos authentication, PAM pluggable authentication module, GSSAPI authentication, etc. In practice, the hosts in the above distributed database cluster can nest the other authentication means with proxy authentication. For details, see Figure 1 The process shown.

[0027] Based on the above embodiments of the present invention, it can be seen that the technical problems that need to be solved when implementing the authentication method provided by the present invention are as follows.

[0028] First, distinguish between normal login and authentication proxy. It is necessary to distinguish between authentication proxy and normal login. The authentication proxy action only needs to use the authentication interface of the target host to determine the correctness of the user credentials to be authenticated, and does not continue the login, avoiding access to the authentication proxy cluster itself.

[0029] Second, how does the original cluster perform authentication? The new authentication method provided by this invention is consistent with existing authentication methods and presents itself as a new authentication method. The original cluster only needs to configure the authentication method as an authentication proxy and add return value processing to the software code. The authentication action only affects the authentication operation and does not affect other functions.

[0030] The third issue is how to handle loopbacks. Loopbacks caused by misconfiguration when configuring an authentication proxy must be avoided. This occurs when the configured authentication proxy server directly or indirectly points to itself, creating an infinite loop. Therefore, before the originating host initiates an authentication proxy action, it should include source verification information, such as the sender's hostname, in the data it sends. When the receiving host receives the authentication proxy request, it checks whether the source hostname contains its own. If so, it considers the request a loopback and returns an authentication error.

[0031] Through the above embodiments and technical problems, more technical details of the present invention are as follows.

[0032] A new authentication type is added, parallel to the existing authentication method, to indicate a new authentication method. An option is added to indicate whether the current host can operate as an authentication proxy cluster. A host can both serve as an authentication proxy server and be configured to use an authentication proxy, as long as the authentication proxy configuration does not directly or indirectly point to its own address, causing a loopback. When the authentication method is set to use an authentication proxy, the IP and port of the cluster acting as the authentication proxy must also be configured. When acting as an authentication proxy server, configuration options can be added to provide blacklists and whitelists for filtering sources using the authentication proxy.

[0033] The cluster is configured to use an authentication proxy. When a user logs in and the code executes the authentication interface, basic IP filtering is performed first, as the user is logging into the current cluster. After passing the filtering, the authentication method is selected. If proxy authentication is used, the standard ODBC interface is used to attempt to log in to the proxy cluster using the user-entered credentials. A special flag must be set to indicate that this login is using a proxy authentication. The user's identity must also be identified, for example, by encoding the host name in Base64 format and entering it into a custom property of the ODBC driver to indicate the source.

[0034] When a host in a cluster is configured as an authentication proxy server, it can accept authentication proxy requests. Other hosts that are not configured will simply reject requests. After determining that the current login operation is an authentication proxy action based on a special flag sent by the driver, some checks, including IP filtering and user existence checks, are skipped. This is because the authentication proxy only verifies the validity of user credentials and does not formally log in. Since the host initiating the authentication proxy action is not the actual user but the host being logged into, any IP filtering should be performed by the initiating host (the host being logged into), not the host currently performing the authentication proxy action. For similar reasons, a user may not be registered with the authentication proxy cluster. In this case, the authentication proxy cluster is only used to verify user credentials, ignoring their non-existence (unless the authentication proxy host uses local database authentication, in which case the user must also be registered with the proxy authentication cluster). Finally, even if the user being authenticated is locked out of the authentication proxy cluster, authentication will proceed without generating a locked-out error.

[0035] To prevent loops in the authentication proxy process, when the authentication proxy cluster receives an authentication proxy request, it first retrieves the base64-encoded list of source host names from the driver's custom properties and compares it with the local host name to determine if it contains a valid host name. If a loop occurs, an authentication failure is immediately returned. If the local host needs to forward the authentication proxy operation, the local host name is also appended to the host name list in the received authentication proxy request before forwarding it and sending it again.

[0036] Because authentication doesn't involve other database functions, there's no requirement for the versions of either authentication server. A new version can authenticate an older version, and vice versa. The host performing the authentication proxy still functions as a database, with proxy authentication being used only part-time. To prevent abuse, the proxy host can configure blacklists and whitelists to filter sources.

[0037] Based on the general form of computer software products, another embodiment of the present invention provides a computer-readable storage medium, which stores instructions. When a computer executes the instructions, the computer executes the identity authentication method for distributed database clusters in the above embodiment.

[0038] Among them, the computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination thereof. More specific examples (non-exhaustive list) of computer-readable storage media include: an electrical connection with one or more wires, a portable computer disk, a hard disk, RAM, ROM, erasable programmable read-only memory (EPROM), a register, a hard disk, an optical fiber, a CD-ROM, an optical storage device, a magnetic storage device, or any suitable combination of the above, or any other form of computer-readable storage medium known in the art. An exemplary storage medium is coupled to a processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be an integral part of the processor. The processor and the storage medium can be located in an application-specific integrated circuit (ASIC). In the embodiments of the present application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, device or device.

[0039] In addition to the above, it should be noted that references to "one embodiment," "another embodiment," "an embodiment," and the like in this specification refer to specific features, structures, or characteristics described in conjunction with that embodiment as included in at least one embodiment generally described in this application. The appearance of the same expression in multiple places in the specification does not necessarily refer to the same embodiment. Furthermore, when a specific feature, structure, or characteristic is described in conjunction with any embodiment, it is intended that such feature, structure, or characteristic, when implemented in conjunction with other embodiments, also falls within the scope of the present invention.

[0040] Although the present invention has been described herein with reference to a number of illustrative embodiments thereof, it will be understood that numerous other modifications and implementations may be devised by those skilled in the art that fall within the scope and spirit of the principles disclosed herein. More specifically, within the scope of the present disclosure, the drawings, and the claims, numerous variations and modifications may be made to the components and / or layout of the subject combination arrangement. In addition to variations and modifications to the components and / or layout, other uses will also be apparent to those skilled in the art.

Claims

1. A method for identity authentication between distributed database clusters, characterized in that The method comprises the following steps: Setting a host in the distributed database cluster as an authentication proxy server; having the authentication proxy server receive proxy authentication requests from hosts in other distributed database clusters; The host in the other distributed database cluster transmits the authentication information of the user currently attempting to log in as the proxy authentication request to the authentication proxy server; the proxy authentication request includes the host name of the current host; The authentication proxy server processes the current proxy authentication request through its own authentication system and feeds back the authentication result to other hosts; After receiving the authentication result, other hosts determine whether to allow the current user to log in based on the authentication result; When receiving the proxy authentication request, the authentication proxy server first reads the host name list from the driver's custom properties and determines whether the host name list contains the local name of the authentication proxy server. If the judgment result is yes, it returns authentication failure; otherwise, it continues to process the current proxy authentication request; After receiving the authentication result, if the authentication is successful, other hosts further determine whether the user currently attempting to log in is locked out. If not, the authentication is deemed successful by default, otherwise the login fails.

2. The identity authentication method for distributed database clusters according to claim 1, characterized in that: The authentication proxy server is provided with a blacklist and / or a whitelist, and the hosts using the authentication proxy in the other distributed database clusters are filtered through the blacklist and / or the whitelist.

3. The identity authentication method for distributed database clusters according to claim 1, characterized in that: Before transmitting the proxy authentication request to the authentication proxy server, the host in the other distributed database cluster first performs IP filtering on the user currently attempting to log in. If the IP filtering passes, the proxy authentication request is transmitted. Otherwise, the login fails.

4. The identity authentication method for distributed database clusters according to claim 1, characterized in that: The host set as the authentication proxy server and other hosts in the distributed database cluster all include other authentication means in addition to proxy authentication, and the other authentication means include any one or more of LDAP authentication, Kerberos authentication, PAM pluggable authentication module, and GSSAPI authentication; the hosts in the distributed database cluster nest the other authentication means with proxy authentication.

5. A computer-readable medium, characterized in that: The computer-readable storage medium stores instructions, and when a computer executes the instructions, the computer executes the method according to any one of claims 1 to 4.

Images