Bug 986053
| Summary: | [RFE] Bind the token to A Kerberos Principal | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Adam Young <ayoung> |
| Component: | openstack-keystone | Assignee: | Jamie Lennox <jlennox> |
| Status: | CLOSED ERRATA | QA Contact: | Jeremy Agee <jagee> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4.0 | CC: | ajeain, ayoung, breeler, dpal, jlennox, kbanerje, mlopes, nkinder, sgordon |
| Target Milestone: | Upstream M2 | Keywords: | FutureFeature |
| Target Release: | 4.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| URL: | https://blueprints.launchpad.net/keystone/+spec/authentication-tied-to-token | ||
| Whiteboard: | |||
| Fixed In Version: | openstack-keystone-2013.2-0.5.b2.el6ost | Doc Type: | Enhancement |
| Doc Text: |
A feature has been added to bind a token to a kerberos token. This has been added to circumvent the following scenario:
The current security model involves bearer tokens. This means, if you hold the token, then you are the specified user and have all the privileges associated with it.
If another user were to acquire that token, they too become that user with all those privileges.
Binding a token means that a user must have both a token and the associated cryptographic identity (in this case kerberos ticket) for the token to be valid.
Tokens can be optionally bound to a Kerberos ticket.
An article on token binding and configuration can be found here: https://github.com/openstack/keystone/blob/master/doc/source/configuration.rst#token-binding
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-12-20 00:13:18 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 975499 | ||
|
Description
Adam Young
2013-07-18 21:22:51 UTC
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 |