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?