[feat](authentication): add fe-authentication modules (api/spi/handler/plugins)

[CalvinKirs]

Doris FE Authentication (fe-authentication)

This directory contains the modular authentication stack for Doris FE. It defines protocol-agnostic
models, a plugin SPI, a handler/orchestrator, and built-in plugin stubs. In the current phase, there
are no changes in fe-core; the handler is intentionally independent and can run with in-memory
registries.

For the full design rationale and details, see auth.md.

#60361

Scope and status (Phase 1)

Implemented now:

• Protocol-agnostic request/response models (AuthenticationRequest, AuthenticationResult).
• Core domain models (AuthenticationProfile, AuthenticationBinding, Principal, Identity, Subject).
• Plugin SPI with lifecycle hooks (validate/initialize/healthCheck/reload/close).
• Handler orchestration (AuthenticationService, BindingResolver, PluginManager).
• In-memory registries (ProfileRegistry, BindingRegistry).
• Built-in plugin skeletons (Password plugin is present but not wired to fe-core).

Not yet wired (planned):

• fe-core integration (user/role/audit/persistence).
• Protocol adapters (MySQL/PG/HTTP/Flight) to construct AuthenticationRequest.
• DDL and persistence for profiles/bindings.
• Real implementations for LDAP/OIDC/Kerberos/X509/JWT plugins.
• External plugin packaging and hot-reload tooling.

Module layout

• fe-authentication-api
  • Domain models and request/identity objects.
• fe-authentication-spi
  • Authentication plugin SPI (AuthenticationPlugin, AuthenticationPluginFactory, AuthenticationResult).
• fe-authentication-handler
  • Orchestration logic: profile/binding selection, plugin lifecycle, request processing.
• fe-authentication-plugins
  • Built-in plugins (currently Password plugin stub).
• fe-extension-spi / fe-extension-loader
  • Shared plugin framework and classloader support for external extensions.

Architecture (current)

Dependency graph (compile-time):

fe-extension-spi/loader  ->  fe-authentication-handler / fe-authentication-plugins

fe-authentication-api  <-- fe-authentication-spi  <-- fe-authentication-handler  <-- fe-core (future)
                         ^                               ^
                         |                               |
                 fe-authentication-plugins  --------------

Runtime flow (simplified):

Protocol Adapter
   -> AuthenticationRequest
      -> AuthenticationService
         -> BindingResolver (ProfileRegistry + BindingRegistry)
         -> PluginManager (AuthenticationPluginFactory / AuthenticationPlugin)
         -> AuthenticationOutcome (Subject + AuthenticationResult)

Profile selection order

1. User binding (explicit)
2. Requested profile (AuthenticationRequest.requestedProfile or request properties
   auth_profile / requested_profile)
3. Default bindings
4. System default password profile (AuthenticationProfile.createDefault())

If a profile is disabled and the binding is mandatory, resolution fails; otherwise it falls back.

Developer usage (today)

1) Create profiles and bindings

ProfileRegistry profiles = new ProfileRegistry();
profiles.register(AuthenticationProfile.createDefault());

AuthenticationProfile ldap = AuthenticationProfile.builder()
        .name("corp_ldap")
        .pluginType(AuthenticationPluginType.LDAP)
        .enabled(true)
        .priority(10)
        .configProperty("ldap_server", "ldap://ldap.example.com:389")
        .configProperty("ldap_base_dn", "dc=example,dc=com")
        .mapRole("developers", "dev_role")
        .build();
profiles.register(ldap);

BindingRegistry bindings = new BindingRegistry();
bindings.putUserBinding("alice",
        new AuthenticationBinding(AuthenticationBinding.BindingType.USER,
                "alice", "corp_ldap", 1, false));

2) Build request and authenticate

PluginManager pluginManager = new PluginManager();
BindingResolver resolver = new BindingResolver(profiles, bindings);
AuthenticationService service = new AuthenticationService(profiles, pluginManager, resolver);

AuthenticationRequest request = AuthenticationRequest.builder()
        .username("alice")
        .credentialType(CredentialType.CLEAR_TEXT_PASSWORD)
        .credential("secret".getBytes(StandardCharsets.UTF_8))
        .protocol("mysql")
        .requestedProfile("corp_ldap")
        .build();

AuthenticationOutcome outcome = service.authenticateWithOutcome(request);

Notes:

• PluginManager uses ServiceLoader to discover AuthenticationPluginFactory on the classpath.
  Provide META-INF/services/org.apache.doris.authentication.spi.AuthenticationPluginFactory in
  plugin jars to enable discovery.
• The built-in Password plugin currently throws AuthenticationException because fe-core wiring
  is not done yet.

Plugin development (SPI)

Implement:

• AuthenticationPlugin (business logic, supports/validate/initialize/authenticate)
• AuthenticationPluginFactory (creates plugin instances)

ServiceLoader file:

META-INF/services/org.apache.doris.authentication.spi.AuthenticationPluginFactory

External plugin packaging (planned):

plugin-name/
  plugin.properties
  plugin.jar
  lib/

plugin.properties fields (recommended):

name = ldap
version = 1.0.0
spiVersion = 1
factoryClass = org.apache.doris.authentication.plugins.LdapPluginFactory

Classloader rules (planned):

• Parent-first: java.*, logging, and Doris SPI/API packages
• Child-first: plugin packages and private dependencies

Planned user experience (future)

Proposed DDL (subject to final syntax):

CREATE AUTHENTICATION PROFILE corp_ldap
  PLUGIN = 'ldap'
  PROPERTIES (
    'ldap_server' = 'ldap://ldap.example.com:389',
    'ldap_base_dn' = 'dc=example,dc=com'
  )
  ROLE_MAPPING (
    'developers' = 'dev_role'
  )
  JIT_USER_ENABLED = true
  PRIORITY = 10;

ALTER USER alice BIND AUTHENTICATION PROFILE corp_ldap;
CREATE AUTHENTICATION BINDING DEFAULT USING __default_password__ PRIORITY 100;

Multi-step authentication:

• Plugins may return AuthenticationResult.CONTINUE with challenge data.
• Protocol adapters will forward the challenge and resume with authState and credential.

Integration plan (future adaptation)

• fe-core adapter layer:
  • Password validation will reuse existing password logic.
  • User creation/JIT and role resolution will use fe-core managers.
  • Audit events will be emitted by the handler.
• Protocol adapters:
  • Convert protocol-specific packets into AuthenticationRequest.
  • Handle challenge/response for multi-step flows.
• Persistence:
  • Profiles and bindings stored in edit log/metadata and exposed to handler registries.

Compatibility and migration

• Default password profile keeps existing password auth behavior once wired.
• New profiles can be rolled out incrementally without changing protocol code.

[Thearas]

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?