Multi-Users for Che

[skabashnyuk]

Adding authentification - is a very frequent request from Eclipse Che community. We think that Keycloak is a rich framework that can provide many interesting features http://www.keycloak.org/about.html

From a technical perspective, it would be a separate assembly inside of Che. We don't want to remove an ability for plugin developers to have an easy and simple assembly without authentification and any heavy components for easy testing of their work. We might reuse the same approach like we did with "single port" feature. When changing some specific parameter on configuration will change the number of containers that would be running. In this case, Keycloak will be running as a separate container.

• Filter to transform Keycloak user to Eclipse Che subject
• Use Keycloak token to authenticate request in DefaultHttpJsonRequestFactory from wsmaster to wsmaster. Use Keycloak token to authenticate request in DefaultHttpJsonRequestFactory from wsmaster to wsmaster. #5427
• Keycloak client configurations Eclipse Che application authentication #5435
• Keycloak server configuration Keycloak server configuration #5436
• Ws-agent authentication Authentication on workspace agent #5434
• CQ for keycloak jars Create CQ for Keycloak server side components #5437
• Synchronize user profile with keycloak database Synchronize user profile with keycloak database #5438
• Customizing site pages related to authentication and Keycloak Customizing site pages related to authentication and Keycloak #5786
• Revise functionality of Profile & Security page on dashboard Revise functionality of Profile & Security page #5788
• The use of GWT Frame objects is not compatible with the Keycloak integration The use of GWT Frame objects is not compatible with the Keycloak integration #5745
• Configure PostgreSQL backend for multiuser Che Configure PostgreSQL backend for multiuser Che #5836
• Che-multiuser: Not able to create workspace and import sample in same time Che-multiuser: Not able to create workspace and import sample in same time #5889
• Adapt CLI to use keycloak openid authentication Adapt CLI to use keycloak openid authentication #5893
• Keycloak token expiration Keycloak token expiration #5927
• Run QA in multiuser branch and figure out what should be done to adapt QA to SPI
  Run QA in multiuser branch and figure out what should be done to adapt QA to multiuser branch #5930
• Che multiuser: allow to configure database settings over environment variables of che-server image Che multiuser: allow to configure database settings over environment variables of che-server image #5962
• Port server side of Permissions, organization/team , resource management from Codenvy to Eclipse Che Port server side of Permissions, organization , resource management from Codenvy to Eclipse Che #6041
• Transplantation of codenvy dashboard stuff to che dashboard Transplantation of codenvy dashboard stuff to che dashboard #5802
• OAuth service authentication with keycloak OAuth service authentication with keycloak #6300
• Adapt Keycloack account page styles in multiuser Che Adapt Keycloack account page styles in multiuser Che #6226
• Add ability to configure admin for che-multiuser Add ability to configure admin for che-multiuser #6402
• [MultiUser-branch] cache.js must be cached on che multiuser [MultiUser-branch] cache.js must be cached on che multiuser #6425
• Che multiuser: Move and adapt html templates from Codenvy project Che multiuser: Move and adapt html templates from Codenvy project #6515
• Che multiuser: Style organization email notifications Che multiuser: Style organization email notifications #6546
• Add ability to configure allowedClockSkewMillis parameter of JWT token parser Add ability to configure allowedClockSkewMillis parameter of JWT token parser #6565

[TylerJewell]

Based upon the discussion on the planning session today, I'd like to adjust the language slightly. You said that "From a technical perspective, it would be a separate assembly inside Che". While it could be a separate assembly that does pose certain challenges with documentation and our marketing distribution. So, I think we agreed that we'd evaluate / investigate both a configuration-based approach to activating this AND also a custom assembly. But for marketing purposes, to the degree that we can keep it in a single assembly, there are other types of advantages.

[gazarenkov]

@TylerJewell Well, what we discussed is that we should not avoid any possible manner.

To be more clear.
We have several let's say "pluggable points" (maybe forgot something):

• IDE plugins - extending either or both client / server developer experience related functionality (LSs, debuggers etc) - the biggest group supposed to be subject of SDK
• Workspace Runtime (a k a Infrastructure) providers (Docker, OS/K8s etc)
• DAO providers (we consider RDBMS based but anyway it is Postgre and H2 as minimum)
• Auth/Autorization providers (we consider single-user and KeyCloak based for the time)

