Since my eventual goal is to Kerberize Horizon, my next step after getting a CGI solution working was to make use of the Keystone client. Since the Kerberos auth plugin is still a work-in-progress, it required a little tweaking, but not all that much.
I’ve got a packstack install, and a Kerberos-capable Keystone. Time to call it from Horizon. Time to set up S4U2Proxy.
A developer does things that are at odds with a production deployment. Case in point: the FreeIPA assumes that it should be run on an ipa-client machine. But as a developer, I need to talk to remote FreeIPA servers. Here’s how to make the CLI work without performing a client install.
Kerberos provides single sign-on. However, if you don’t take care, you will end up having to do a kinit on a remote machine. Not a big deal, but the TGT on the remote machine will not necessarily be cleaned up when you log out.
Configuring Kerberos as the authentication mechanism for Keystone is not much different than Kerberizing any other Web application. The general steps are:
- Configure Keystone to Run with an LDAP backend
- Configure Keystone to Run in Apache HTTPD
- Register the Keystone server as an Kerberos Client (I use FreeIPA)
- Establish a Kerberized URL for $OS_AUTH_URL
In a recent post, I described how I configured a web server to user mod_lookup_identity. Now, I use that configuration to provide a test for the recent Federation work in Keystone. This is a really rough proof of concept; do not expect to be able to use this in your production environments yet.
“How can I integrate Kerberos in to a Keystone server and still maintain the UserId-Password based login.”
This is a fairly simple task, and works due to the fact that the AUTH_URL used to get a token does not need to match the other URLS returned by the service catalog for identity.
“Don’t repeat yourself.” This rule is such a core principal in programming it has been reduced to the acronym DRY. Yet, somehow, every web application framework out there ends up with a custom authorization framework; LDAP, SQL, and usually a Flat File authorization list.
Apache HTTPD can and should perform a cryptographic based authentication for your users. Even better, it should be able to return to you the user attributes necessary to perform accurate authorization. REMOTE_USER has been the standard ever since CGI first appeared for the web. Now we can extend that approach to a generic set of user attributes for authorization. mod_lookup_identity.
I’m starting on a proof-of-concept setup where, instead of using the LDAP backend for Keystone, I use mod_identity_lookup to fetch the data at the HTTPD layer. Here are the steps I went to configure the system.
While Packstack makes it easy to get OpenStack up and running, it does not (yet) support joining to an existing Directory (LDAP) server. I went through this recently and here are the steps I followed.