Hi Alex, This proposal sounds very reasonable to me.
I believe we had some recent user interest (in slack) for running Polaris with Keycloak. From my POV, implementing your proposal should significantly simplify that user's deployment. As for item (3b), I'd like this lookup to be covered by a feature flag. Admin users who do not import / sync Principals know that this lookup will always fail, so it would be nice to allow skipping the unnecessary database hit. WDYT? Thanks, Dmitri. On Tue, Nov 4, 2025 at 11:53 AM Alexandre Dutra <[email protected]> wrote: > Hello everyone, > > I'd like to propose an enhancement to Polaris's authentication > process: the introduction of "detached" (non-persisted) principals. > > A detached principal is different from a federated principal. The > former isn't persisted at all, whereas the latter is persisted (with > federated flag = true), and possibly synchronized with some external > system (e.g. via SCIM). > > Motivation: > > Currently, Polaris requires principals to be pre-existing for > successful authentication – even those marked as "federated". The > default authenticator always performs a lookup by ID or name, and > fails if the principal isn't found. > > This presents a challenge for users who utilize external > authentication and authorization systems, such as Keycloak + OPA, > where Polaris acts as a passthrough between authn and authz. > > In such scenarios, principals still need to be created in advance > within Polaris, which doesn't make much sense. > > Proposal: > > 1) Introduce a new property: PolarisCredential.isExternal(). > > 2) During authentication, set isExternal=false on the > PolarisCredential if Polaris is the IDP (internal auth); otherwise, > set isExternal=true. > > 3) In DefaultAuthenticator: > > a) If PolarisCredential.isExternal() is false, continue with the > existing logic (lookups by ID and name). > > b) If PolarisCredential.isExternal() is true, perform the usual > lookups. If they succeed, continue with the existing logic. If they > fail though, don't fail the authentication. Instead, create the > principal and assign roles directly from the token. > > 4) In the Resolver, trust the PolarisPrincipal and avoid re-resolving > the principal and its roles (as this would fail for detached > principals). > > I believe this change will not impact internal authentication with the > default authorizer. It also won't impact people using external IDPs > with pre-synchronized federated principals: the default authorizer > would work just fine. > > However, for external IDPs combined with custom authorizers, this > change would significantly improve the user experience by eliminating > the need to persist the principal and its roles within Polaris. > > What do you all think? > > Thanks, > Alex >
