yuqi1129 opened a new issue, #13090: URL: https://github.com/apache/gravitino/issues/13090
### Describe the subtask #9087 scoped metadata authorization to auxiliary mode and left standalone per-user identity out of scope. This subtask opens that track. Today standalone Lance REST authenticates the caller and then makes every Gravitino call as one configured service account (`gravitino.lance-rest.gravitino-auth-type` = `simple` / `oauth2`). Unlike Iceberg REST — which only reads catalog configuration through its Gravitino client and does all metadata work against the backend catalog — Lance REST performs its metadata *writes* through Gravitino, so a service account means every table is owned by `lance-rest-server`, audit never records the real user, and Gravitino's privilege model does not apply to Lance users. The plan, in order: 1. Forward the caller's credentials per request (sub-issue below; PR #12984). Lands after #12954 so the auth documentation is in place; the `LanceExceptionMapper` conflict resolves in favour of #12954 (no stack traces in 401/403). 2. Fix the client bootstrap so the first caller's credentials are not used to load the metalake (#12985). 3. Document and then close the authorization-semantics gap between the two modes (#13089). 4. Replace raw credential replay with token exchange, which removes the Kerberos and dual-audience limits and stops Lance REST acting as a credential relay. Step 1 is deliberately an intermediate state: it is the smallest change that makes Gravitino's ownership, audit and privilege model apply to standalone Lance users, and its `AuthDataProvider.getRequestHeaders()` extension point is the seam step 4 plugs into. ### Parent issue #9087 -- 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]
