[Freeipa-devel] python kerberos problems (forms based auth)
John Dennis
jdennis at redhat.com
Fri Feb 17 20:35:11 UTC 2012
I'm trying to add the missing session features. Last night I started to
add support for forms based auth (i.e. on the web UI a user enters his
password and we get a kerberos ticket for them). To do that we need to
call krb5_get_init_creds_password() (or the deprecated
krb5_get_in_tkt_with_password()).
Bad news, the python kerberos library we're using, python-krbV, does not
export this functionality.
There is a python library, python-krb5, which does export it but it's
not packaged for Fedora or RHEL. It's also rather incomplete.
So it looks like we have a few options:
1) add krb5_get_init_creds_password() to python-krbV
2) package python-krb5 for fedora and RHEL.
3) use my new python kerberos library
4) invoke kinit as a subprocess
5) drop the feature.
From my perspective option 1 of adding the support to python-krbV is a
non-starter. This python library has been nothing but a headache to use,
it's incomplete and it's not pythonic. But the real problem is it's
horribly coded, it doesn't use Python classes, it incorrectly uses
deprecated internal Python API's and it's doesn't encapsulate kerberos
objects inside genuine Python objects. All of which means it's
fundamentally flawed, fragile, out of date, and difficult to extend. I
don't think there is any justification for any continued development on
this library, it should be put out of it's misery and it should have
been killed years ago. The only reason it wasn't was because there
wasn't anything better to replace it with.
I see little point in option 2 as well, getting a new package into
Fedora and RHEL is a significant effort and since this package is rather
incomplete and wouldn't serve all of IPA's needs then why go through
that effort just to get access to one function from Python?
I got so frustrated with kerberos options for Python I started writing a
new MIT Kerberos Python binding in my spare time. It's pythonic, meaning
it supports all the basic python operations you expect such as genuine
classes that encapsulate a genuine Kerberos object, properties,
iteration, indexing, slices, comparison, stringification, etc. It's not
complete yet, at the moment it supports these classes: Context, CCache,
Credential, Principal, Keytab, Address, KeyBlock, and TicketTimes. It
does not yet support krb5_get_init_creds_password() but the framework is
so clean it would be easy to add.
I'm not a fan of option 4, invoking kinit. I'm pretty sure it would
involve doing the pseudo terminal dance to pass the password. I've done
similar things in the past from Python (e.g. invoking some of the NSS
cert generation utilies that prompt for passwords). It tends to be
fragile as well as being inefficient, awkward and possibly may run afoul
of SELinux, but it's an option, not one I'm keen on though, but it could
be a "workaround".
Summary:
If we added krb5_get_init_creds_password() to the existing python-krbV
we would have to rebase or backport in rhel, never an easy task. It also
wouldn't be easy to code up in the first place because the C code in
python-krbV is so horrible.
python-krb5 is a non-starter, it doesn't exist in Fedora and RHEL and
there is little justification in adding it, plus why go through the work
of adding this as new package when there is a far better python kerberos
binding available.
We could finish up the work I started on the new binding and get it
packaged. I think it would add a lot to IPA and the community in
general. But if you add up the time to finish the functionality, write
unit tests, get it reviewed, get it packaged it's still a chunk of work
despite the fact a large part of it is already written and working.
Bottom line, I don't think we'll be supporting forms based auth anytime
soon unless I've missed some easy way to get a ticket for a user from
inside Python code.
P.S.: Since IPA is based on Kerberos and IPA is written in Python it
would seem to make sense to have a decent Python binding for Kerberos.
Thoughts? Comments?
John
--
John Dennis <jdennis at redhat.com>
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
More information about the Freeipa-devel
mailing list