CalvinKirs opened a new issue, #69944: URL: https://github.com/apache/doris/issues/69944
### Description ADBC clients connecting to Doris through Arrow Flight SQL should use the same extensible authentication framework as other SQL clients. Authentication methods and identity policies should be supplied by configured authentication integrations and plugins rather than hardcoded into the Flight SQL path. Today, `FlightAuthUtils.authenticateCredentials()` calls `Auth.checkPlainPassword()` directly, and `FlightBearerTokenAuthenticator` fixes initial authentication to `BasicCallHeaderAuthenticator`. This bypasses the unified integration selection and identity mapping flow. In addition, `FlightAuthResult` carries only the username, user identity and remote IP, so it cannot propagate the complete authentication outcome into the Flight session. ### Proposed behavior Extract a protocol-independent authentication entry point from the existing SQL authentication flow and let the Flight SQL adapter call it. Keep protocol credential extraction, handshake responses and Flight session-token handling in the adapter; keep authentication policy in the shared framework. The shared flow should: - Resolve explicit user bindings using the existing username and host matching rules. Authenticate only through the bound integration and enforce its external identity binding. A failed bound authentication must not fall back to another integration or JIT. - For users without a binding, follow the existing authentication selection and chain rules. After successful authentication, reuse an eligible existing Doris identity; use a temporary JIT identity only when the selected integration enables it and no matching identity exists. - Reuse existing credential validation, Principal construction and role mapping through the configured integration/plugin. Adding an authentication method should not require a new method-specific branch in Flight SQL core code. - Apply the same shared post-authentication checks and session initialization as other SQL clients. Preserve the full outcome, including the resolved identity, temporary-user flag, Principal, authenticated roles, binding information and credential expiration/delegation where applicable. The Flight adapter should distinguish incoming authentication credentials from Doris-issued session tokens and establish a Flight session only after the shared authentication flow succeeds. ### Acceptance criteria - MySQL and Flight SQL use the same shared authentication policy and identity mapping implementation; neither protocol adapter duplicates integration selection, JIT or role mapping. - Configured authentication plugins can be reached from Flight SQL when the adapter can represent their required credentials. - Coverage verifies bound integration selection and identity matching, rejection without fallback, unbound authentication chains, existing-user mapping, JIT enabled/disabled, and propagation of roles and authentication context into the Flight session. - Existing username/password clients and Doris-issued Flight session tokens continue to work. ### Related issues - #67578 — Arrow Flight SQL server and official Doris ADBC driver tracking. - #65615 — Arrow Flight SQL and ADBC Catalog tracking. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
