Thanks for reviving this discussion, Mike! The API spec change by itself LGTM, but I have related concerns in how this feature is meant to work in general.
1) The need to expose Federated Principals in Polaris API. The design doc [1] discusses the possibility to expose Federated Principals in Polaris API, but there are pros and cons. I do not think it is a trivial decision. I'd like to discuss this in more detail before we commit to doing that. >From my POV the main benefit of exposing Federated Principals is to be able to alter their properties in Polaris (as mentioned in the doc). However, your email indicates that this is actually forbidden. What use cases do you envision for exposing read-only Federated Principals? 2) Reconciliation of Federated vs. Non-Federated changes. Let's focus on Principal Roles here (which are meant to be writable via API). If users are able to make and change (I assume) Principal Roles via API, and federation code will also be creating and changing those roles, what is our approach to handling conflicts between those two streams of changes? Some examples for context (also mentioned in GH): A) A user creates normal Principal Role "A", and later role "A" is discovered through Federation. B) A user edits Federated Role "B" and later properties of "B" are updated through Federation (or the other way around). Do we want to control property edits based on the origin of the property (spec out a "namespace" for Federated properties)? 3) OO types Currently Principals and Principal Roles are represented by one java type each. When federation comes into play, would it make sense to develop a (java) type hierarchy for working with that data in Polaris code? My main concern here is avoiding a maze of if/else statements throughout the Polaris codebase for supporting Federation. I guess our approach to this depends largely on the outcome of topic 2 above. WDYT? Thanks, Dmitri. [1] https://docs.google.com/document/d/15_3ZiRB6Lhzw0nxij341QUdxEIyFGTrI9_18bFIyJVo/edit?tab=t.0#heading=h.cu1a1acu4lc5 On Wed, Apr 16, 2025 at 6:44 PM Michael Collado <collado.m...@gmail.com> wrote: > Hey folks > > Some of you already know that I posted an initial PR to get federated > principals/roles added. One thing that came out of the feedback was a spec > change to make it clear when federated identities can be used in the APIs. > Notably, federated principals cannot be created or updated, but can be > returned in get/list calls, whereas federated roles *can* be created by the > API. The latter is useful/necessary in order to be able to assign > privileges to those roles without relying on the JIT creation on login. > > Please check out the spec change here and let me know what you think - > > https://github.com/apache/polaris/pull/1353/files#diff-52444bc79608edfae86ed0b46d171f7ef63c20090860d877e4e135168311a986 > > Mike > > On Tue, Dec 17, 2024 at 5:15 PM Dmitri Bourlatchkov > <dmitri.bourlatch...@dremio.com.invalid> wrote: > > > Hi Mike, > > > > I left some comments in the doc, but overall it looks good to me :) > > > > I still think there are some hidden dependencies on Persistence. For > > example, whether and how we can have composite keys for persisted > federated > > entities... but I guess we can work that out later. > > > > Also, I think it is important for the Authorizer API to avoid assuming > that > > all principals are persisted. Specific authorizer implementations > > (including the default one) can certainly expect persisted principals, > but > > the API should require that for the sake of flexibility of possible > AuthN/Z > > extensions. WDYT? > > > > Cheers, > > Dmitri. > > > > On Thu, Nov 14, 2024 at 7:43 PM Michael Collado <collado.m...@gmail.com> > > wrote: > > > > > Hey folks > > > > > > As discussed during the community sync, I've put together some thoughts > > on > > > how we'd add support for federated identities in Polaris. I copied over > > > some of what I had in the issue at > > > https://github.com/apache/polaris/issues/441 and put it into the doc > > here: > > > > > > > > > > > > https://docs.google.com/document/d/15_3ZiRB6Lhzw0nxij341QUdxEIyFGTrI9_18bFIyJVo/edit?tab=t.0 > > > . > > > > > > Please take a look when you get some time and let me know what you > think. > > > Given that our next community sync is scheduled for the Thanksgiving > > > holiday in the US, it might be useful to schedule a meeting > specifically > > > for this. I can schedule that sync if needed. > > > > > > Mike > > > > > >
