Impossible to get workspace list with machine token

[vzhukovs]

Describe the bug

Due to filtering restrictions for some REST service methods it is impossible to retrieve workspace list using workspace-client library with machine token.

Workspace service is configured for blocking some requests that comes with machine token: getByKey and getWorkspaces and the following filter: https://github.com/eclipse/che/blob/master/multiuser/machine-auth/che-multiuser-machine-authentication/src/main/java/org/eclipse/che/multiuser/machine/authentication/server/MachineAuthModule.java#L55-L56

che-workspace-client library's methods require user token, not machine. And on the other hand, che-theia doesn't have fully functional mechanism, which allow developer obtain user token without any workaround. So by obtaining user token means communication with keycloak authorization mechanism. Theia editor locates in iframe and there is only way to get user token is to make some "bridge" between Theia and parent inframe (Dashboard). This is the first way which can be made as a workaround, discussed with Platform Team. As for the second workaround, we may update filters by removing those two methods from filtering (getByKey and getWorkspaces), but this is not convenient, because it breaks the conception of workspace sharing. cc @skabashnyuk

In terms of Che-Theia (editor as a subject) there should be some API, which allow developer to get user token like it has been done for machine token to allow make such requests.

On the other hand, it requires modification API in che-workspace-client which will allow pass user token as parameter for such type of call.

Dependent issue: #17034

Che version

• latest
• nightly
• other: please specify

Runtime

• kubernetes (include output of kubectl version)
• Openshift (include output of oc version)
• minikube (include output of minikube version and kubectl version)
• minishift (include output of minishift version and oc version)
• docker-desktop + K8S (include output of docker version and kubectl version)
• other: (please specify)

Screenshots

Installation method

• chectl
  • provide a full command that was used to deploy Eclipse Che (including the output)
  • provide an output of chectl version command
• OperatorHub
• I don't know

Environment

• my computer
  • Windows
  • Linux
  • macOS
• Cloud
  • Amazon
  • Azure
  • GCE
  • other (please specify)
• other: please specify

[skabashnyuk]

it's not a bug. It's by design. Machine-token is a thing that grants access for a specific user to a specific workspace. Please note that using machine-token that is provided as an environment variable in the container to get the list of owner's workspaces is undesired. Since it doesn't provide necessary context about who exactly is calling - is this owner or user wich owner shared his workspace.

. As for the second workaround, we may update filters by removing those two methods from filtering (getByKey and getWorkspaces), but this is not convenient, because it breaks the conception of workspace sharing.

I don't think that it is a possible workaround. When you share one folder with someone you don't expect to give access to all your folders for reading.

[vzhukovs]

I don't think that it is a possible workaround. When you share one folder with someone you don't expect to give access to all your folders for reading.

Yep, think so.

it's not a bug.

I mean, it's a bug only in terms of che-workspace-client library, because it tries to make a request using machine-token, which is wrong. It should respect filtering and make request using user token. Using keycloak is the only painless way I see.