Comment 15 for bug 1490804

This should only be a problem with PKI(Z) tokens. The fix can be made here:

http://git.openstack.org/cgit/openstack/keystone/tree/keystone/token/utils.py

Using the logic in the blog post here: http://adam.younglogic.com/2014/10/who-signed-that-token/ we can pull out the signed data from the token and take a hash of that; modifying the hashed data will mean the token will not longer pass the CMS validation.

This will pull in an additional dependency on pyasn1 to Keystone. We cannot avoid that by calculating the hash on the JSON data itself, as it will not (necessarily) be reproducible.

In addition, Horizon will need an update, as they currently Md5 Hash the tokens before sending them to the remote services.

Another possibility is to generate a UUID for the token ID, and stick that inside the JSON body before signing. revocation could be done on the UUID value instead of the HASH. That would involve changing both Keystone and keystonemiddleware.

another alternative it to compare the signer info in the PKIZ token with the Certificate. If they don't match, the token is invalid. I don't know if it is possible to be 100% certain that the teokn cannot be tampered with.