Inactivate API keys instead of deleting them

[billkalter]

What is the Issue?

Currently when an API key is deleted it is fully removed from the system via a record deletion. There are several reasons why this is not desirable:

• Any historical record concerning the API is lost, such as who owned it and what roles it had.
• Although extremely unlikely it is possible that a new API is created which hashes to the same value as a deleted key. Were this to happen the deleted API key could then be used and would authenticate as the new API key. Keeping around deleted API keys prevents inadvertent reactivation by hash collisions.
• There are proposed features for EmoDB which involve object ownership by an API key. There is already an element of this with owned databus subscriptions. Although currently not an issue deleting API keys could leave harmful dangling references in the future.

The proposed solution is to instead have a state on an API key with the following possible values:

• active
  • Normal state where a key is in use
• inactive
  • State which indicates the key has been "deleted" and should not longer authenticate
• migrated
  • State for a key which was compromised and migrated to a new key using API key administration tool. This is functionally similar to inactive but provides more context to the reason. It also allows for multiple records with the same internal ID while allowing the system to distinguish which one can authenticate. In other words if there are n API key entries with the same internal ID then n-1 of them will be in the migrated state.

How to Test and Verify

There are no errors caused by this issue. The only way to very is to query the authorization tables directly and verify that a key has been deleted after the API key administration task to delete the key has been called.

Risk

Risk is fairly low. So long as the existing API key realm only authenticates or authorizes keys in the active state then the rest of the system should be unaffected.

Level

Medium. While the changes are localized there are some nuances in ensuring authentication behaves as expected, especially concerning key migration.

Issue Checklist

• Make sure to label the issue.
• Well documented description of use-cases and bugs.