Re: Proposal: Optional clientId / clientSecret in createPrincipal API for Migration Support

Hi Robert, > There is already a way to rotate credentials [...] I do not think so. Currently, Polaris allows only the Principal itself to rotate the credential it owns. Admin / root cannot rotate credentials for another Principal. Cheers, Dmitri. On Mon, Jul 21, 2025 at 4:32 AM Robert Stupp

Re: Proposal: Optional clientId / clientSecret in createPrincipal API for Migration Support

There is already a way to rotate credentials, so I am not sure what the benefit of a "reset password" workflow would be. I do see the disadvantage that 0.9 doesn't have "external IdP" support, but 1.0 has it. I also see that you have trouble with keeping both versions alive. However, we have to be

Re: Proposal: Optional clientId / clientSecret in createPrincipal API for Migration Support

I’m aligned with the phased approach you’ve outlined: supporting password resets for existing principals now, while steadily enhancing IdP support and making it the default over time I will go ahead with making changes based on the discussions Thank you for the suggestions On Tue, Jul 15, 2025 at

Re: Proposal: Optional clientId / clientSecret in createPrincipal API for Migration Support

I support Robert's proposal to leverage external IdPs in Polaris. However, Arun's use case also has merit, IMHO, because it enables existing deployments to migrate to newer Polaris versions, while keeping the old Polaris Principals. Migrating to an external IdP, while valuable from a security per

Re: Proposal: Optional clientId / clientSecret in createPrincipal API for Migration Support

Hey Dmitri, Thanks for the update. I don’t have any strong concerns with this approach — it looks good to me. I would say calling two APIs (one to create the principal and another to reset the credentials) is acceptable, especially since this also addresses the broader issue of rotating/resetting

Re: Proposal: Optional clientId / clientSecret in createPrincipal API for Migration Support

Hi all, Writing the following with my "nasty security guy" hat on: Generally speaking, storing secrets is a quite sensitive topic that deserves a lot of attention upfront, during the initial implementation and for all changes related to it. What we already have in Polaris is IMHO strictly speakin

Re: Proposal: Optional clientId / clientSecret in createPrincipal API for Migration Support

Hi Arun, After writing my previous email I realised that we might be able to support your use case via REST API by implementing admin-base password reset [624]. The flow would be: 1) create a principal using current ID (random client ID/secret) 2) set your own client ID / secret via the password

Re: Proposal: Optional clientId / clientSecret in createPrincipal API for Migration Support

Hi Yufei, I do not think what Arun proposes is related to Secrets Management in Polaris. The use cases you mentioned do require accessing "raw" secrets owned by external systems. What Arun is proposing is about basically resetting Polaris' own password (for Polaris Principals). In that case Polari

Re: Proposal: Optional clientId / clientSecret in createPrincipal API for Migration Support

Thanks for volunteering to make a PR for this, Arun! Looking forward to it. As discussed, please consider securing the extra capability via (new) permission checks. I'd think it might be worth it to also have a feature flag to control the new functionality. Re: External IdP - most of the authenti

Re: Proposal: Optional clientId / clientSecret in createPrincipal API for Migration Support

Thanks for the detailed response Dimitri and Yufei! I agree with making the PR to support user-defined client ID and secret via the REST API, along with appropriate access checks and possibly introducing a new permission type/config. I will work on this REST fits better with our tooling as it has

Re: Proposal: Optional clientId / clientSecret in createPrincipal API for Migration Support

The use case of passing secrets via REST is definitely valid, and this use case is not the only one we should be considering. Other concrete scenarios include: 1. Catalog federation, where Polaris needs to store credentials to connect to remote catalogs (e.g., Hive, Glue, Unity Catalog).

Re: Proposal: Optional clientId / clientSecret in createPrincipal API for Migration Support

Thanks for providing more context, Arun! I do not object to adding user-provided client ID and secret to the REST API. However, I personally maintain my opinion that this kind of operation fits better with the Admin Tool, given the current state of the project. I wonder what other community member

Re: Proposal: Optional clientId / clientSecret in createPrincipal API for Migration Support

Hey Dmitri and Robert, *To clarify our use case further:* This isn't a one-time migration for us. We're migrating our *customers* from Polaris 0.9 (EclipseLink) to Polaris 1.0 (JDBC) gradually. During this process, we’ll be *running both catalog servers in parallel*, with 1.0 acting as a *seco

Re: Proposal: Optional clientId / clientSecret in createPrincipal API for Migration Support

Hi Arun, Thank you for starting this discussion! I did some poking about Keycloak and it looks like Keycloak allows user-provided Client IDs. I think it should be fine for Polaris to accept user-provided Client IDs in the Principal management API. I suppose we may want to impose some restriction

Proposal: Optional clientId / clientSecret in createPrincipal API for Migration Support

Hi all, Following up on the suggestion from the discussion here — thank you for the feedback so far. We’re currently migrating our self-hosted Polaris service from version 0.9 (EclipseLink-based metastore) to version 1.0 (JDB