It doesn't really matter. Robert, if I remove the flag, will you remove the
-1 on the PR?
On Wed, May 7, 2025 at 10:43 AM Dmitri Bourlatchkov
wrote:
> On Wed, May 7, 2025 at 11:29 AM Robert Stupp wrote:
>
> > If federated principals cannot be created, it doesn't make sense to me
> > to even hav
On Wed, May 7, 2025 at 11:29 AM Robert Stupp wrote:
> If federated principals cannot be created, it doesn't make sense to me
> to even have that flag.
>
I think Robert has a point here. Still, from my POV (as I commented in GH
[1])
exposing the same property in PrincipalRole and Principal at the
If federated principals cannot be created, it doesn't make sense to me
to even have that flag.
On 01.05.25 19:57, Michael Collado wrote:
Maybe our approaches are just different. As for me, making backend changes
first, adding API later is more "natural" :)
I definitely have the opposite appr
> Maybe our approaches are just different. As for me, making backend changes
first, adding API later is more "natural" :)
I definitely have the opposite approach. I’m very used to defining the
contract first, before a working backend implementation is complete, as
that usually allows dependent tea
But even in the original code, there is a test asserting that federated
principals can't be created.
Yeah, I saw that, but this was actually the thing that felt awkward to me
in the PR.
I'd prefer to avoid making API changes that do not have an execution option
in runtime (i.e. not possible to c
Hi Dmitri
I do have a revision ready to push. As of this morning (PDT), I was still
waiting for a response to this issue (I see you've responded since) -
https://github.com/apache/polaris/pull/1353#discussion_r2067815515 .
But even in the original code, there is a test asserting that federated
pr
Hi Mike,
I guess some of the confusion may come from PR 1353 [1] and this thread
being a bit out of sync.
Would you mind removing federated Principals from the API in the PR for the
sake of clarity?
>From my POV, we can reconsider that if/when SCIM (or something similar)
comes.
Thanks,
Dmitri.
Hi Robert
Unsure if you read the previous emails in this thread. In my earlier
response, I wrote
> 1. TBH, I have no strong feelings about persisting the federated
principals. I think the biggest advantage I saw was to support SCIM along
with 3p identity providers. But for this implementation, if
Hi,
thanks Mike for the effort.
However, I think that persisting principals, which are not "owned" by
Polaris, being persisted in Polaris is a good idea. How would changes to
a principal in the IdP be propagated to Polaris? What happens if a
principal that's deleted/disabled in the IdP - how
Hi Mike,
Thanks for the historical context, that is really helpful. And I completely
agree with your last paragraph, and especially this:
My preference would be to make this an immutable class that has the
> principal entity and all active principal roles all in the constructor.
I was arriving
Hey
1. I'm unsure why the Resolver was written to assume no role means all
roles. But I think it has to do with
2. The Resolver was intended to be able to resolve principal roles, grants,
and target entities all at one "snapshot" based on the entity and grant
versions returned by that loadEntities
Hi Mike,
I am generally fine with the spec changes.
I have however some concerns around the way we handle principal roles today
in Polaris, and as I was preparing the PR with support for external IDPs
[1], some oddities stood out:
1. The pseudo-role PRINCIPAL_ROLE:ALL seems, by convention, to
Re 2: Thanks for the clarification, Mike! I guess my brain swapped out a
large portion of that doc :)
I'm still not sure how IdentityToPrincipalMapping can help with resolving
changes from API and from IdP integration.
The doc talks about namespaces, but in PR# 1353, it looks like API calls
are f
Thanks Micheal for working on this. The spec looks good to me!
Yufei
On Thu, Apr 17, 2025 at 10:44 AM Eric Maynard
wrote:
> +1 on the spec change
>
> On Wed, Apr 16, 2025 at 3:44 PM Michael Collado
> wrote:
>
> > Hey folks
> >
> > Some of you already know that I posted an initial PR to get fe
Thanks for the response.
1. TBH, I have no strong feelings about persisting the federated
principals. I think the biggest advantage I saw was to support SCIM along
with 3p identity providers. But for this implementation, if we want to skip
persisting principal entities, I'm ok with it.
2. In the
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 Po
+1 on the spec change
On Wed, Apr 16, 2025 at 3:44 PM Michael Collado
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
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
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 im
Thanks. I fixed the permissions. Everyone should be able to comment.
Mike
On Thu, Nov 14, 2024 at 10:42 PM Jean-Baptiste Onofré
wrote:
> Hi Michael
>
> Thanks for sharing the doc.
> Can you please give everyone the permission to comment on the doc ?
>
> As discussed, to implement muti-authentic
Hi Michael
Thanks for sharing the doc.
Can you please give everyone the permission to comment on the doc ?
As discussed, to implement muti-authenticators and SSO, I think we
have to decouple in two parts:
- the core Polaris model and design
- the impl depending of the runtime framework (dropwizar
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/docume
22 matches
Mail list logo
