Thinking about implementing integrated login authentication?

[oct-sky-out]

I know from the webserver_config.py logs that Airflow only allows a single login authentication method.

webserver  | Traceback (most recent call last):
webserver  | File "/usr/lib/python3.10/runpy.py", line 196, in _run_module_as_main
webserver  | return _run_code(code, main_globals, None,
webserver  | File "/usr/lib/python3.10/runpy.py", line 86, in _run_code
webserver  | exec(code, run_globals)
webserver  | File "/home/ubuntu/.local/lib/python3.10/site-packages/gunicorn/__main__.py", line 7, in <module>
webserver  | run()
webserver  | File "/home/ubuntu/.local/lib/python3.10/site-packages/gunicorn/app/wsgiapp.py", line 67, in run
webserver  | WSGIApplication("%(prog)s [OPTIONS] [APP_MODULE]").run()
webserver  | File "/home/ubuntu/.local/lib/python3.10/site-packages/gunicorn/app/base.py", line 236, in run
webserver  | super().run()
webserver  | File "/home/ubuntu/.local/lib/python3.10/site-packages/gunicorn/app/base.py", line 72, in run
webserver  | Arbiter(self).run()
webserver  | File "/home/ubuntu/.local/lib/python3.10/site-packages/gunicorn/arbiter.py", line 58, in __init__
webserver  | self.setup(app)
webserver  | File "/home/ubuntu/.local/lib/python3.10/site-packages/gunicorn/arbiter.py", line 118, in setup
webserver  | self.app.wsgi()
webserver  | File "/home/ubuntu/.local/lib/python3.10/site-packages/gunicorn/app/base.py", line 67, in wsgi
webserver  | self.callable = self.load()
webserver  | File "/home/ubuntu/.local/lib/python3.10/site-packages/gunicorn/app/wsgiapp.py", line 58, in load
webserver  | return self.load_wsgiapp()
webserver  | File "/home/ubuntu/.local/lib/python3.10/site-packages/gunicorn/app/wsgiapp.py", line 48, in load_wsgiapp
webserver  | return util.import_app(self.app_uri)
webserver  | File "/home/ubuntu/.local/lib/python3.10/site-packages/gunicorn/util.py", line 424, in import_app
webserver  | app = app(*args, **kwargs)
webserver  | File "/home/ubuntu/.local/lib/python3.10/site-packages/airflow/www/app.py", line 186, in cached_app
webserver  | app = create_app(config=config, testing=testing)
webserver  | File "/home/ubuntu/.local/lib/python3.10/site-packages/airflow/www/app.py", line 88, in create_app
webserver  | flask_app.config.from_pyfile(webserver_config, silent=True)
webserver  | File "/home/ubuntu/.local/lib/python3.10/site-packages/flask/config.py", line 185, in from_pyfile
webserver  | exec(compile(config_file.read(), filename, "exec"), d.__dict__)
webserver  | File "/home/ubuntu/airflow/webserver_config.py", line 50
webserver  | AUTH_TYPE = [AUTH_DB, AUTH_OAUTH]
webserver  | IndentationError: unexpected indent

My thought after seeing these log entries is, has Airflow considered introducing unified login authentication to allow the above code?

For example, can we consider integrating 3 logins, one through DB, one through OAuth2, and one through SAML, through a package or implementation like Flask-Multipass?
flask-multipass

[Taragolis]

At that moment authentication mechanism reworked step-by-step, see:

• AIP-56 Extensible user management
• https://github.com/orgs/apache/projects/276

So maybe it would be available or already available.

cc @vincbeck, when you have time, can look at this discussion?

[oct-sky-out]

Thank you for your reply @Taragolis .

I have read the history you attached and understand it.

[vincbeck]

Interesting use case. As mentioned by @Taragolis, the user authentication and authorization is currently getting completely remodelled. The end result of AIP-56 wont change anything for the user (the authentication will sill be the same) but will open doors for contributors to create their authentication and authorization layer called auth manager. Once AIP-56 completed, the use case you provided (multiple auth mechanisms) could be fulfill by creating a new auth manager. Feel free to ping if you have any questions about that

[oct-sky-out]

I read AIP-56: #32525 with great interest.
In particular, I read the code written in airflow/www/extensions/init_auth_manager.py(- link), and assuming that I have a CustomSecurityManager class, which is an implementation of AirflowSecurityManager, would it be correct to import that class as the value of the core/auth_manager key in the airflow.cfg file so that I can develop in the direction I want?

(+ Also, I think AirflowSecurityManagerV2 was also created some time ago, if you don't mind, can I know the history of this as well...🥺?)

[vincbeck]

In particular, I read the code written in airflow/www/extensions/init_auth_manager.py(- link), and assuming that I have a CustomSecurityManager class, which is an implementation of AirflowSecurityManager, would it be correct to import that class as the value of the core/auth_manager key in the airflow.cfg file so that I can develop in the direction I want?

No. Customizing the security manager is a feature of the FAB auth manager (sorry for all the different names), so if you want to bring your own security manager, you do not need to change the config core/auth_manager (default being the FAB auth manager) but you need to specify it using SECURITY_MANAGER_CLASS. See documentation.

(+ Also, I think AirflowSecurityManagerV2 was also created some time ago, if you don't mind, can I know the history of this as well...🥺?)

AirflowSecurityManagerV2 has been created as a replacement as security manager. As part of the AIP-56 work, a big effort has been done to remove all FAB auth related function from the security manager in core Airflow to the FAB auth manager. The idea behind it is: the security manager in core Airflow must be small and generic to all auth manager. For any functions specific to an auth manager, it has to be moved to what is called "a security manager override". This is basically a class that extends AirflowSecurityManagerV2 and is used as security manager. To summarize: AirflowSecurityManagerV2 is now THE security manager of Airflow, if you use FAB auth manager, this security manager is overridden by FabAirflowSecurityManagerOverride.

[oct-sky-out]

@vincbeck
Thank you.
This has helped me a lot.