The files are reformatted in order to suit the requirements of coveo maven fmt plug-in of v.2.5.1
Signed-off-by: Victor Rubezhny <vrubezhny@redhat.com>
Previously, it banned only update profile attributes of the specified user
(PUT /profile/{USER_ID}/attributes) but methods related to current user
were still available (DELETE /profile/attributes and PUT
/profile/attributes)
* Improve wsmaster OpenIdConnect configurability, and helm deployment scripts
- Make username claim configurable in cases
Oidc provider does not support the default claim (default is "preferred_user")
- Introduce fallback for username (issuer+subject) if the username claim is not present
in the token
- Extend helm scripts to take customOidcProvider and customOidcUsernameClaim
parameters into account when deploying che master.
- Introduce cheDedicatedKeycloak global param, conditioning if dedicated che
keycloak server should be deployed, and waited on by the master.
- default value for cheDedicatedKeycloak (if not defined) is true
if the cheDedicatedKeycloak parameter is defined and is false,
customOidcProvicer must be supplied, when using multiuser mode.
Signed-off-by: Sergey Kuperman <sergey.kuperman@sap.com>
* Code review fixes
Remove the extra if condition in configmap.yaml
Remove extra line in requirements.yaml
fix typo in deployment.yaml
* Add che.keycloak.username_claim property as NULL into multiuser.properties
* Simplify helm conditions, when deploying che master with or without keycloak
if multiuser = true, and .Values.customOidcProvider was supplied, assumption is that
we work with no keycloak (no waiting in deployment)
global.cheDedicatedKeycloak is still needed as separate variable for requirements.yaml to determine whether keycloak chart should be installed
so for keycloak deployment, no parameters need to be passed beside global.multiuser=true,
for custom OIDC :
.Values.customOidcProvider=http://url, and global.cheDedicatedKeycloak=false
both need to be set
* Support identity provider token retrieval in both JSON or URL formats.
That's required because some identity providers (such a `openshift-v3`)
correctly return the token information in JSON, as expected. So
switching to the url-based syntax should only used when the returned
json is invalid.
Signed-off-by: David Festal <dfestal@redhat.com>
* Introduce an `OpenShiftClientConfigFactory` to allow customizing the OpenShift config returned according to the current context (workspace ID, current user)
Signed-off-by: David Festal <dfestal@redhat.com>
* Openshift Infra + Multi-user => allow using OpenShift identity provider to connect to openshift with the OS oauth token of the current Che user.
This introduces a new property:
`che.infra.openshift.oauth_identity_provider`
Signed-off-by: David Festal <dfestal@redhat.com>
* Notify the user when a workspace cannot be started from the nav bar.
Signed-off-by: David Festal <dfestal@redhat.com>
* Add the ability to install the Openshift certificate into Keycloak
Signed-off-by: David Festal <dfestal@redhat.com>
* Add a yaml file to provide the openshift certificate as a secret,
in case it has to be installed into the dedicated Keycloak server.
Then the commands to install Che multiuser on Minishift with this
certificate are:
```
oc new-project che
oc process -f multi/openshift-certificate-secret.yaml -p
CERTIFICATE="$(minishift ssh docker exec origin /bin/cat
./openshift.local.config/master/ca.crt)" | oc apply -f -; \
oc new-app -f multi/postgres-template.yaml; \
oc new-app -f multi/keycloak-template.yaml -p ROUTING_SUFFIX=$(minishift
ip).nip.io; \
oc apply -f pvc/che-server-pvc.yaml; \
oc new-app -f che-server-template.yaml -p ROUTING_SUFFIX=$(minishift
ip).nip.io -p CHE_MULTIUSER=true -p
CHE_INFRA_OPENSHIFT_OAUTH__IDENTITY__PROVIDER=openshift-v3; \
oc set volume dc/che --add -m /data --name=che-data-volume
--claim-name=che-data-volume
```
Of course it's still needed to register the `openshift-v3` identity
provider in the Keycloak server, as well as, add the corresponding
`OAuthClient` object in Minihshift.
Signed-off-by: David Festal <dfestal@redhat.com>
* Add processing of runtime exceptions during JWT tokens validation
It is needed to set correct 403 response code instead of 500.
Also added response message to notify a client about error reason.
Allow switching to an alternate OIDC provider (provided that it emits access tokens as JWT tokens).
This is the implementation required in upstream Che, for issues
redhat-developer/rh-che#502 and
redhat-developer/rh-che#525
Signed-off-by: David Festal <dfestal@redhat.com>
* Make it possible to tell IDE to use a different "wsagent" server passing server's ref prefix through query parameter
Signed-off-by: Artem Zatsarynnyi <azatsary@redhat.com>
Adapted modules to gwt-lib/gwt-app lifecycle;
shared libs have been cleaned up from the GWT related stuff;
enabled launching Super DevMode with a reactor goal gwt:codeserver;
enabled launching Super DevMode inside a dev-machine (for Che in Che development);
separate compiling IDE GWT app from packaging IDE Web app.
Signed-off-by: Artem Zatsarynnyi <azatsary@redhat.com>
* Fixed possible constraint violation with an existed organization.
Usecase is following:
If we have already an organization with name, let's say "org" and the new user also has name "org" then we will have constraint violation.
In this case, we will try to create the user with name "org"+random string.
Multi-user Eclipse Che (#6441)
#### How to run it.
```docker run -it -e CHE_MULTIUSER=true -e CHE_HOST=<your ip> -e CHE_KEYCLOAK_AUTH-SERVER-URL=http://<your ip>:5050/auth -v /var/run/docker.sock:/var/run/docker.sock -v ~/.che-multiuser:/data eclipse/che:nightly start --skip:pull --skip:nightly```
#### How to manage it
- Keycloak configured with two realms. ```Master``` and ```che```. Also we have one user admin/admin in both realm. Admin user in master realm is - super admin.
- Eclipse Che configured for che realm
- We enabled user registration in ```Che``` realm
#### Known limitation
- swagger would not work. We need to upgrade a version. to support openid authentification https://github.com/eclipse/che/issues/6015
- It's working on local docker. We are going to provide scalable version based on OpenShift on next versions.
- Invitation of non-existent users to Eclipse Che organization https://github.com/eclipse/che/issues/6335
#### How to run it when it is in a branch
To run an multiuser Che version, the following steps are required after building the branch:
- Rebuild init, cli and che images (in the given sequence). To do that, proceed to folder _dockerfiles/<image_name>_ and run _build.sh_
- Run Che in a usual way using cli, with additional parameters: `-e CHE_MULTIUSER=true` and `--skip:pull --skip:nightly`
Full command example:
`docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock -v /home/user/.che:/data -e CHE_MULTIUSER=true eclipse/che-cli:nightly start --skip:pull --skip:nightly`
- MacOS users may need to edit _che.env_ file in the data folder, changing `CHE_HOST` and `CHE_KEYCLOAK_AUTH__SERVER__URL` values to their specific IP.
When start is succeeded, the following docker containers should be created:
- che, exposing 8080 port;
- che_keycloak, exposing 5050 port;
- che_postgres, exposing 5432 port;
It is needed since it is secured by permissions system which requires
an authenticated user.
Also, use base API endpoint for checking Che in OpenShift deploy
script since system state API which was used before is secured now.
Signed-off-by: Oleksandr Garagatyi <ogaragat@redhat.com>
Sergii Leshchenko