implement api key and secret authentication

[loomis]

Currently machine cookies are used to allow access to SlipStream resources from the orchestrators/machines in a deployment. Investigate whether we should change this implementation or improve the existing one. For example, the existing one could be enhanced to provide further checks on the cookie. A different implementation would be to use revocable api/secret keys, which would be valid only for the lifetime of a given deployment.

[loomis]

The decision was to start with an implementation of api/secret keys to replace machine cookies and to provide general, revocable API access to the service. The essential features of the implementation are:

• Users can generate on demand new api/secret key pairs. These can be used through the API to authenticate with the server.
• Authentication follows the standard CIMI workflow with the SessionTemplate and Session resources, allowing the client to obtain a time-limited token.
• The api/secret key pairs can be revoked by the user at any time. After this, no new access tokens can be generated with the revoked api/secret key pair.
• At creation time, the user attributes (groups, roles, etc.) will be transferred into the api/secret key and included in generated tokens thereafter. The user may optionally limit which attributes are included in the api/secret key.
• At creation time, the user may provide an expiration time for the api/secret key. If provided, the api/secret key cannot be renewed after that time.

The details of the proposal and discussion can be found in another ticket.

[loomis]

The attached PR implements all of the above features, except allowing the user to limit the roles for the API key and secret. Testing with a live SlipStream instance still needs to be carried out.

[loomis]

The roles stored when creating an API key credential also stores the current session role. This should be stripped so that future sessions do not have multiple session roles.

[loomis]

The latest changes fix the problem with the duplicated session roles.

[loomis]

Reimplementation of the machine cookies is covered in a separate ticket. #1151