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
bcc0f6d6fc