PKI Signed Tokens

Fix proposed to branch: master
Review: https://review.openstack.org/7754

The proposed TTL token is 8 hours. How do we deal with token revocation?

We don't on the first pass. If 8 hours is too long for policy, make it shorter.

This is the approach followed by Kerberos, and it has been fairly successful.

I have a write up for a Revocation scheme should we need it, but I think it unnecessarily complicates the system.

Note that I think if we use PKI signed token authentication, we should remove the ability to do token chaining, where one token is allowed to request the next without the user re-authenticating themselves manually, as that is a huge security hole.

ayoung: I strongly disagree that token revocation is an unnecessary complication. If a user account is found to be compromised, issued tokens for that account need to be rendered invalid as quickly as possible. If you don't agree, consider raising this issue on the mailing list. I would be very interested to hear whether any cloud services provider agrees with your assertion that they should not be concerned about the potential impact this could have on their reputation.

Reviewed: https://review.openstack.org/7754
Committed: http://github.com/openstack/keystone/commit/bcc0f6d6fc1f674bc4b340d041b28bc1cfddf66a
Submitter: Jenkins
Branch: master

commit bcc0f6d6fc1f674bc4b340d041b28bc1cfddf66a
Author: Adam Young <email address hidden>
Date: Mon Jul 2 22:18:36 2012 -0400

    Cryptographically Signed tokens

    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 K...

Fix proposed to branch: master
Review: https://review.openstack.org/10545

Reviewed: https://review.openstack.org/10545
Committed: http://github.com/openstack/keystone/commit/ba8f351c6b72c2c49b070bf5e5551ff26fd3402b
Submitter: Jenkins
Branch: master

commit ba8f351c6b72c2c49b070bf5e5551ff26fd3402b
Author: Dolph Mathews <email address hidden>
Date: Mon Jul 30 11:23:32 2012 -0500

    Assert adminness on token validation (bug 1030968)

    - Only affects non-PKI tokens

    - Includes style changes following bug 1003962
      - Fixed redundant imports & import order
      - Fixed single quote consistency
      - Fixed line continuations
      - Refactored a bit for readability

    Change-Id: I2d2566c615919f4968fd5636744fdb613b8fa3ad