Since negotiate isn't supported, at least basic auth support allows authenticating against our domain rather then users needing to come up with another password. The basic auth support is not specific to kerberos either, so its more generally useful.
Thanks, Kevin ________________________________________ From: Simo Sorce [s...@redhat.com] Sent: Monday, October 14, 2013 6:58 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] Keystone Apache2 Installation Question On Mon, 2013-10-14 at 14:31 -0700, Fox, Kevin M wrote: > Hi Adam, > > I was trying to get both kerberos negotiate and kerberos basic auth working. > Negotiate does not seem to be supported by any of the clients so I think it > will be a fair amount of work to get working. > > /keystone/main/v2.0/tokens can't support having an apache auth module on it, > it seems because it is overloaded to do too many things. After playing around > with it, it looks like some services (like horizon) assume they can give it a > token and get back a restricted token without doing basic auth/negotiate all > the time. You can't put auth around it in apache and Require valid-user and > still have it perform its other functions. the tokens endpoint needs to be > able to be split out so that you can do something like /auth/<type>/tokens so > you can put a different handler on each url and /tokens has all the rest of > the functionality. I guess this will have to wait for Icehouse. > > I also played around with basic auth as an alternative in the mean time to > negotiate and ran into that same issue. It also requires changes to not just > python-keystoneclient but a lot of the other python-*clients as well, and > even then, horizon breaks as described above. > > I found a work around for basic auth though that is working quite nicely. I'm > trying to get the patch through our legal department, but they are tripping > over the contributor agreement. :/ > > The trick is, if you are using basic auth, you only support a > username/password anyway and havana keystone is plugable in its handling of > username/passwords. > > So, I'll just tell you the idea of the patch so you can work on > reimplementing it if you'd like. > * I made a new file > /usr/lib/python2.6/site-packages/keystone/identity/backends/basic_auth_sql.py > * I made a class Identity that inherits from the sql Identity class. > * I overrode the _check_password function. > * I took the username/password and base64 encoded it, then make a http > request with it to whatever http basic auth service url you want to validate > with. apache on localhost works great. > * Check the result for status 200. You can even fall back to the super > class's _chck_password to support both basic auth and sql passwords if you'd > like. > > The interesting bit about this configuration is keystone does not need to be > embedded in apache to support apache basic auth, while still providing you > most of the flexability of apache basic auth plugins. The only thing that > doesn't work is REMOTE_USER rewriting. Though you could probably add that > feature in somehow using a http response header or something. If all you end up using is basic auth, what is the point of using Kerberos at all ? Basic Auth should never be used with kerberos except in exceptional cases. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
