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