Make it possible to use keycloak from workspace IDE part

[vinokurig]

Is your task related to a problem? Please describe.

Dashboard loads keycloak script to be able to retrieve authorisation token:
https://github.com/eclipse/che/blob/dfdc304120cb3286071f4f8a0ded2df0d9b805e4/dashboard/src/app/index.module.ts#L71-L77
We need to have the same mechanism for all IDE containers to be able to authorise api requests with jwt token e.g oAuth request:
https://github.com/eclipse/che/blob/11bbcf0c10cd7cb30a9643ee5ddf9bc59d9677b1/multiuser/keycloak/che-multiuser-keycloak-server/src/main/java/org/eclipse/che/multiuser/keycloak/server/oauth2/DelegatedOAuthAPI.java#L60-L63
The problem is that the IDE url e.g http://serverliy59p5x-jwtproxy-server-4401.192.168.99.181.nip.io/ is not static like the dashboard url, but the keycloak oauth requires redirect URI which is not so flexible: https://issues.redhat.com/browse/KEYCLOAK-5943?jql=text%20~%20%22Valid%20Redirect%20URIs%22.

The other problem is that keycloak in Che is configured to use Web Origins with the dashboard url, and it doesn't support url patterns as well:

Describe the solution you'd like

Allowing all redirect Uris and disabling CORS Web origins in keycloak will make it possible to apply keycloak in an IDE client.

Describe alternatives you've considered

Additional context

[vinokurig]

@l0rd @benoitf @skabashnyuk WDYT?

[skabashnyuk]

As I remember last time this topic was touch it was a big security concern for OSIO.
I doubt that this is a good idea from security point of view since it will break the whole idea of isolation workspaces authentification from the identity provider that is used to access che server.

[benoitf]

As it's part of github Pull requests, from UX perspective, I guess the user doesn't want to authenticate twice ?
Does Che/Theia needs to access this token directly or it can be delegated to another service ?

[vinokurig]

@benoitf

As it's part of github Pull requests, from UX perspective, I guess the user doesn't want to authenticate twice ?

It is a part of github Pull request flow and this one is needed to NOT to authenticate twice.

Does Che/Theia needs to access this token directly or it can be delegated to another service ?

I don't know another ways to get a jwt token except keycloak service

[skabashnyuk]

At this moment I don't see a way how to get keycloak token from the IDE part or exchange machine token to keycloak token.
CC @l0rd

[l0rd]

@vinokurig I am not sure I understand what you are trying to solve here (I suspect that #14217 is outdated) so let me try to summarize it here:

The Context
When the GH Pull Request VS Code Extension is run the first time users are requested to grant VS Code to access to their GH token. In Che Theia scenario we need to change that so that users grant Che, not VS Code, to access the GH token.

The Problem
VS Code OAuth server is hardcoded in the VS Code Extension source code and we do not have any way to dynamically replace it with Che OAuth server.

The (obvious) Solution
Submit a PR to the GH Pull Request extension to make the the OAuth server configurable.

The (alternative) Solution
Retrieve the GH Token before the GH Pull Request extension is loaded so that the request to grant VS Code to access the user GH token is never shown.

@vinokurig @ericwill if the description is correct please update #14217 and in particular:

• why we are not working on the (obvious) solution
• why we need to retrieve the GH token IDE side and don't retrieve the GH token wsmaster/dashboard side and persist it in the user preferences in the (alternative) solution

[vinokurig]

@l0rd

why we are not working on the (obvious) solution

Before start working on the GitHub plugin we need to be sure that we can retrieve GitHub token from IDE side.

why we need to retrieve the GH token IDE side

Because the GitHub PR plugin is located in the IDE side.

and don't retrieve the GH token wsmaster/dashboard side and persist it in the user preferences in the (alternative) solution

It can be a solution, but we all have to be agree with it. I think we need to schedule a meeting for this question.

[l0rd]

@vinokurig we can have a brief discussion about it tomorrow during prioritization. If we need more time let's have a dedicated call.