Ossipee started off as OS-IPA. As it morphed into a tool for building development clusters,I realized it was more useful to split the building of the cluster from the Install and configuration of the application on that cluster. To install IPA and OpenStack, and integrate them together, we now use an ansible-playbook called Rippowam.
Keystone Tokens are bearer tokens, and bearer tokens are vulnerable to replay attacks. What if we wanted to get rid of them?
OpenStack Keystone tokens can become too big to fit in the headers between mod_wsgi and the WSGI applications. Compression mitigates the problem somewhat, but if token sizes continue to grow, eventually they outpace the benefits of compression. How can we keep them to a minimal size?
In my last post, I discussed how to extract the signing information out of a token. But just because the signature on a document is valid does not mean that the user who signed it was authorized to do so. How can we got from a signature to validating a token? Can we use that same mechanism to sign other OpenStack messages?
The specification For multiple signers requires a mechanism to determine who signed the token and then determine I’d the signer had the authority to issue a token for the scope of the token. These are the steps he he necessary to perform that validation.
Many people have questioned why I chose to use popen to call the OpenSSL binary from Keystone and the auth_token middleware. Here is my rationale:
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.
Horizon is the Web Dashboard for OpenStack. Since it manages some very sensitive information, it should be accessed via SSL. I’ve written up in the past how to do this for a generic web server. Here is how to apply that approach to Horizon.
The PKI version of the Keystone tokens use a standard format for cryptographic signing of documents. Crypto Message Syntax (CMS) is the mechanism behind S/MIME and is well supported by the major cryptographic libraries: OpenSSL and NSS both have well documented CMS support. Messaging in OpenStack requires guaranteed identification of the author.