Refactor API key and role administration as a public endpoint

[billkalter]

What is the Issue?

Currently API keys and roles are administered using DropWizard tasks, ApiKeyAdminTask and RoleAdminTask respectively. It would be more beneficial if API keys are roles were administered using standard REST endpoints for several reasons:

• Simplifies the API
• Simplifies the ability to build a UI on top of API key and role administration
• Allows delegation of API key and role management without requiring non-administrators to use the less-accessible Task interface

As part of this refactoring the administration API should also be changed to expose each API key's internal ID. Administration API methods to modify the API key (add roles, delete, etc.) should be changed to use the internal ID and not the key itself. There are several reasons for this change:

• API keys are supposed to be secret. In our experience people requesting new permissions have been overly cavalier in giving administrators their API keys as required by the current tasks, such as in an email or chat room, thereby risking their exposure to third parties.
• API keys are stored nowhere in the system except as hashes. If an API key is lost there is no good way to delete the key since the API requires the key but no one knows it. The current work-around is to scan the entire API key table to find the match, such as by owner or description. However, even then the API key can't be recovered since it is only a hash, so we are forced to back-door delete the record using the sor interfaces instead of using the task. This then requires restarting all EmoDB instances in all environments to force them to flush their API key caches.

How to Test and Verify

Not really anything to test or verify, other than that the current administration is indeed performed through tasks and requires use the of an API key to modify the key in any way.

Risk

This is a low risk change since it is largely just refactoring existing capabilities. Emo already has the ability to restrict REST calls based on permissions, so using that system to protect API key and role administration endpoints from users without the necessary permissions should be straightforward. The largest risk is the switch to using internal IDs for administration. However, this should be safe because:

• It is not possible for a standard user to query the __auth:keys or __auth:internal_ids tables, so there is no way for them to back-door lookup information about an API key from their internal ID.
• It is not possible to authenticate using an internal ID for any public endpoint.
• The internal ID and API key are constructed independently, so knowing one gives no information about the value of the other.

Level

Medium

Issue Checklist

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