[Freeipa-devel] python kerberos problems (forms based auth)

[Simo Sorce]

On Fri, 2012-02-17 at 15:35 -0500, John Dennis wrote:
> 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".

It seem like kinit can be passed a password through stdin w/o problems
(just tried with echo "password" | kinit foobar) so maybe this option is
not that bad.

> 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.

Pass, waste of time

> 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.

Pass, non-starter

> 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.

I like this, but too late in the process, I would like to have it in 3.0
though.

> 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.

kinit, ugly but will work I think.

> 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.

It does.

> Thoughts? Comments?

I think 'kinit' for now, and your new bindings for 3.0 would be the
'right' answer.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York