Feature overview

Provide access to the API through a single use token based authentication instead of using user and password with default RBAC provided by the platform

Goals

• Create a secure way to use the API for automation, so the user does not need to work with user credentials and store them in their automation platform
• Being able to generate tokens for automation that

• • Are automatically renewed (check with security)
  • Provide user authentication (RBAC will be that of the user)
  • Possibly provide a subset of the RBAC (to reduce access capabilities to only those needed by automation

Requirements

• As a customer, I want to be able to add token-based access to the API, without the need to create new users or update the user itself, in order to get better control of what is used to access the environment. Those tokens will not provide access to the GUI.
• As a customer, I want to be able to specify what pieces of the API and GUI can be accessed with the token (i.e. GUI access or not, access to one application or many)
• As a customer, I want to be able to revoke a token that was previously accessed.
• As a customer, I want to see a list of tokens that have been created, with the date when they were created and the last time they were used to access the system, with information about the connection (IP, region, etc).
• As a customer, I want to be able to see a list of the last x times a token has been used, with their access information (IP, DNS name, geographical information)
• As an admin, I want to be able to access other user tokens in my organisation, see them and revoke them.

Background and strategic fit

Our customers need a solution for chargeback and showback and can use most of the information provided by the API. Providing user and password as means to access cost management implies:

1. That the automation engine needs access to user and password, that can possibly provide access to additional GUI and capabilities not required by the API, and thus creates a security problem
2. If the user changes the password, the automation will stop working without any way of notifying the user of that event.
3. The only way to revoke access to an automation platform is to change the password, that will break any automation.
4. There is no way of differentiate access to the GUI and through the API, so any automation or user access will be perceived as the same, unless the customer creates a new user for each automation integration, moving the problem to user and RBAC management

Out of scope

• Tokens that last for a specific time or are no longer active after a date.
• Automatically renewal of tokens