+1 non-binding On Fri, Aug 2, 2024 at 6:20 PM Elad Kalif <elad...@apache.org> wrote:
> +1 binding > > I am not sure I agree with previous statements regarding the LDAP issue > (specifically about blocker or not blocker for Airflow 3) but let's not > discuss this here as it's out of scope for the AIPs we are voting here. > > On Fri, Aug 2, 2024 at 7:15 PM Vincent Beck <vincb...@apache.org> wrote: > > > Big +1 to this one. I think this is the major blocker on that workstream: > > deciding which tool we want to leverage to build the default auth manager > > for Airflow 3. Once that decision taken I'll be happy to help to > implement > > the auth manager based upon that tool. > > > > On 2024/08/02 16:06:00 Jarek Potiuk wrote: > > > Yeah. KeyCloak was just a repeating theme in a number of > questions/issues > > > some users raised (How do I integrate with KeyCloak) and it's well > > > recognized in enterprise. But this is about as much as I know about it > :) > > > > > > So yeah, if we have anyone who can dig deeper in the options we have or > > > ideally someone who has experience in running and configuring / > > developing > > > for any of those - we are definitely on a lookout for such person. > > > > > > On Fri, Aug 2, 2024 at 5:34 PM Vikram Koka > <vik...@astronomer.io.invalid > > > > > > wrote: > > > > > > > Agreed Jarek on the parallel workstream for auth and also that should > > not > > > > be a blocker for 3.0. > > > > > > > > I don't know if the right answer is actually Keycloak. There was some > > > > research done by my colleagues within Astronomer using Casbin for the > > same, > > > > but I don't know the differences between those and other options. I > > agree > > > > that this needs some investigation before we can figure out the exact > > > > timing. And therefore having the FAB provider as a backup option is > > > > critical in my mind. > > > > > > > > > > > > > > > > On Fri, Aug 2, 2024 at 4:27 AM Jarek Potiuk <ja...@potiuk.com> > wrote: > > > > > > > > > Yeah. And (a little tangential) - I really feel that we should > have a > > > > > separate parallel workstream `Implement "proper" Auth Manager` (for > > > > example > > > > > authorizing users via Keycloak) - which should be creating a new > > > > provider. > > > > > Note that this provider should NOT have a way to manage users and > > roles - > > > > > it should allow mapping the "external" groups into roles (and > > eventually > > > > > teams) - with default roles defined, and likely have some > > flexibility of > > > > > mapping roles to be able to access particular resources. > > > > > > > > > > It does not have to IMHO be ready for 3.0 - there likely FAB > > provider as > > > > > backup would be ok, but having it from day one would be really good > > to > > > > > actually benefit from splitting out FAB as dependency. > > > > > > > > > > On Fri, Aug 2, 2024 at 1:07 PM Jed Cunningham < > > jedcunning...@apache.org> > > > > > wrote: > > > > > > > > > > > > Just to verify, users will still be able connect FAB to LDAP by > > > > > > installing > > > > > > > FAB provider explicitly? > > > > > > > > > > > > > > > > > > Yes. That and configuring the FAB auth manager as the auth > > manager, as > > > > it > > > > > > won't be the default most likely. Being able to maintain that is > a > > > > > primary > > > > > > goal of this AIP. > > > > > > > > > > > > > > > > > > > But I want to make sure that we add Connection > > > > > > > form decoupling to AIP-79 (or other AIP) unless we rely on FAB > > for > > > > > > > backwards compatibility. > > > > > > > > > > > > > > > > > > That's part of AIP-38 - it's in the list of the remaining > non-react > > > > > pages. > > > > > > Granted, probably the most complex one remaining. We should > likely > > add > > > > > some > > > > > > details there about this and likely also for the trigger dag run > > form. > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org > > For additional commands, e-mail: dev-h...@airflow.apache.org > > > > > -- Bugra Ozturk
