Yes. That would be rather useful and finally allow "enterprise" users to not have to use FAB for just authentication in Airflow 3.
> We're using Keycloak, integrated with Airflow using the FAB auth manager > (OpenID). As of now, it has worked properly for us to login to the webpage, > but I never managed to get the API working for Keycloak users (I had to > create users using FAB directly). > Sorry to hear that, I am not sure if this is a bug or expected. Has it always behaved that way or it started to fail recently? Feel free to cut an issue on Github in any case. Yeah. I guess that's one of the limitations of FAB provider that - some of the ways of integrations are not perfect.. On Wed, May 21, 2025 at 4:36 PM Vincent Beck <vincb...@apache.org> wrote: > > Oh, this could be cool! But quite specific since not everyone has > Keycloak > > for auth things and Airflow still has to have some own one. > > May be not full delegation, but some sort of synchronization could be a > > great middle ground. Airflow works like it always been, while source of > > auth info becomes Keycloak or some else service via API. > > Auth managers are individual components in Airflow which handle the user > authentication and authorization. There are different auth managers > available, each with their own implementation and underlying dependencies. > For example, there is AWS auth manager which uses 2 different AWS services > to handle authentication and authorization. As a deployment manager, you > can chose the auth manager that fits better with your needs/requirements. > If you want to use AWS, AWS auth manager can be an option. If you want to > use Keycloak, then Keycloak auth manager is an option. If you want to keep > using FAB, then you can use FAB auth manager as of today. > > What I am proposing here is to add a new option: Keycloak auth manager. > But if you do not want to use Keycloak, you can chose another auth manager > :) > > > Hi Vincent, > > > > This looks promising! > > > > We're using Keycloak, integrated with Airflow using the FAB auth manager > > (OpenID). As of now, it has worked properly for us to login to the > webpage, > > but I never managed to get the API working for Keycloak users (I had to > > create users using FAB directly). > > Sorry to hear that, I am not sure if this is a bug or expected. Has it > always behaved that way or it started to fail recently? Feel free to cut an > issue on Github in any case. > > > We have versions 2.10 and 3 installed, so let me know if you'd like me to > > test the auth manager you've prepared. > > Absolutely! Thank you! That would be indeed very much welcome :) > > On 2025/05/21 05:32:08 Eloi Codina wrote: > > Hi Vincent, > > > > This looks promising! > > > > We're using Keycloak, integrated with Airflow using the FAB auth manager > > (OpenID). As of now, it has worked properly for us to login to the > webpage, > > but I never managed to get the API working for Keycloak users (I had to > > create users using FAB directly). > > > > We have versions 2.10 and 3 installed, so let me know if you'd like me to > > test the auth manager you've prepared. > > > > On Tue, May 20, 2025 at 10:04 PM Alexander Shorin <kxe...@apache.org> > wrote: > > > > > Oh, this could be cool! But quite specific since not everyone has > Keycloak > > > for auth things and Airflow still has to have some own one. > > > May be not full delegation, but some sort of synchronization could be a > > > great middle ground. Airflow works like it always been, while source of > > > auth info becomes Keycloak or some else service via API. > > > > > > -- > > > ,,,^..^,,, > > > > > > > > > On Tue, May 20, 2025 at 7:48 PM Vincent Beck <vincb...@apache.org> > wrote: > > > > > > > Good point. > > > > > > > > You're right — it's already possible to use Keycloak for user > > > > authentication with the FAB (Flask AppBuilder) auth manager. You can > > > > configure FAB to use Keycloak as an identity provider, allowing > users to > > > > authenticate via Keycloak. Authorization, however, remains handled > within > > > > FAB, meaning user permissions and access control are still enforced > by > > > > Flask AppBuilder. > > > > > > > > With this new provider, I'm proposing to introduce a brand-new auth > > > > manager that relies entirely on Keycloak, independent of Flask > > > AppBuilder. > > > > This new manager would delegate both authentication and > authorization to > > > > Keycloak — meaning all user permissions and access controls would be > > > > defined in Keycloak, not in Airflow. > > > > > > > > On 2025/05/20 16:35:07 Alexander Shorin wrote: > > > > > Hi! > > > > > > > > > > Sounds great, but Airflow already works perfectly to auth users via > > > > > Keycloak LDAP protocol. What this provider will change and why it > will > > > be > > > > > better than now? > > > > > > > > > > -- > > > > > ,,,^..^,,, > > > > > > > > > > On Tue, May 20, 2025 at 7:32 PM Beck, Vincent > > > > <vincb...@amazon.com.invalid> > > > > > wrote: > > > > > > > > > > > Hi all, > > > > > > > > > > > > I'd like to propose adding a new provider, Keycloak [1], to the > > > > collection > > > > > > of Apache Airflow providers. > > > > > > > > > > > > Keycloak is an open-source software product to allow single > sign-on > > > > with > > > > > > identity and access management aimed at modern applications and > > > > services. > > > > > > > > > > > > The intent of this new provider would be to provide Keycloak auth > > > > manager, > > > > > > an auth manager [2] leveraging Keycloak to perform > authentication and > > > > > > authorization of user actions in Airflow. > > > > > > > > > > > > I started the implementation and have a POC working. > > > > > > > > > > > > Happy to hear from you all any feedback or questions :) > > > > > > > > > > > > [1] https://www.keycloak.org/ > > > > > > [2] > > > > > > > > > > > > > > https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/auth-manager/index.html > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org > > > > For additional commands, e-mail: dev-h...@airflow.apache.org > > > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org > For additional commands, e-mail: dev-h...@airflow.apache.org > >
