This bugzilla is designed to track the inclusion of an upstream blueprint in the RHOS 4.0 release. Please see the URL field above for details.
Jamie, please provide info on how to test.
So there are obviously unit tests. Currently it is only implemented by keystone itself so it should be fairly easy to modify one of the basic excercises to force binding. 1. Set up a keystone HTTP environment with kerberos authentication. My httpd.conf looks like: Listen 5000 <VirtualHost *:5000> ServerName jamielennox-keystone.openstack.freeipa.org WSGIScriptAlias / /var/www/cgi-bin/keystone/main <Location /> AuthType Kerberos AuthName "OPENSTACK.FREEIPA.ORG" KrbMethodNegotiate on KrbMethodK5Passwd off KrbAuthRealms OPENSTACK.FREEIPA.ORG Krb5KeyTab /etc/httpd/conf/http.keytab KrbLocalUserMapping on KrbSaveCredentials off Require valid-user </Location> </VirtualHost> Listen 35357 <VirtualHost *:35357> ServerName jamielennox-keystone.openstack.freeipa.org WSGIScriptAlias / /var/www/cgi-bin/keystone/admin <Location /> AuthType Kerberos AuthName "OPENSTACK.FREEIPA.ORG" KrbMethodNegotiate on KrbMethodK5Passwd off KrbAuthRealms OPENSTACK.FREEIPA.ORG Krb5KeyTab /etc/httpd/conf/http.keytab KrbLocalUserMapping on KrbSaveCredentials off Require valid-user </Location> </VirtualHost> Nothing here should be surprising but ask if you have issues. You should no longer need to do the KrbLocalUserMapping, but i haven't tested it without it (ask adam about exactly how this works). 2. Turn on binding in keystone. Edit the keystone.conf file: [token] bind = kerberos enforce_token_bind = required (or kerberos) 3. Post your identity info to /v3/auth/tokens, it will return the token as a header but also the token data in the body and you should be able to see the token['bind']['kerberos'] is the principal (or username if localusermapping) 4. Use that token to do some other queries on keystone, like list my user's roles or something. Anything that requires the token be validated (which is most things outside of /v3/auth and /v2/tokens). It should succeed. Notes: you don't need to provide a username/password or token to keystone if you have a user with username that is the same as your kerberos username in the default domain. I'm not exactly sure how this works for other domains but it isn't hard. But you still need to supply an empty 'auth: {}' in your auth request. Because of this it's probably easier to not use the keystoneclient to test. The curl commands are mostly: curl -i \ --negotiate -u: \ -X GET \ -H "X-Auth-Token: $TOKEN" \ -H "Content-Type: application/json" \ -H 'User-Agent: testscript' \ $URL I had a script that did a better job of this but i think it has been lost to an older git branch. I'll help resurrect one if needed. You will need to do things like have an active kerberos ticket, and server to auth against, as well as apache restarts which i think is implied. Is this sufficient for a basic test?
Tests verified however when PKI tokens are in use BZ1035032 occurs for v3 token request.
for v3 test cases requesting pki tokens without the catalog. This is a workaround for the following issue that is unrelated to this feature. https://bugzilla.redhat.com/show_bug.cgi?id=1035032 Tests passed
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2013-1859.html