Open Stack

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?

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1292283

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

Status in OpenStack Dashboard (Horizon):
  Confirmed
Status in OpenStack Identity (Keystone):
  Triaged

Bug description:
  As part of the design process for revocation events it was determined
  that a mechanism to revoke all dependent tokens was needed. This
  covers the case of revoking a token and ensuring all tokens that were
  created from that token are also revoked.

  To accomplish this, the revocation of a specific token is done by
  expiration_time. The expiration_time attribute is never changed on
  subsequent tokens. This means it is easy to ensure revocation of an
  entire chain of tokens.

  This poses an issue if any specific token (or all tokens that are a
  child of a specific token) should be revoked, but the parent tokens
  should not be revoked.

  Use case:

  Get Unscoped token
  Get Scoped Token from Unscoped token
  Get New Scoped Token
  Revoke first unscoped token
  Now all tokens (including the Unscoped token) are revoked because they share an expiration_time.

  Likely there needs to be a solution that allows for revoking based
  upon expiration_time and issued_at and one that revokes on
  expiration_time alone. Revoking by expiration_time alone is API
  incompatible with previous API mechanisms (both V2 and V3).

  This is the reason bug https://bugs.launchpad.net/horizon/+bug/1291099
  was identified.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1292283/+subscriptions