There are a lot of combinations of such and we suppose third parties to be able to contribute theirs components as well (good docs needed of course) so what from your marketing perspective mean to keep it in a single assembly using configuration-based approach?
To me it sounds like your expectation is to change anything from listed with just changing some configuration parameters and rebooting (without reassembling).
Is it something like you have in mind?

[TylerJewell]

Actually, the more I think about it, our concepts may be compatible. The concept of an "assembly" in the Che sense is different from the concept of an installation given the unique qualities of our installer.

So it may be possible for us to have 1..n custom assemblies pre-built and for us to have a single installer image that knows how to install different configurations of Che (using different assemblies).

Our installer for Che is a stateless Docker container that in turn installs a che.env file. That file is what I consider the "configuration" of the system. This file's contents are used by both the installer container AND the Che server container to configure itself.

Since we have the ability to have different puppet templates that define different composable infrastructures, we could allow for different properties in che.env to activate different Che assemblies. The default assembly would:
a) all of our standard IDE plugins
b) our Docker-based workspace runtime
c) our postgres RDMS DAO provider running in a 2nd container
d) our KeyCloak implementation with the server running in a third container
e) single port activation with the traefik proxy running in a fourth container

If a user modifies the right properties in the che.env, or perhaps just runs the CLI in "dev mode" which is a feature that we have, those properties could disable the postgres RDBMS, uses no-auth for a single user, does not allow for single port with Traefik.

In these two scenarios, the CLI would need to be smart enough to use two different custom assemblies. Each custom assembly would have the elements in the server necessary to support the configuration provided.

So yes, we can have different custom assemblies, but still a single installer & che.env file that determines the layout and setup when the system starts. Roman would know how to apply this.

[skabashnyuk]

Today I've discussed folder structure what we are going to have with @gazarenkov @riuvshin And we have such proposal

V1

/assembly
  /sdk
     /assembly-main
     /assembly-*
  /small-group(onprem)
     /assembly-main
     /assembly-*    
/dockerfiles
  /sdk
     /action
     /base
     /cli
     /dev
     /init
     ..
     /test
  /small-group(onprem)
     /cli
     /init

Roman's variant

/assembly
  /sdk
     /assembly-main
     /assembly-*
  /small-group(onprem)
     /assembly-main
     /assembly-*    
/dockerfiles
  /sdk
     /action
     /base
     /cli
     /cli-small-group
     /dev
     /init-small-group
     ..
     /test

@TylerJewell wdyt?

[benoitf]

FYI, from an external user POV, the layout seems complicated to understand what is proposing what
I think we could try names like "core", "basic", "full"

[riuvshin]

Well, I actually disagree with using "small_group" in any place... In my mind "small group" means something minimalistic and lightweight while in that case "small group" means that this is EXTENDED CHE with DB, and stuff.

I would like something sdk (very basic stuff single container) and CHE where CHE is fully powered CHE.

[gazarenkov]

I would not say "sdk" name is good one. In this case I would expect something dedicatedly useful for plugin/extensions developers, not sure it is the case though.

I would better propose the name as the offering - first for "individual", second for "small group" (yes, it is rather marketing oriented, but it is what it is :) )

[benoitf]

small group let me more thinking of small group of features --> smaller than the sdk which is the opposite

[TylerJewell]

I have two things to introduce:

1. I would rather see "individual" and "workgroup". It helps to avoid terms like "simple", "full", "basic" because these are not descriptive for an end user. It could mean many things to different people on what is included in each of those definitions. Another option could be "singleuser" and "multiuser". Because really all of the customizations we are doing are because of that simple switch.

2. On the structure proposed by @skabashnyuk - I think it's going in the right direction, but I suspect that the CLI folder should not be part of each custom assembly. I think the CLI becomes smarter and lives as a peer of the multiple assemblies. We would have che.env properties that if turned on / off, automatically activates the other assembly. We could, for example, use the name of the Docker image in the /init package as a way to determine which assembly gets launched.

[benoitf]

@tyler is that "enterprise" name would match as well ?

[TylerJewell]

I thought about the use of the term "enterprise", and I chose to avoid that as I felt that it attached a number of concepts related to support, infrastructure, and configuration that we may or may not support with this particular packaging. Or, we may only want to support them if you have Che on OpenShift, which is quite different from Che on Docker. So I think the term is a bit ambiguous as it could mean different things to different people.

