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

[Dmitri Pal]

On 02/17/2012 04:08 PM, Simo Sorce wrote:
> 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.
>
I am definitely not a Python person but in AuthHub code I have see the
following construct:
https://fedorahosted.org/AuthHub/browser/plugins/python/authhub-yubikey/authhub-yubikey
when a shared library is loaded and and entry point is mapped.
I assume this can be easily done as in the example code so why we are
not doing this instead of starting KINIT as a separate process? I know
it is probably not the cleanest approach but I am surprised to not find
it as one of the top options on the list in the current situation with
the given constraints.

I am not against Simo's approach, just wanted to make sure all options
are mentioned.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/