Project

General

Profile

action #86063

coordination #58184: [saga][epic][use case] full version control awareness within openQA, e.g. user forks and branches, fully versioned test schedules and configuration settings

action #48641: [epic] Trigger openQA tests in pull requests of any product github pull request

[epic] Add possibility to trigger openQA API calls, e.g. single "jobs", without the need of the client / over the webUI / with curl

Added by okurz 7 months ago. Updated 28 days ago.

Status:
Blocked
Priority:
Low
Assignee:
Category:
Feature requests
Target version:
Start date:
2021-01-13
Due date:
% Done:

50%

Estimated time:
(Total: 0.00 h)
Difficulty:

Description

Motivation

Most of openQA functionality is available over the webUI with prominent exceptions like "trigger tests". To allow easier workflows for web centric users or for easier integration into infrastructures where no custom "openQA client" can be called but only HTTP endpoints we should offer such possibility

Acceptance criteria

  • AC1: openQA jobs with arbitrary parameters can be triggered over the webUI for authenticated users with right permissions (operator+)
  • AC2: openQA jobs can be triggered with single curl calls
  • AC3: All openQA API calls with known exceptions can be conducted without needing an openQA CLI

Suggestions

e.g. a POST route where one can authenticate with username+password forwarded to any external authentication service or existing API key+secret. Within the webUI a POST request could be sent from an authenticated webUI form, e.g. a single simple textfield taking all parameters that the openQA CLIs would also take.

github_scopes.png (509 KB) github_scopes.png GitHub example kraih, 2021-02-01 14:51
10969

Subtasks

action #87698: openQA jobs can be triggered with single curl callsResolvedkraih

action #90788: openQA jobs with arbitrary parameters can be triggered over the webUI for authenticated users with right permissions (operator+)Workable


Related issues

Copied to openQA Project - action #87695: [epic] full openQA test development, maintenance and administration from browser without the need of a local terminalNew

History

#1 Updated by ilausuch 7 months ago

