Learn more about these different git repos.
Other Git URLs
python-gssapi is the updated, newer, better gssapi module for python, essentially obsoleting python-kerberos. It will have python 3 support and is more full featured. It will allow us pass the keytab and use it directly insteaf of using the env var KRB5_KTNAME.
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'] = <the keytab file> 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.
Metadata Update from @dcallagh:
- Issue set to the milestone: 0.10
Metadata Update from @lholecek:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)
- Issue tagged with: enhancement
to comment on this ticket.