[benoitf]

Ok

[gazarenkov]

"individual" and "workgroup" - good for me

[gazarenkov]

See no problem having CLI as a part of each assembly, why not if it is required?

[TylerJewell]

We could have a structured tiering:

1. A top-level CLI that has master che.env. Configuration values in this file may launch different assemblies based upon how admin configures it.
2. Each assembly also has a CLI that is special purpose, just for running that local assembly and nothing else.

But I think #2 is an anti-pattern to how we intended the CLI to operate.

[gazarenkov]

I do not understand what does "A top-level CLI that has master che.env. Configuration values in this file may launch different assemblies based upon how admin configures it" mean.
It sounds like there are several assemblies packed together to let have one CLI to choose which one to run?

I would imagine assembly without mandatory CLI at all, but if assembly requires CLI why not to include it?

[TylerJewell]

I think the confusion you are running into can be solved by learning a small amount on how the CLI runs.

The CLI is a stateless, temporary container that imports a configuration from a set of files in an installation directory. It then uses that configuration to define a set of puppet manifests that are executed to generate a "configuration instance" that can run Che itself. Different properties in che.env can generate different types of "configuration instances".

The configuration instances include docker compose and other scripts necessary to start and stop Che. Since we can generate different configuration instances, those instances can generate different kinds of compose scripts that reference different Docker images.

So, we can look at the admin point of view of which properties we want on / off, and then based upon those properties we can generate compose scripts that choose to launch the single container version (with one assembly in it) or the a multi-container version with postgres, keycloak, and other software in different images / assemblies.

[gazarenkov]

OK, indeed, I misunderstand where /cli folder is placed so what inside of it.
Then I let you decide.

The only thing - I'd like to rename "assembly" on something more specific like "docker-assembly"

[TylerJewell]

It might help to define "assembly" a little bit. Is an assembly just the custom tomcat packaging that runs ws-master? Or, do we want to define an assembly to be the custom WAR, tomcat, and Docker image that packages it all together for execution?

[riuvshin]

@TylerJewell just to make it clear for me which way to go on CLI and 2 assemblies. We have following options:
CLI

1 separate CLI for multiuser che / separate che-server image

2 single CLI with ability to switch CHE assemblies (that will add some difficulties for simple single user che all images for che multi server will be pulled and maybe some other side effects)

che-server:
1 use single che-server image for both tomcat assmeblies
2 use different images for che-server (che-server and che-server-multiuser)

I personally think more about CLI 1) because it much more flexible and it will be easy if we will need add something more it will be easier to extend and with single CLI it could be nightmare of workarounds to make it work same way for both completely different products. And to me it is much easier to understand what you are actually using because you use different images for different products.
As for che-server I prefer 2 because it will be better for users who need only single user CHE they will just choose right image.
Btw we also can use separate tag for multiuser like: che-server:latest and che-server:multiuser-lates

[skabashnyuk]

2.2 - I thought we go in this way.

[riuvshin]

@skabashnyuk sorry I messed it up, now edited. THere is to topic
single / different CLI image and single / different che-server image

[TylerJewell]

Hi @riuvshin - I think what we said was 2.2:

1. Single CLI with ability to switch che assemblies based upon values in che.env.
2. Use different docker images for che-server and che-server-multiuser

On the comment for how to tag images, is that a best practice? I thought that labels should only apply to version labels? So how would you have handle version 6.1 of the multi-user image?

[riuvshin]

@TylerJewell got it.

• single cli with ability to enable multiuser mode with -e CHE_MULTIUSER=true or change it manually in che.env
• two different che images che-server (default single user) che-server-multiuser

about tags it was just a thoughts, we will go with different images.

[l0rd]

@skabashnyuk I've added the following item to the epic:

- [ ] Fix bug that currently slow down IDE in OSIO https://github.com/redhat-developer/rh-che/issues/300

[skabashnyuk]

@l0rd can you explain how they are related?

[l0rd]

@skabashnyuk that's a problem that we have noticed when keycloak authentication is enabled in rh-che. Since we don't want to continue fixing keycloak related issues on rh-che repository I've linked the issue here. Fixing it as part of this epic seemed the right thing to do.