FreeIPA makes Kerberos a lot less painful.

Here is a short list of future work that I feel would help the overall adoption of Kerberos, and, in doing so, make the Enterprise adoption of IPA a lot more worthwhile.

Make it easy to do Kerberos type stuff from the Browser.

Firefox supports Kerberos. But configuring it is a PITA, and it does not let you kinit directly. This is probably best dealt with in the short term using a plugin and/or extension, but eventually, the Browser has to support this even if the OS does not.  I’ve heard rumblings along these lines from the rumor mill.

Chrome does not support Kerberos.  It needs to.

Safari is in the sort-of camp. I’ve heard some people say they need to send a password with each request.

Microsoft Kerberos is…just different.  It will always be harder to catch up with what MS does in IE.  Others can tackle this.

Optimize Kerberos Authentication with a cookie Layer

If you use form based authentication, what happens is that the initial Auth is done as a standard form submit, and the application authenticates you.  The session identifier becomes a cookie (short lived, not sotred to the hard disk) that acts as an authentication token.  Kerberos could easily take this approach.  Then, Negotiate would only be done on the initial request, and all other requests until session time out would use session auth.  It will only work under SSL, but it is secure.

Tie in a SSO option Like OAuth and or OpenID

For those systems that are not using Kerberos, but that do have session based Auth, the FreeIPA system should provide a web-centric add on for Single Sign On…We’ve discussed both OAuth and OpenID.  Feedback here is Welcome.

Make it easier to have multiple Realms co-exist on a users system

Negotiate holds its cards close to its chest.  If a browser or some other network service gets a request for Kerberos negotiation, the client doesn’t know for certain which Kerberos Realm it is in.  We need a standard method of mapping Resource to Realm.  I need to talk to Red Hat services, I need to talk to Fedora Services, and I have a few other, non-work related things I do on line that should be Kerberized as well.  For example, this blog is hosted on Dreamhost, and Ideally they would use Kerberos for Auth.  It should be pretty easy to say, in certificate form,  dreamhost.com usese the CUSTOMERS.DREAMHOST.COM realm, fedorahosted.org, fedorapeople.org use FEDORAPROJECT.ORG realm, and anything that ends in readhat.com uses the Red Hat realm.

Make use of DNS delegation for virtual machines

VMs are the way of the future for much of the common use cases.  I need to be able to create, destroy, repurpose, and share virtual machines on a regular basis.  FreeIPA supports DNS, but in order to have a full solution, you need to tie in DNS, DHCP, and VM creation all together.  I’m a big fan of IPv6, and so I think this might be a great place to do a V6 only solution: Use IUPv6 as the primary network backbone for administration, and provide a dead simple mapping from libvirt virtual machine names to DNS AAAA records.

Each user gets a subdomain.  Lets say, for sake of argument, that it is username.cloud.fedoraproject.org.  If I create a new rawhide VM for testing ipa, I get an AAAA record rawhideipa.admiyo.fedoraproject.org that points to the IPv6 address generated from my MAC address.  DNS A records become an optional resource, available on request, as they need a routable IPv4 address, which VMs don’t get by default.

I realize that most of this work is outside the realm of FreeIPA, but would benefit from having FreeIPA available to make it work or make it easier to implement.