revocation events: deleting a token revokes all tokens with same expiration

Added Horizon project to this bug as the solution should include both keystone and horizon teams to determine the expected (and correct) behavior going forward.

I wrote a tempest test that I thought would show this problem, but it works for me: https://review.openstack.org/#/c/80838/1/tempest/api/identity/admin/test_tokens.py

In the summit session on the topic, we discussed emitting as much detail about the token being revoked as possible, specifically including the expiration (not just the expiration). For example, with the project_id and user_id included, you wouldn't risk any impact on the unscoped token, or tokens scoped to other projects.

Reviewed: https://review.openstack.org/80441
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=7c9746c49b7518f2a000f7e4822e822c6eeee81d
Submitter: Jenkins
Branch: master

commit 7c9746c49b7518f2a000f7e4822e822c6eeee81d
Author: Adam Young <email address hidden>
Date: Thu Mar 13 21:11:54 2014 -0400

    Don't automatically enable revocation events.

    Cuts any direct imports of revoke.model as that
    triggers the dependency registration.

    In order to fix a dependecy resolution issue, changes the syncronziation to
    using the same sort of chaching mechanism as the other drivers.

    Adds the ability to Lazy activate providers for future or optional dependency
    resolution.

    Closes-Bug: 1291099
    Related-Bug: 1292283
    Change-Id: I0db36b295c2040ec1fb248cf75dc55c44c059211

Revoking tokens based on either their creation time or expiration time is conceptually wrong, because you can never guarantee that two totally unrelated tokens do not have the same time stamps. So revoking one would automatically revoke the other, and this is undesirable. Tokens should have unique serial numbers, and revocation should be based on this. In this way you can guarantee to revoke any single token without impacting any other token. If you want to revoke a family of delegated tokens, then you could hold the parent serial number in the child token, and revoke parent and child either together or separately, or revoke all tokens with the same parent serial number. For grandparents you would need to follow the lineage - but how deep are these trees likely to get?

Hi David,

We are actually moving to just that, a unique id for the token. Each token will hopefully also have an option original parent token id (eg for audit you know what the first non-rescoped token unique id is.

Hopefully In the next release or so we can also limit the depth of the token chain by limiting rescope of token to only occur from the unscoped token (separate bug/spec that is still being discussed).

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

Reviewed: https://review.openstack.org/114864
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=ea185a25a235d339d0d9282fbc08905fa1949b92
Submitter: Jenkins
Branch: master

commit ea185a25a235d339d0d9282fbc08905fa1949b92
Author: Morgan Fainberg <email address hidden>
Date: Mon Aug 25 20:17:47 2014 -0700

    Revoke by Audit Id / Audit Id Chain instead of expires

    Instead of using the expiry of the token which can collide (is non
    unique in some/many cases) use the new Audit ID for the tokens when
    revoking a single token via the token revocation events.

    Support for revoking by the audit_chain_id has been added to the
    token provider, however, the REST API has not been updated to
    accept an argument to revoke the chain. Support for revoking
    the entire chain is in place to allow Keystone to internally
    revoke an entire chain in certain circumstances. Exposing the
    ability to revoke the entire chain via the REST API may occur
    based upon further design discussions.

    Change-Id: I840355ccd9bcfcd88aa139184731c056808c2c8f
    bp: non-persistent-tokens
    Closes-Bug: 1292283

With Morgan's changes to revocation events (use of audit id), only the unscoped token will be revoked. This matches how revocations worked with the revocation list.

I don't think that there's anything that Horizon could do about this, unless it's going to change to handle tokens being revoked (as it should anyways, because they can be revoked at any time due to a password change).

I agree with Brant's assessment.

This is no longer valid for Horizon

This was included in Juno-3, targeting at juno-RC so it can be included in release documents.