Hi all, I think I would prefer to stay on the 1:1 model and I would even advocate for co-locating the UI with the Polaris server.
My reasons are: 1) Users would simply direct their browser to the service in front of the Polaris deployment, completely eliminating CORS issues. 2) Quarkus already supports Human-to-Machine flows, such as the authorization code grant. It would transparently redirect users to the IDP login page if necessary. 3) For the internal /token endpoint, indeed a simple login page as suggested by Dmitri could help, if it mimics the authorization code grant flow. The 1:N model is undoubtedly attractive, as it could serve as a central management interface for multiple Polaris deployments. However, it introduces significant complexity, and I'm uncertain if we have the resources to develop and sustain it. Not to mention that I don't think any users have explicitly requested that feature. Thanks, Alex On Mon, Feb 2, 2026 at 6:03 PM Dmitri Bourlatchkov <[email protected]> wrote: > > Good point by Romain about 1:1 vs. N:1 between UI and Polaris Servers. > > I do agree that the N:1 model with CORS headers requires Polaris Servers to > be aware of all UI instances, which may be very inconvenient in larger > environments. > > From my POV the key negative point about using an API proxy in UI is > passing credentials through it. Otherwise, the proxy is quite valid, IMHO. > > So, in case of OAuth2, the UI should be able to redirect the browser to an > auth page in an IdP (e.g. Keycloak). That is a pure browser-level redirect > and should not cause any CORS issues (although I'm not an expert in UI). > > In case of the "internal" Polaris Authentication flow, currently someone > has to POST to the /tokens endpoint in Polaris. Doing that via proxy is not > ideal from the security perspective, IMHO. Doing a direct POST from JS code > causes CORS issues. So, how about we host a custom login page in Polaris > (no full UI, just the login page), and allow UI to redirect the browser to > it in a manner similar to OAuth2 flows? > > Given that the /token endpoint is already deprecated in the Iceberg REST > Catalog API, handling the internal login flow via OAuth2 flows might be > preferable from that POV too. Polaris effectively acts as an IdP for > internal principals anyway. > > WDYT? > > Sorry, if this steers the conversation a bit sideways from the original > topic, but I believe these issues are interconnected. > > Thanks, > Dmitri. > > On Mon, Feb 2, 2026 at 4:12 AM Jean-Baptiste Onofré <[email protected]> wrote: > > > Hi Romain > > > > That was my point and the reason why I started the console with 1-1. > > Again for dev it’s totally fine but enterprise grade probably need extra > > work. > > > > Regards > > JB > > > > Le lun. 2 févr. 2026 à 09:55, Romain Manni-Bucau <[email protected]> a > > écrit : > > > > > Hi, > > > > > > my 2 cts would be that if you switch to 1-N instead of 1-1 you can't just > > > rely on the frontend to do the switch since you will desire some sort of > > > centralized security management so specific backend to avoid to rely on > > > every backend to be configured the same way to enable smooth workflows > > > (login -> actions) plus sounds like the backend should handle the list of > > > instances it aggregates with security for every level? > > > > > > Indeed it only applies to enterprise grade solution, for dev the current > > > option is perfect. > > > > > > Romain Manni-Bucau > > > @rmannibucau <https://x.com/rmannibucau> | .NET Blog > > > <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/ > > > > > > | Old > > > Blog <http://rmannibucau.wordpress.com> | Github > > > <https://github.com/rmannibucau> | LinkedIn > > > <https://www.linkedin.com/in/rmannibucau> | Book > > > < > > > > > https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064 > > > > > > > Javaccino founder (Java/.NET service - contact via linkedin) > > > > > > > > > Le lun. 2 févr. 2026 à 09:24, Jean-Baptiste Onofré <[email protected]> a > > > écrit : > > > > > > > Yes I know the change. My point was > > > > More for context to everyone, in order to understand the deployment and > > > > behavior. > > > > > > > > Thanks for your work on workspaces. As said, I will take a look. > > > > > > > > Regards > > > > JB > > > > > > > > Le lun. 2 févr. 2026 à 08:49, artur rakhmatulin < > > > > [email protected]> > > > > a écrit : > > > > > > > > > Hi JB, > > > > > Thanks for the clarification and for sharing your experience — the > > > > > distinction between the two approaches is very helpful. > > > > > > > > > > Just to clarify the scope of the current PR: it does not introduce > > any > > > > > server-side changes. The workspace concept is purely client-side and > > > > > user-scoped, with all configuration stored in browser LocalStorage. > > > > > > > > > > Also, a previous change already removed the strict 1 Console = 1 > > server > > > > > limitation in main. > > > > > As a result, using a Console with Polaris server now requires > > explicit > > > > CORS > > > > > configuration on the server side. > > > > > This adds some setup overhead, but keeps the security model explicit > > > and > > > > > controlled by the server. > > > > > > > > > > The workspace approach builds on top of this by improving usability > > > when > > > > > working with multiple realms or environments, without changing server > > > > > assumptions. > > > > > > > > > > Thanks again for the context. > > > > > > > > > > Best regards, Artur. > > > > > > > > > > пн, 2 февр. 2026 г. в 10:44, Jean-Baptiste Onofré <[email protected]>: > > > > > > > > > > > Hi > > > > > > > > > > > > Fundamentally, it means about two different approaches: > > > > > > 1. Without workspace, it means one Polaris server == one Console > > > > > > 2. With workspaces, it means one Console == several Polaris servers > > > > > > > > > > > > Initially, the intent was (1), but we discussed (2) as well. > > > > > > Personally, when I started the Console, I was more (1) as it's > > easier > > > > in > > > > > > terms of infrastructure (local to the server) and security (no > > proxy, > > > > > etc), > > > > > > and the Console doesn't need any state/storage for the access to > > the > > > > > > different servers. > > > > > > > > > > > > I'm fine with the workspaces, even if it's a change in the > > paradigm. > > > > > > > > > > > > I will take a look at the workspaces PR. > > > > > > > > > > > > Regards > > > > > > JB > > > > > > > > > > > > On Sun, Feb 1, 2026 at 8:24 PM artur rakhmatulin < > > > > > > [email protected]> wrote: > > > > > > > > > > > > > Hi all, > > > > > > > I’d like to start a discussion on introducing "workspaces" in the > > > > > Polaris > > > > > > > Console UI. > > > > > > > > > > > > > > The idea is to move away from environment-variable–based > > > > configuration > > > > > > > toward a UI-managed model, where a workspace represents an > > isolated > > > > > > Polaris > > > > > > > context (server, realm, and authentication). This allows a single > > > > > console > > > > > > > instance to work with multiple realms and Polaris environments > > in a > > > > > clean > > > > > > > and scalable way. > > > > > > > > > > > > > > A preliminary PR is available for review [1] > > > > > > > > > > > > > > Thanks, Artur. > > > > > > > > > > > > > > [1]: https://github.com/apache/polaris-tools/pull/138 > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Best regards, Artur Rakhmatulin > > > > > e-mail: [email protected], > > > > > telegram: https://t.me/binarycat0 > > > > > > > > > > > > > >
