+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 > >
