Che: Fallback to native Keycloak users if using OpenShift OAuth is not possible

[l0rd]

Is your enhancement related to a problem? Please describe.

When a user deploys Che on OpenShift using the operator and specifying to use OpenShift OAuth:

spec:
  auth:
    openShiftoAuth: true

the deployment faisl if it's not possible to use OpenShift OAuth (e.g. kubeadmin is the only user).

Describe the solution you'd like

If using OpenShift OAuth is not possible we should NOT fail and instead:

• issue a warning
• fall back to openShiftoAuth: false

[tolusha]

@davidfestal
Are you aware of another way to check if it is not possible to use OpenShift OAuth ?

[davidfestal]

@davidfestal
Are you aware of another way to check if it is not possible to use OpenShift OAuth ?

@tolusha I assume it's related to the sub-issue: https://github.com/eclipse/che/issues/16837

Mainly OpenShift OAuth should be disabled if the list of identity providers returned by the followingoc command is empty:

╰─ oc get oauth/cluster -o jsonpath="{.spec.identityProviders}"

Of course in the controller logic you would probably get this using the API and the non-cached client.

[AndrienkoAleksandr]

Hello @l0rd @tolusha . We implemented check identity providers using oAuth, but it works only for Openshift 4. For openshift 3 'oauth' object was encapsulated in the configuration file https://docs.openshift.com/container-platform/3.11/install_config/master_node_configuration.html#master-node-config-manual and we don't have access to this object.
@davidfestal proposed:

Couldn't we manage both cases separately:

• check OAUth for OpenShift 4 and
• keep checking Users on OpenShift 3.11 ?

@l0rd @tolusha Is this propose OK to move forward?

[l0rd]

@AndrienkoAleksandr ok from my side but I guess that this is a question related to #16837 rather then this issue right? In both cases, OCP 4 and OCP 3.11, you will fallback to native Keycloak users if you are not able to find a valid OAuth identity provider or user (this issue).

[tolusha]

@l0rd
We've decided to handle both issues in the same PR since they are very related.

@AndrienkoAleksandr
ok for me too

[AndrienkoAleksandr]

Pr's merged, so close this an issue.