bcc0f6d6fc
Uses CMS to create tokens that can be verified without network calls. Tokens encapsulate authorization information. This includes user name and roles in JSON. The JSON document info is cryptographically signed with a private key from Keystone, in accordance with the Cryptographic Message Syntax (CMS) in DER format and then Base64 encoded. The header, footer, and line breaks are stripped to minimize the size, and slashes which are invalid in Base64 are converted to hyphens. Since signed tokens are not validated against the Keystone server, they continue to be valid until the expiration time. This means that even if a user has their roles revoked or their account disabled, those changes will not take effect until their token times out. The prototype for this is Kerberos, which has the same limitation, and has funtioned sucessfully with it for decades. It is possible to set the token time out for much shorter than the default of 8 hours, but that may mean that users tokens will time out prior to completion of long running tasks. This should be a drop in replacement for the current token production code. Although the signed token is longer than the older format, the token is still a unique stream of Alpha-Numeric characters. The auth token middle_ware is capable of handling both uuid and signed tokens. To start with, the PKI functionality is disabled. This will keep from breaking the existing deployments. However, it can be enabled with the config value: [signing] disable_pki = False The 'id_hash' column is added to the SQL schema because SQL alchemy insists on each table having a primary key. However primary keys are limited to roughly 250 Characters (768 Bytes, but there is more than 1 varchar per byte) so the ID field cannot be used as the primary key anymore. id_hash is a hash of the id column, and should be used for lookups as it is indexed. middleware/auth_token.py needs to stand alone in the other services, and uses keystone.common.cms in order to verify tokens. Token needs to have all of the data from the original authenticate code contained in the signed document, as the authenticate RPC will no longer be called in mand cases. The datetime of expiry is signed in the token. The certificates are accessible via web APIs. On the remote service side, certificates needed to authenitcate tokens are stored in /tmp/keystone-signing by default. Remote systems use Paste API to read configuration values. Certificates are retrieved only if they are not on the local system. When authenticating in Keystone systems, it still does the Database checks for token presence. This allows Keystone to continue to enforce Timeout and disabled users. The service catalog has been added to the signed token. Although this greatly increases the size of the token, it makes it consistant with what is fetched during the token authenticate checks This change also fixes time variations in expiry test. Although unrelated to the above changes, it was making testing very frustrating. For the database Upgrade scripts, we now only bring 'token' up to V1 in 001 script. This makes it possible to use the same 002 script for both upgrade and initializing a new database. Upon upgrade, the current UUID tokens are retained in the id_hash and id fields. The mechanisms to verify uuid tokens work the same as before. On downgrade, token_ids are dropped. Takes into account changes for "Raise unauthorized if tenant disabled" Bug 1003962 Change-Id: I89b5aa609143bbe09a36bfaf64758c5306e86de7 |
||
---|---|---|
.. | ||
versions | ||
__init__.py | ||
manage.py | ||
migrate.cfg | ||
README |
This is a database migration repository. More information at http://code.google.com/p/sqlalchemy-migrate/