binarycat0 opened a new issue, #3059: URL: https://github.com/apache/polaris/issues/3059
### Is your feature request related to a problem? Please describe. The current Principals REST API does not return principal_id, but external OIDC providers are expected to supply: - principal_id - principal_name - principal_roles Because **principal_id** is not exposed via the API, external identity providers cannot reliably provide it. This forces users to choose between: - Accessing the metastor and manually retrieving IDs from the internal entities table, or - Using the **undocumented workaround** of returning `principal_id = 0`, which causes Polaris to fall back to name-based mapping and ignore ID-based mapping entirely. https://github.com/apache/polaris/blob/3c5dbaf2bc93bb2861b5fb0407ffc1597e48bdd2/runtime/service/src/main/java/org/apache/polaris/service/auth/DefaultAuthenticator.java#L116 This silent behavior is not discoverable by users unless they read the source code. ### Describe the solution you'd like ### Expose principal_id in the Principals REST API Return principal_id in responses so external OIDC providers can supply accurate mapping data. ### Document the principal_id = 0 Fallback Behavior If exposing internal IDs is not acceptable, the documentation should explicitly state: Supplying `principal_id = 0` disables ID-based matching and triggers name-based mapping. ### Describe alternatives you've considered ### Remove ID-Based Mapping Logic Entirely Standardize principal mapping to rely solely on names (and optionally roles), avoiding IDs altogether. ### Additional context - OIDC providers cannot determine or supply the correct internal principal_id. - Users unknowingly depend on an undocumented behavior (`principal_id = 0`) to make authentication work. - The current mix of ID-based and name-based logic is ambiguous and confusing. - The user experience degrades because the expected mapping logic is not transparent. -- 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]
