Skip to content

Conversation

@CalvinKirs
Copy link
Member

CalvinKirs and others added 2 commits June 30, 2025 11:20
## abstract
introduces the pluginization of the Authenticator component, enabling
greater flexibility and modularity within the authentication system. By
refactoring the Authenticator into a pluggable SPI (Service Provider
Interface), we allow for custom authentication mechanisms to be
seamlessly integrated and managed.

## Key Changes
AuthenticatorFactory Interface:

This interface defines the create method, which is used to create an
Authenticator instance based on initialization properties, enabling
support for various authentication mechanisms.
The factoryIdentifier method provides an identifier for the factory,
allowing differentiation between various AuthenticatorFactory
implementations (e.g., LDAP, default).
Implemented Specific Authentication Factories:

We have implemented factories for different authentication mechanisms
(such as LDAP), providing the necessary configuration support for each.

## eg

In your Maven pom.xml, add the fe-core dependency:

```
        <dependency>
            <groupId>org.apache.doris</groupId>
            <artifactId>fe-core</artifactId>
            <version>1.2-SNAPSHOT</version>
            <scope>provided</scope>
        </dependency>

```

```
import org.apache.doris.common.ConfigBase;

public class LocalAuthenticatorFactory implements AuthenticatorFactory {

    @OverRide
    public LocalAuthenticator create(Properties initProps) {
        return new LocalAuthenticator();
    }

    @OverRide
    public String factoryIdentifier() {
        return "local";
    }
}
import java.util.HashMap;
import java.util.Map;

public class LocalAuthenticator implements Authenticator {
    private Map<String, String> userStore = new HashMap<>();

    public LocalAuthenticator() {
        // Hardcoded usernames and passwords
        userStore.put("user1", "password1");
        userStore.put("user2", "password2");
        userStore.put("admin", "adminpass");
    }

    @OverRide
    public boolean authenticate(String username, String password) {
        // Authenticate by checking the hardcoded user store
        String storedPassword = userStore.get(username);
        return storedPassword != null && storedPassword.equals(password);
    }
}

```
To integrate with the SPI (Service Provider Interface) mechanism, we
created a file at
**src/main/resources/META-INF/services/org.apache.doris.mysql.authenticate.AuthenticatorFactory**
containing **org.example.LocalAuthenticatorFactory,** which allows the
system to dynamically load and utilize the LocalAuthenticatorFactory
implementation.

Your plugin needs to include all necessary dependencies, and it is
generally recommended to package them into an Uber JAR (also known as a
Fat JAR) to ensure that the plugin can run independently without
additional dependency management. Once packaged, this JAR can be placed
directly in the **fe/custom_lib** directory.

(cherry picked from commit 119ea59)
### What problem does this PR solve?
The `defaultAuthenticator` is not initialized. When a configured
authentication plugin implements the `canDea`l method and returns
`false`, the `defaultAuthenticator` will be used, resulting in a login
failure. The client exception message is `RROR 2013 (HY000): Lost
connection to MySQL server at 'reading authorization packet', system
error: 2`. This issue only affects users who use non-built-in
authentication plugins that implement `canDeal` and return false under
certain circumstances.

apache#40113 introduced this issue
(cherry picked from commit dd0c2d8)
@CalvinKirs CalvinKirs requested a review from morrySnow as a code owner June 30, 2025 03:23
@hello-stephen
Copy link
Contributor

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

  1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
  2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
  3. What features were added. Why was this function added?
  4. Which code was refactored and why was this part of the code refactored?
  5. Which functions were optimized and what is the difference before and after the optimization?

@CalvinKirs
Copy link
Member Author

run buildall

@CalvinKirs
Copy link
Member Author

run external

@morrySnow morrySnow merged commit 156d1ac into apache:branch-3.1 Jul 1, 2025
20 of 24 checks passed
@CalvinKirs CalvinKirs deleted the branch-3.1-40113 branch July 1, 2025 06:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants