We are using flask-kerberos though. So isn't this issue really with flask-kerberos not with waiverdb?

Nah, we're using python-kerberos, but basically duplicating all the kerberos authentication code in flask-kerberos.

In waiverdb, we could set o os.environ['KRB5_KTNAME'] = when the app is intialized. But I think the ideal way is switching to python-gssapi.

(Curious, is there a reason you're not using flask-kerberos?)

flask-kerberos is using a decorator @requires_authentication to decorate any view function for doing kerberos authentication. Since there is no function in flask-kerberos directly return the authenticated user, it's hard to build a function to support both kerberos authentication and OIDC authentication. In this case, I decided to adpot its authentication approach into WaiverDB.

By switching to gssapi, I would expect to set the keytab file in the settings.py and use it directly when doing kerberos authentication. No need to set the KRB5_KTNAME env var or tweak the systemd files when deploying waiverdb with Ansible.

We should send a PR to flask-kerberos which makes it usable with other authentication methods (and also ports it to use python-gssapi???) so that we can go back to it, instead of carrying our own copy of all that logic.

Yeah, that's also a good idea.

Also btw, there is nothing actually wrong with python-kerberos maintenance-wise. It has an active upstream (now) and is already ported to Python 3. Its only downside is it doesn't expose much of the libkrb5 API (specifically nothing for init'ing credentials from a keytab).

Don't get it mixed up with python-krbV which is a separate package that is basically dead upstream and has no Python 3 port.

So switching from python-kerberos to python-gssapi would not be necessary unless there is some API we want that is not exposed in python-kerberos.

GSSAPI has its own downsides anyway, as I recently discovered (like some Kerberos features which are not exposed in older GSSAPI versions on RHEL6).

Alright, I will a PR to flask-kerberos to make it usable for other authentication methods. Then we can get rid of the duplicated logic here.

After closely looking at the code of python-flask-kerberos, it seems that it's not hard to make it work with other authentication methods. The problem is we don't have it on Fedora koji and Brew. That's why I did not use it at the start.

Oh - so is this just a matter of packaging python-flask-kerberos now and porting to it?

OTOH, is this a case of "if its not broken, don't fix it." Is it worth it to spend time on this, or should we close as wontfix?

By porting to python-flask-kerbero would clean up the code, I would say it is worth to do it. However, it is not a high priority thing and the current implementation is working, so I guess we could leave this open until we can find some time to fix it?

This is in progress in #143.