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