[feature](fe) Integrate OIDC authentication, MySQL login bridge, and role mapping#61819
Conversation
### What problem does this PR solve?
Issue Number: None
Related PR: None
Problem Summary: Move AuthIntegration role mapping into the successful authentication runtime path so granted roles are computed once during authentication and downstream authenticators only propagate the result.
### Release note
None
### Check List (For Author)
- Test: Attempted `./run-fe-ut.sh --run org.apache.doris.authentication.AuthenticationIntegrationRuntimeTest`, `./run-fe-ut.sh --run org.apache.doris.mysql.authenticate.integration.AuthenticationIntegrationAuthenticatorTest`, `./run-fe-ut.sh --run org.apache.doris.mysql.authenticate.AuthenticatorManagerTest`
- Unit Test (blocked by existing FE build issues: concurrent cache restore collisions, then fe-core pattern generator failure `NoClassDefFoundError: org.apache.doris.nereids.pattern.generator.javaast.TypeBound`)
- Behavior changed: Yes (role mapping is now computed in `AuthenticationIntegrationRuntime` immediately after successful authentication, while `AuthenticationIntegrationAuthenticator` only propagates granted roles)
- Does this need documentation: No
### What problem does this PR solve? Issue Number: close #xxx Related PR: #xxx Problem Summary: Define the approved design for porting CREATE/DROP ROLE MAPPING into the current OIDC branch, removing property-backed production role mapping, and adding the minimum MySQL OIDC login bridge needed to reach the existing OIDC plugin. ### Release note None ### Check List (For Author) - Test: No need to test (design document only) - Behavior changed: No - Does this need documentation: No
### What problem does this PR solve?
Issue Number: None
Related PR: None
Problem Summary: Port CREATE ROLE MAPPING and DROP ROLE MAPPING into FE metadata, switch runtime evaluation to metadata-backed role mappings, advertise the MySQL capability flags required by OIDC clients, and propagate authenticated roles into session privilege checks so OIDC logins receive mapped roles end to end.
### Release note
Support metadata-backed role mappings for authentication integrations and apply mapped roles during OIDC MySQL login.
### Check List (For Author)
- Test: FE unit tests
- ./run-fe-ut.sh --run org.apache.doris.nereids.parser.RoleMappingParserTest,org.apache.doris.authentication.RoleMappingMgrTest,org.apache.doris.authentication.AuthenticationIntegrationMgrTest,org.apache.doris.authentication.AuthenticationIntegrationRuntimeTest,org.apache.doris.mysql.MysqlCapabilityTest,org.apache.doris.mysql.MysqlHandshakePacketTest,org.apache.doris.mysql.MysqlAuthPacketTest,org.apache.doris.mysql.authenticate.password.ClearPasswordResolverTest,org.apache.doris.mysql.authenticate.AuthenticatorManagerTest,org.apache.doris.mysql.authenticate.integration.AuthenticationIntegrationAuthenticatorTest,org.apache.doris.authentication.handler.AuthenticationServiceTest,org.apache.doris.authentication.handler.OidcAuthenticationServiceTest,org.apache.doris.mysql.privilege.AuthTest
- Behavior changed: Yes (OIDC login now consumes metadata-backed role mappings and session-mapped roles)
- Does this need documentation: No
### What problem does this PR solve? Issue Number: None Related PR: None Problem Summary: Prevent FE from throwing a null pointer when a client closes the MySQL connection during handshake, and preserve the original OIDC token when password auth falls back to authentication_chain so the fallback authenticator can still use the client-provided token. ### Release note Improve FE MySQL authentication error handling and OIDC fallback behavior. ### Check List (For Author) - Test: No test run (per user request; added FE unit tests but did not execute them) - Behavior changed: Yes (handshake failures now return a clear error instead of a null pointer; OIDC fallback reuses the original token) - Does this need documentation: No
### What problem does this PR solve? Issue Number: None Related PR: None Problem Summary: Re-enable edit log persistence for create, alter, and drop operations in AuthenticationIntegrationMgr so authentication integration metadata changes participate in FE journal replay again. ### Release note None ### Check List (For Author) - Test: No need to test (per user request in this session) - Behavior changed: Yes (authentication integration DDL now writes edit log records again) - Does this need documentation: No
### What problem does this PR solve? Issue Number: None Related PR: None Problem Summary: Add temporary FE-side logging around MySQL OIDC auth packet decoding and token bridging so we can determine whether the incoming mysqlsh token still contains a length-encoded prefix or is being transformed before OIDC validation. ### Release note None ### Check List (For Author) - Test: No need to test (debug-only instrumentation requested by user; user asked not to run tests) - Behavior changed: Yes (adds temporary INFO logs for OIDC MySQL authentication flow only) - Does this need documentation: No
### What problem does this PR solve?
Issue Number: None
Related PR: None
Problem Summary: Move MySQL OIDC auth-packet parsing out of ClearPasswordResolver and make packet-aware credential resolution explicit for integration and plugin authenticators.
### Release note
None
### Check List (For Author)
- Test: No test run (per user request)
- No test execution requested by the user in this session
- Behavior changed: Yes (direct plugin-based OIDC auth now consumes credentials from the initial MySQL auth packet through an explicit resolver path)
- Does this need documentation: No
… role mapping
The core changes are:
1. Add MySQL protocol-layer support for OIDC login
- bridge OIDC credentials carried in the MySQL authentication packet into Doris authentication requests
- allow OIDC-based external login to enter the FE authentication pipeline through the MySQL protocol path
2. Add ROLE MAPPING for built-in authorization
- introduce role mapping so external authenticated identities can be mapped to Doris built-in roles
- support using external identity attributes/groups to drive internal authorization decisions
3. Integrate the authentication feature modules into FE
- wire the authentication plugin/integration modules into the FE runtime
- connect external authentication, JIT/external login, and built-in role authorization into one complete flow
With these changes, Doris can accept OIDC-based external logins from the MySQL protocol entry, authenticate them through the integrated authentication modules, and apply Doris-native authorization
through ROLE MAPPING.
### Release note
Support OIDC-based external login through the MySQL protocol and add ROLE MAPPING for Doris built-in authorization.
…mapping-oidc # Conflicts: # fe/fe-core/src/main/java/org/apache/doris/persist/meta/PersistMetaModules.java
### What problem does this PR solve?
Issue Number: None
Related PR: None
Problem Summary: Remove the OIDC authentication plugin module and the role-mapping OIDC bridge design spec from this branch so the PR only keeps the MySQL protocol credential bridge and role-mapping related FE integration work.
### Release note
None
### Check List (For Author)
- Test: No test run (per user request)
- No test execution requested in this session
- Behavior changed: Yes (this branch no longer submits the OIDC plugin module or the design spec; MySQL protocol-layer OIDC credential adaptation remains)
- Does this need documentation: No
|
/review |
|
run buildall |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
### What problem does this PR solve?
Issue Number: None
Related PR: None
Problem Summary: Address review blockers in the OIDC login and role mapping integration by including the MySQL auth packet OIDC credential extractor in fe-core, fixing role mapping metadata image persistence, aligning lock ordering between authentication integration and role mapping managers, avoiding null role materialization in Auth, using the command context consistently for DROP ROLE MAPPING privilege checks, and making evaluator cache refresh atomic.
### Release note
Fix role mapping metadata persistence and stabilize fe-core OIDC login integration.
### Check List (For Author)
- Test: No test run (per request)
- No unit test or regression test was executed
- Behavior changed: Yes
- Role mappings are now included in image save/load and fe-core OIDC credential extraction is committed with the protocol bridge
- Does this need documentation: No
|
/review |
|
run buildall |
There was a problem hiding this comment.
Code Review Summary: OIDC Authentication, MySQL Login Bridge, and Role Mapping
This PR adds OIDC authentication support via the MySQL protocol, role mapping based on CEL expressions, and wires these into the FE authentication pipeline. The architecture is well-structured with clear separation between metadata management, runtime plugin management, and role mapping evaluation. The EditLog/persistence paths are correctly symmetric, and test coverage is good.
However, I found several issues that should be addressed before merging:
Critical Checkpoint Conclusions
1. Goal Accomplishment: The code accomplishes the stated goals of OIDC login bridge, role mapping, and integration. Tests cover the main paths.
2. Concurrency:
- BUG (High):
Auth.doesRoleExist()accessesroleManagerwithoutAuth's read lock — data race. Called fromRoleMappingMgr.normalizeGrantedRoles()which does not holdAuth's lock. - BUG (High): Deadlock risk from inconsistent lock ordering between
AuthenticationIntegrationMgr(write lock → callsRoleMappingMgr.hasRoleMapping()) andRoleMappingMgr.createRoleMapping()(IntegrationMgr read lock → own write lock). Classic ABBA pattern. - Issue (Medium):
ThreadLocal-based CEL context passing inUnifiedRoleMappingCelEngineis non-reentrant and fragile if CEL ever delegates to another thread.
3. Lifecycle Management:
- Issue (Medium): Image load replaces
authenticationIntegrationMgrbut never resetsAuthenticationIntegrationRuntime— stale cached plugins persist. - Dead Code:
replayUpsertAuthenticationIntegration()andrebuildAuthenticationIntegrations()exist but are never called.
4. EditLog Replay Correctness:
- BUG (Medium): ALTER/DROP authentication integration replay updates only metadata, not the runtime. Followers retain stale plugins. The master-side DDL path correctly updates the runtime (dirty flag / removal), but the replay path does not.
5. Incompatible Changes:
- Issue (Medium):
MAPPING,CEL, andRULEare not in thenonReservedrule inDorisParser.g4, making them reserved keywords. This breaks any existing queries using these words as unquoted identifiers.
6. Code Quality:
- Issue (Medium):
main(),runMultipleMatchDemo(), andDemoResultclass left in productionUnifiedRoleMappingCelEngine. Should be in test code only. - Issue (Low): Defensive null checks on
Env.getCurrentEnv()inAuthenticationIntegrationRuntimeshould be assertions per coding standard.
7. Configuration: No new configuration items requiring dynamic change support.
8. Parallel Code Paths: N/A for this feature.
9. Test Coverage: Good unit test coverage for the new modules. Role mapping, CEL engine, auth service chain, and parser rules are all tested. Missing: no regression test for the end-to-end SQL flow (CREATE ROLE MAPPING / DROP ROLE MAPPING).
10. Observability: No logging in the CEL evaluation path. When role mapping fails due to CEL errors or misconfiguration, there is no log output for diagnosis.
11. Transaction/Persistence: EditLog writes are correctly covered. The replay asymmetry (runtime not updated) is the main concern.
12. FE-BE Variable Passing: N/A — this is FE-only.
13. Performance: Cache entries in IntegrationPropertyRoleMappingEvaluator are never evicted (minor memory leak). No limit on CEL expression complexity or number of rules per integration.
| integrationMgr.readLock(); | ||
| try { | ||
| writeLock(); | ||
| try { |
There was a problem hiding this comment.
[Deadlock Risk - High] Inconsistent lock ordering between AuthenticationIntegrationMgr and RoleMappingMgr:
createRoleMapping(here): acquiresIntegrationMgr.readLock→ thenRoleMappingMgr.writeLockdropAuthenticationIntegration(AuthenticationIntegrationMgr.java:128,136): acquiresIntegrationMgr.writeLock→ then callsRoleMappingMgr.hasRoleMapping()which acquiresRoleMappingMgr.readLock
This is a classic ABBA deadlock pattern. Thread 1 holds IntegrationMgr and waits for RoleMappingMgr; Thread 2 holds RoleMappingMgr and waits for IntegrationMgr.
Fix: Establish a consistent lock ordering. Either always acquire IntegrationMgr lock first, or refactor dropAuthenticationIntegration to check the role mapping constraint before acquiring its own write lock.
| public static void main(String[] args) { | ||
| DemoResult demoResult = runMultipleMatchDemo(); | ||
| System.out.println("=== unified role mapping demo ==="); | ||
| System.out.println("principal: " + demoResult.getContext().getName()); |
There was a problem hiding this comment.
[Code Quality - Medium] main() method and runMultipleMatchDemo() along with the DemoResult class (lines 323-345) are left in production code. This is test/demo code that should not ship in a security-sensitive module. The test class RoleMappingCelPlayground already exists for this purpose.
Fix: Remove main(), runMultipleMatchDemo(), and DemoResult from this production class.
| private static final ThreadLocal<EvaluationContext> CURRENT_CONTEXT = new ThreadLocal<>(); | ||
| private static final CelCompiler COMPILER = createCompiler(); | ||
| private static final CelRuntime RUNTIME = createRuntime(); | ||
|
|
There was a problem hiding this comment.
[Thread Safety - Medium] ThreadLocal-based context passing is fragile:
- Non-reentrancy: If
evaluate()is ever called recursively on the same thread (e.g., via future refactoring), the outer context is silently overwritten and thefinallyblock removes it entirely. - CEL runtime thread delegation: If the CEL runtime internally delegates to a different thread,
CURRENT_CONTEXT.get()returnsnull, causingIllegalStateException.
If the CEL library supports passing context variables through the eval() activation map rather than ThreadLocal, that would be a cleaner and safer pattern.
| @@ -350,6 +354,7 @@ supportedDropStatement | |||
| | DROP WORKLOAD GROUP (IF EXISTS)? name=identifierOrText (FOR computeGroup=identifierOrText)? #dropWorkloadGroup | |||
There was a problem hiding this comment.
[Compatibility - Medium] The tokens MAPPING, CEL, and RULE are used here but are NOT listed in the nonReserved rule (lines 1985-2370). This makes them reserved keywords, meaning any existing user query that uses these words as unquoted identifiers (e.g., SELECT mapping FROM t, CREATE TABLE rule (...)) will break after this change.
Fix: Add MAPPING, CEL, and RULE to the nonReserved rule in DorisParser.g4, following the alphabetical convention used there.
Additional Findings (outside diff hunks)1. Concurrency Bug (High):
|
TPC-H: Total hot run time: 26434 ms |
TPC-DS: Total hot run time: 168899 ms |
|
run buildall |
TPC-H: Total hot run time: 26457 ms |
TPC-DS: Total hot run time: 168728 ms |
FE UT Coverage ReportIncrement line coverage |
github-actions
bot
removed
the
approved
### What problem does this PR solve?
Issue Number: None
Related PR: None
Problem Summary: Add a narrow gitleaks allowlist for the fake OIDC token fixture in AuthenticatorManagerTest so secret scanning does not flag this known false positive or require rewriting historical commits.
### Release note
None
### Check List (For Author)
- Test: Manual test
- Reviewed the staged gitleaks config diff; gitleaks binary is not available in this environment for an end-to-end scan
- Behavior changed: Yes
- Gitleaks should ignore the specific false positive in AuthenticatorManagerTest while keeping the generic-api-key rule active elsewhere
- Does this need documentation: No
|
run buildall |
### What problem does this PR solve?
Issue Number: None
Related PR: None
Problem Summary: Exclude .gitleaks.toml from repository license header checks so the new gitleaks configuration file does not require an Apache license header and does not fail license validation.
### Release note
None
### Check List (For Author)
- Test: Manual test
- Reviewed the staged diffs in .licenserc.yaml and .rat-excludes; full license-eyes CI is not available in this environment
- Behavior changed: Yes
- License header checks should ignore .gitleaks.toml
- Does this need documentation: No
|
run buildall |
1 similar comment
|
run buildall |
TPC-H: Total hot run time: 29162 ms |
TPC-DS: Total hot run time: 180264 ms |
github-actions
bot
added
the
approved
|
PR approved by at least one committer and no changes requested. |
dataroaring
left a comment
dataroaring
left a comment
There was a problem hiding this comment.
EditLog / Persistence / Concurrency Review
I did a focused review on the edit log, persistence, and concurrency aspects of this PR. Findings below.
CRITICAL: PersistMetaModules — "TableStreamManager" accidentally removed from MODULE_NAMES
File: fe/fe-core/src/main/java/org/apache/doris/persist/meta/PersistMetaModules.java
The PR changes:
// master:
"constraintManager", "TableStreamManager"
// , "authenticationIntegrations"
// PR:
"constraintManager", "authenticationIntegrations", "roleMappings""TableStreamManager" is dropped. Since MODULES_MAP is built from MODULE_NAMES, this causes two failures:
-
Reading old images crashes FE on startup. When
MetaReaderencounters"TableStreamManager"in the footer'sMetaIndex,MODULES_MAP.get("TableStreamManager")returnsnull. WithConfig.ignore_unknown_metadata_module = false(the default), this throwsIOException: Unknown meta module: TableStreamManager. FE cannot start from any existing image checkpoint. -
New image checkpoints silently drop TableStreamManager data.
MetaWriteriteratesMODULES_IN_ORDER(built fromMODULE_NAMES).TableStreamManageris never written → data lost permanently after the next checkpoint.
Fix: append new modules after TableStreamManager:
"constraintManager", "TableStreamManager", "authenticationIntegrations", "roleMappings"HIGH: putRoleMappingInternal throws unchecked IllegalStateException during replay
File: fe/fe-core/src/main/java/org/apache/doris/authentication/RoleMappingMgr.java
private void putRoleMappingInternal(RoleMappingMeta meta) {
// ...
String previousMappingName = integrationToMappingName.put(meta.getIntegrationName(), meta.getName());
if (previousMappingName != null && !previousMappingName.equals(meta.getName())) {
throw new IllegalStateException(...);
}
}This is called from both createRoleMapping (guarded by pre-checks) and replayCreateRoleMapping (no pre-checks). During replay, if duplicate mappings for the same integration exist in the journal (e.g., corrupted journal, partial write), this throws an unchecked IllegalStateException that propagates up through EditLog.loadJournal and crashes FE startup.
Recommendation: In replayCreateRoleMapping, either catch IllegalStateException and log a warning, or make the method idempotent by removing the throw and overwriting silently (which is what nameToRoleMapping.put() on the line above already does).
HIGH: Cross-class lock ordering undocumented
Files: RoleMappingMgr.java, AuthenticationIntegrationMgr.java
The lock ordering is consistent (integrationMgr → roleMappingMgr) across all paths:
| Path | Lock 1 | Lock 2 |
|---|---|---|
RoleMappingMgr.createRoleMapping() |
integrationMgr.readLock() |
roleMappingMgr.writeLock() |
IntegrationMgr.dropAuthenticationIntegration() |
integrationMgr.writeLock() |
roleMappingMgr.readLock() (via hasRoleMapping()) |
No deadlock exists today. However, readLock()/readUnlock() on AuthenticationIntegrationMgr were widened from private to package-private specifically for this cross-class protocol, with no documentation of the ordering invariant. A future developer adding a reverse-order lock acquisition would introduce a deadlock.
Recommendation: Add a lock ordering comment to both classes:
// Lock ordering: AuthenticationIntegrationMgr.lock → RoleMappingMgr.lock
// Always acquire integration lock before role mapping lock to prevent deadlocks.MEDIUM: NPE on corrupted journal during replay
File: fe/fe-core/src/main/java/org/apache/doris/persist/EditLog.java
case OperationType.OP_CREATE_ROLE_MAPPING: {
RoleMappingMeta log = (RoleMappingMeta) journal.getData();
env.getRoleMappingMgr().replayCreateRoleMapping(log); // NPE if log is null
break;
}If getData() returns null (corrupted journal entry), replayCreateRoleMapping(null) → putRoleMappingInternal(null) → null.getName() → NPE → FE fails to start.
This is consistent with the existing codebase pattern (other replay handlers have the same issue), but adding a null-guard would make role mapping replay more resilient.
Minor notes
-
Edit log write atomicity:
createRoleMappingcallsputRoleMappingInternal(meta)thenlogCreateRoleMapping(meta)inside the write lock. If the BDBJE write fails, in-memory state is updated but not persisted. On restart the mapping is lost. This is the standard Doris pattern (same asAuthenticationIntegrationMgr,SqlBlockRuleMgr, etc.) — not a new issue, just noting for awareness. -
Edit log write holds
integrationMgr.readLock(): BDBJE writes can be slow under replication pressure. While pending,DROP/ALTER AUTHENTICATION INTEGRATIONoperations are blocked. Latency concern only. -
DropRoleMappingOperationLogdegrades gracefully: If GSON deserializes corrupted JSON missing the"n"field,mappingNamedefaults to"", andremoveRoleMappingInternal("")is a no-op. Good defensive design. -
ReentrantReadWriteLock lockfield inRoleMappingMgr: Correctly initialized via field initializer in the default constructor that GSON uses. No NPE after deserialization.
dataroaring
left a comment
dataroaring
left a comment
There was a problem hiding this comment.
EditLog / Persistence / Concurrency Review
I did a focused review on the edit log, persistence, and concurrency aspects of this PR. Findings below.
CRITICAL: PersistMetaModules — "TableStreamManager" accidentally removed from MODULE_NAMES
File: fe/fe-core/src/main/java/org/apache/doris/persist/meta/PersistMetaModules.java
The PR changes:
// master:
"constraintManager", "TableStreamManager"
// , "authenticationIntegrations"
// PR:
"constraintManager", "authenticationIntegrations", "roleMappings""TableStreamManager" is dropped. Since MODULES_MAP is built from MODULE_NAMES, this causes two failures:
-
Reading old images crashes FE on startup. When
MetaReaderencounters"TableStreamManager"in the footer'sMetaIndex,MODULES_MAP.get("TableStreamManager")returnsnull. WithConfig.ignore_unknown_metadata_module = false(the default), this throwsIOException: Unknown meta module: TableStreamManager. FE cannot start from any existing image checkpoint. -
New image checkpoints silently drop TableStreamManager data.
MetaWriteriteratesMODULES_IN_ORDER(built fromMODULE_NAMES).TableStreamManageris never written → data lost permanently after the next checkpoint.
Fix: append new modules after TableStreamManager:
"constraintManager", "TableStreamManager", "authenticationIntegrations", "roleMappings"HIGH: putRoleMappingInternal throws unchecked IllegalStateException during replay
File: fe/fe-core/src/main/java/org/apache/doris/authentication/RoleMappingMgr.java
private void putRoleMappingInternal(RoleMappingMeta meta) {
// ...
String previousMappingName = integrationToMappingName.put(meta.getIntegrationName(), meta.getName());
if (previousMappingName != null && !previousMappingName.equals(meta.getName())) {
throw new IllegalStateException(...);
}
}This is called from both createRoleMapping (guarded by pre-checks) and replayCreateRoleMapping (no pre-checks). During replay, if duplicate mappings for the same integration exist in the journal (e.g., corrupted journal, partial write), this throws an unchecked IllegalStateException that propagates up through EditLog.loadJournal and crashes FE startup.
Recommendation: In replayCreateRoleMapping, either catch IllegalStateException and log a warning, or make the method idempotent by removing the throw and overwriting silently (which is what nameToRoleMapping.put() on the line above already does).
HIGH: Cross-class lock ordering undocumented
Files: RoleMappingMgr.java, AuthenticationIntegrationMgr.java
The lock ordering is consistent (integrationMgr → roleMappingMgr) across all paths:
| Path | Lock 1 | Lock 2 |
|---|---|---|
RoleMappingMgr.createRoleMapping() |
integrationMgr.readLock() |
roleMappingMgr.writeLock() |
IntegrationMgr.dropAuthenticationIntegration() |
integrationMgr.writeLock() |
roleMappingMgr.readLock() (via hasRoleMapping()) |
No deadlock exists today. However, readLock()/readUnlock() on AuthenticationIntegrationMgr were widened from private to package-private specifically for this cross-class protocol, with no documentation of the ordering invariant. A future developer adding a reverse-order lock acquisition would introduce a deadlock.
Recommendation: Add a lock ordering comment to both classes:
// Lock ordering: AuthenticationIntegrationMgr.lock → RoleMappingMgr.lock
// Always acquire integration lock before role mapping lock to prevent deadlocks.MEDIUM: NPE on corrupted journal during replay
File: fe/fe-core/src/main/java/org/apache/doris/persist/EditLog.java
case OperationType.OP_CREATE_ROLE_MAPPING: {
RoleMappingMeta log = (RoleMappingMeta) journal.getData();
env.getRoleMappingMgr().replayCreateRoleMapping(log); // NPE if log is null
break;
}If getData() returns null (corrupted journal entry), replayCreateRoleMapping(null) → putRoleMappingInternal(null) → null.getName() → NPE → FE fails to start.
This is consistent with the existing codebase pattern (other replay handlers have the same issue), but adding a null-guard would make role mapping replay more resilient.
Minor notes
-
Edit log write atomicity:
createRoleMappingcallsputRoleMappingInternal(meta)thenlogCreateRoleMapping(meta)inside the write lock. If the BDBJE write fails, in-memory state is updated but not persisted. On restart the mapping is lost. This is the standard Doris pattern (same asAuthenticationIntegrationMgr,SqlBlockRuleMgr, etc.) — not a new issue, just noting for awareness. -
Edit log write holds
integrationMgr.readLock(): BDBJE writes can be slow under replication pressure. While pending,DROP/ALTER AUTHENTICATION INTEGRATIONoperations are blocked. Latency concern only. -
DropRoleMappingOperationLogdegrades gracefully: If GSON deserializes corrupted JSON missing the"n"field,mappingNamedefaults to"", andremoveRoleMappingInternal("")is a no-op. Good defensive design. -
ReentrantReadWriteLock lockfield inRoleMappingMgr: Correctly initialized via field initializer in the default constructor that GSON uses. No NPE after deserialization.
### What problem does this PR solve? Issue Number: close apache#60361 Related PR: apache#61819 Problem Summary: Restore the persisted module ordering so TableStreamManager remains readable and writable when authentication integrations and role mappings are persisted, and document the cross-manager lock ordering used by authentication metadata managers. ### Release note None ### Check List (For Author) - Test: Checkstyle - Behavior changed: Yes - preserves metadata compatibility by keeping TableStreamManager in the persisted module list before the new auth metadata modules. - Does this need documentation: No
github-actions
bot
removed
the
approved
|
run buildall |
TPC-H: Total hot run time: 29145 ms |
TPC-DS: Total hot run time: 180200 ms |
github-actions
bot
added
the
approved
|
PR approved by at least one committer and no changes requested. |
…role mapping (apache#61819) apache#60361 This PR integrates the Doris FE authentication extension modules and delivers the end-to-end OIDC login path for MySQL clients. The core changes are: 1. Add MySQL protocol-layer support for OIDC login - bridge OIDC credentials carried in the MySQL authentication packet into Doris authentication requests - allow OIDC-based external login to enter the FE authentication pipeline through the MySQL protocol path 2. Add ROLE MAPPING for built-in authorization - support using external identity attributes/groups to drive internal authorization decisions 3. Integrate the authentication feature modules into FE - wire the authentication plugin/integration modules into the FE runtime - connect external authentication, JIT/external login, and built-in role authorization into one complete flow With these changes, Doris can accept OIDC-based external logins from the MySQL protocol entry, authenticate them through the integrated authentication modules, and apply Doris-native authorization through ROLE MAPPING. (cherry picked from commit c116852)
### What problem does this PR solve? Issue Number: close apache#60361 Related PR: apache#61819, apache#62077, apache#61362 Problem Summary: Backport the missing FE-side authentication chain compatibility pieces required by the branch-4.1 OIDC authentication and role mapping cherry-picks so the FE build succeeds on auth_branch-4.1. ### Release note None ### Check List (For Author) - Test: env DORIS_PARALLELISM=16 BUILD_TYPE=ASAN ./build.sh --fe -j16 - Manual test - Behavior changed: Yes (restores FE-side authentication chain compatibility for the branch-4.1 auth backport) - Does this need documentation: No
8 participants
#60361
This PR integrates the Doris FE authentication extension modules and delivers the end-to-end OIDC login path for MySQL clients.
The core changes are:
Add MySQL protocol-layer support for OIDC login
Add ROLE MAPPING for built-in authorization
Integrate the authentication feature modules into FE
With these changes, Doris can accept OIDC-based external logins from the MySQL protocol entry, authenticate them through the integrated authentication modules, and apply Doris-native authorization
through ROLE MAPPING.