For authentication method, I suggest JWT (https://en.wikipedia.org/wiki/JSON_Web_Token) (https://jwt.io/)
Once you have authenticated you receive a token that will be used in next calls to the API
Is an standard (https://tools.ietf.org/html/rfc7519)
And exist perl libraries
cpanm Crypt::JWT

#2 Updated by okurz 7 months ago

  • Description updated (diff)

#3 Updated by okurz 7 months ago

  • Description updated (diff)
  • Status changed from New to Workable
  • Assignee set to okurz

discussed with team, all ACs sound valid, should create user stories.

#4 Updated by okurz 6 months ago

  • Copied to action #87695: [epic] full openQA test development, maintenance and administration from browser without the need of a local terminal added

#5 Updated by okurz 6 months ago

  • Status changed from Workable to Blocked

I have created a related epic #87695 and created one user story that we can start with: #86063

#6 Updated by kraih 6 months ago

I'd also like to put the idea of personal access tokens into the room. Similar to how GitHub handles the problem. Those are pre-negotiated keys stored with the user profile that do not expire on their own. They are created and deleted by the users themselves in the ui. And then used like curl -u username:token https://api.github.com/....

#7 Updated by kraih 6 months ago

For temporary expiring tokens i do like the idea of using JWT (Mojo::JWT is another option there). Perhaps as a starting point we could have a new operators menu entry for access tokens. And on that page only give out one temporary JWT token that expires after 48 hours. But that in the meantime could be used for curl -u username:jwttoken ... access. Every time you refresh the page you would get a new JWT token. If we later decide we want real persistent personal access tokens that could easily be added using the same infrastructure. Workflow for the user would stay pretty much the same.

Btw. One downside of JWT is that they can get a bit long.

curl -u kraih:eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2MTE4NDMzNDcsInVzZXIiOiJrcmFpaCJ9.uKb_e-Fe_fN0COVMcK3zawP00gALO6YeEswCibMree0 /api/...

This one only contains my nick and an expiration time.

#8 Updated by okurz 6 months ago

What do you see as benefit for temporary expiring tokens? And what is the difference for user access tokens vs. apisecrets? They are also already created by users themselves

#9 Updated by kraih 6 months ago

10969

okurz wrote:

What do you see as benefit for temporary expiring tokens?

The requirements for the user workflow are currently very vague. Temporary expiring tokens give us the most freedom to figure out what exactly users want and modify the system based on feedback. Access control levels could be added/changed without the need for database migrations.

okurz wrote:

And what is the difference for user access tokens vs. apisecrets? They are also already created by users themselves

Good point. It really depends on what workflow we end up with. Reusing "$user:$key$secret" as access token could be enough if we are sure that level of access control is all we need. And would be the easiest solution for me to implement. Here's a few question that need to be answered first though:

  • Should access tokens always have the same level of access as the user that created them? GitHub has fine grained access levels to mitigate security risks (i've attached a screenshot as example).
  • What additional information would we need to keep for API keys? At the very least a comment field to remember what automated service an API key has been created for comes to mind.
  • How much flexibility do we need for future changes to the personal access token system? Changes to the key+secret system have a risk of interfering with micro service IPC and other existing OpenQA::Client uses. Which are much more important than user automation scripts.
  • How much do we trust our users to not use one pair of key+secret for absolutely everything and ignore security risks completely? Do we care?
  • Is there no chance at all we might need a token access level below operator in he future? Perhaps for certain read-only endpoints?

There's probably more, but these are the main topics i've had on my mind.

#10 Updated by okurz 6 months ago

kraih wrote:

okurz wrote:

What do you see as benefit for temporary expiring tokens?

The requirements for the user workflow are currently very vague. Temporary expiring tokens give us the most freedom to figure out what exactly users want and modify the system based on feedback. Access control levels could be added/changed without the need for database migrations.

We should not be scared of database migrations. Not that we should necessarily design that we would always need database migrations to introduce more fine grained details for access control levels but to introduce the concept of a more fine grained control in general. Currently I see any access control levels going further than the current "unauthenticated/user/operator/admin" levels out of scope for the work to be planned here.

okurz wrote:

And what is the difference for user access tokens vs. apisecrets? They are also already created by users themselves

Good point. It really depends on what workflow we end up with. Reusing "$user:$key$secret" as access token could be enough if we are sure that level of access control is all we need. And would be the easiest solution for me to implement.

Yes, that is all that we currently need.

Here's a few question that need to be answered first though:

  • Should access tokens always have the same level of access as the user that created them? GitHub has fine grained access levels to mitigate security risks (i've attached a screenshot as example).

I can see the screenshot. And I think github is a nice example but I do not see that we need that as openQA is not a "single closed-source service" but a server that we market to be installable by users even for single-person instances as well as have multi-user instances but with the limit of not needing more fine grained access levels. So in short: For now, yes, access tokens should always have the same level of access as the user that created them

  • What additional information would we need to keep for API keys? At the very least a comment field to remember what automated service an API key has been created for comes to mind.

yes, an optional comment sounds good.

  • How much flexibility do we need for future changes to the personal access token system? Changes to the key+secret system have a risk of interfering with micro service IPC and other existing OpenQA::Client uses. Which are much more important than user automation scripts.

I agree but I am confident that in the case we even would need such change we can get along with a migration and stringent inter-dependency of services key+secret API version.

  • How much do we trust our users to not use one pair of key+secret for absolutely everything and ignore security risks completely? Do we care?

I am sure that the majority of users will use one pair for everything and some of them will leak the details in the web :D But we should not care.

  • Is there no chance at all we might need a token access level below operator in he future? Perhaps for certain read-only endpoints?

Well, certainly there is a chance but what would that interfer with now? And another point: Right now an authenticated user can actually not do that much so from my experience existing users ask soon to become "operator", meaning that should give us some leeway to give "user" more permissions when we see good, limited new use cases for that.

#11 Updated by okurz 28 days ago

  • Target version changed from Ready to future

Also available in: Atom PDF