Cloned Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=766070
In some cases the machine that the UI should run from is not Linux or can't be a part of the domain. Also the POC deployments of IPA want something more simple that what we currently offer. Some people in POC cases switch to the basic auth as it is the only alternative we provide. This however sets a bad security precedent. To avoid this we should leverage the sessions and S4U ticket transformation work we already doing and offer a form based authentication for IPA UI.
This will be possible once sessions are available.
Marked https://fedorahosted.org/freeipa/ticket/2109 as duplicate
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=766070
Moving to next month iteration.
Capturing an email I sent to the devel list here describing some issues.
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?
master: ee780df
ipa-2-2: 135e208
Be more forgiving about content-type forma:
master: 610420b
ipa-2-2: d5fbb87
Metadata Update from @dpal: - Issue assigned to jdennis - Issue set to the milestone: FreeIPA 2.2 Core Effort - 2012/02
Login to comment on this ticket.