Authentication and Registration when user goes directly to che.openshift.io

[slemeur]

Description

To support the transition of codenvy.io to che.openshift.io, we need to handle the different authentication flow, when a user will access directly to che.openshift.io.

Proposed Flows

User, non-authenticated + not having osio account, goes to che.openshift.io

• Authentication page displayed
  • The page is today displaying only “OpenShift.io” information
  • Could we specialize the authentication page, so the user can get information that he is signing up for OpenShift.io, but will get access to cloud workspaces with Che?
• User does not have an account, he has to create a new account
  • Similarly, the page to create a new account is showing only “OpenShift.io” information
  • Could we specialize the authentication page, so the user can get information that he is signing up for OpenShift.io, but will get access to cloud workspaces with Che?
  • Sign-up emails, are specialized for “OpenShift.io” and are not including Che information.
  • Could we have a separate email, when a user is signing up in the che.openshift.io flow
• After creating the account, the user should be redirected into his dashboard on che.openshift.io

User, non-authenticated + having osio account, goes to che.openshift.io

• Authentication page displayed
  • The page is today displaying only “OpenShift.io” information
  • Could we specialize the authentication page, so the user can get information that he is signing up for OpenShift.io, but will get access to cloud workspaces with Che?
• User follow the flow to authenticate
• After authenticating, the user is redirected into his dashboard on che.openshift.io (already working)

User, authenticated, goes to che.openshift.io

• The user is redirected into his dashboard on che.openshift.io (already working)

[joshuawilson]

which team will work on this? Che or Auth or both?

[ibuziuk]

@slemeur Am I correct that in general this issue is just about adding more information about che.openshift.io and promoting it on login & registration pages since the account for accessing osio & che dashboard is going to be the same ? Or you mean that when user is redirected to login page from che dashbord the login / registration form should be che (not osio) branded (but the registration flow remains the same, so it just about applying another css theme)?

[slemeur]

@ibuziuk :
The pages you put the screenshots for are the right ones. You are right, we want to rebrand these pages but not change the registration flow.

The rebranding should:

• Change the title
  • instead of "Register for the OpenShift.io" it should be something like "Register to Eclipse Che Live" (consider Eclipse Che Live as a placeholder for now)
  • we would add a small subtitle: "Eclipse Che online instance powered by OpenShift.io"
• Change the logo in the header

[ibuziuk]

@slemeur thanks for clarification, so for me it sounds that the issue for UI / UX team. Basically, the issue is about applying different css themes based on document.referrer [1] e.g. if it "https://rhche.openshift.io/dashboard/" / "https://che.openshift.io/dashboard/" new che theme should be applied on registration pages. I guess, no input is required from Che / Auth team regarding this issue.

[1] https://developer.mozilla.org/en-US/docs/Web/API/Document/referrer

[ibuziuk]

@slemeur Joshua have added team/che/osio label but I believe it is pure UI / UX thingy, and team/ux would be more appropriate here, right ?

[joshuawilson]

@ibuziuk @slemeur you can pass it along to whatever team is working the issue. I added this one since you are writing on it.
cc @openshiftio/uxd-team

[slemeur]

@catrobson : Could your team handle this issue ?

[catrobson]

@slemeur yes, thanks for the ping as I missed this earlier. @mindreeper2420 could you work with Tiffany to get these changes into the SSO pages for Che.openshift.io branding and information?

@slemeur is there an "approved" name and logo for this already, or do we need to work with Brand on getting a new logo made?

[slemeur]

I've replied over email in a separate thread, but there is no new logo or name that we want to use here.

The users are going to be redirected to a "pure Eclipse Che" experience. We can reuse Che logo in the header. We can also have a subtitle "Powered by Red Hat on OpenShift.IO"

[davidfestal]

After various tests, discussions, and thoughts, let me add some comments of this part of the issue description (first use case):

After creating the account, the user should be redirected into his dashboard on che.openshift.io

In the context of the work on factories, the idea is that, when clicking on a factory link (from the Eclipse Che website for example) a brand new user should be finally brought to the running workspace in a single story, even if it has to perform intermediary steps for registration to RHD and OSIO. These required steps should not stop the flow that bring a new user from the factory link to the running workspace.

This is not currently possible with the existing authorization / registration flow.
Let's summarize what I just tested again here and recorded in video:

1. If the user doesn't have a RHD account and clicks on Register, then he creates a new RHD account with a given email address, and has to pass through email verification, which hopefully isn't really a blocker since the email verification link sends back to the original factory URL in a new browser tab, so that flow can continue for the user (https://youtu.be/fGZZZVY93Uc?t=149).
2. When the user is redirected from the factory URL to the RHD login and logs in (either with his RHD account or with some social media account), without being provisioned for OSIO, the Che Dashboard welcome screen directly opens but fails to show anything, since the user is not known in the OSIO authentication system (https://youtu.be/fGZZZVY93Uc?t=189).
3. So the user must interrupt the flow to manually go to the openshift.io page (https://youtu.be/fGZZZVY93Uc?t=209) and, after logging again with his RHD account, would arrive to the You are not authorized page (https://youtu.be/fGZZZVY93Uc?t=247)
4. Here he can continue the flow by clicking on signup and is redirected to the manage.openshift.com with the Queued for provisioning message (https://youtu.be/fGZZZVY93Uc?t=258)
5. But on this page the flow is broken again since he has to refresh the manage.openshift.com page until he is automatically provisioned and a button to access openshift.io appears (https://youtu.be/fGZZZVY93Uc?t=264). And at this time the initial factory URL is lost.
6. But even when the user has just been provisioned, if he opens a new tab and points to the factory URL again, Che Dashboard will correctly open, but the factory workspace will not start because the user Openshift namespaces have still not been created (update tenant operation) (https://youtu.be/fGZZZVY93Uc?t=275)
7. Finally, if the user manually visits again the openshift.io page, logs in and arrives into the getting started page (https://youtu.be/fGZZZVY93Uc?t=291), then finally retrying the factory link will bring the user to the running workspace (https://youtu.be/fGZZZVY93Uc?t=334).

What I wonder is: shouldn't we simply provide a sort of facade / proxy small application (mainly some client-side Javascript code) that would chain these steps as necessary, waiting for the intermediate asynchronous tasks to finish (provisioning and, later, tenant init), before redirecting to the real Che server URL initially requested ? Something that would be similar, for the che.openshift.io to what the wwwopenshiftio application does for the rest of Openshif.io components ?

[catrobson]

@davidfestal - Many of the things you pointed out are being discussed here: https://docs.google.com/presentation/d/1P8p_6Va1hExB3y7vZvmAxkHjliDpzOZVDaT6ox-2lG8/edit#slide=id.g3e4795d877_0_20

@sbose78 FYI

[davidfestal]

@catrobson yes, Thanks for the information. I already added some comments in this document. In fact it happens that the google doc has been created / shared while I was writing the comment above: I found it just after.

[ibuziuk]

@davidfestal thanks for the detailed analyses / explanations and the demo - https://youtu.be/fGZZZVY93Uc

What I wonder is: shouldn't we simply provide a sort of facade / proxy small application (mainly some client-side Javascript code) that would chain these steps as necessary, waiting for the intermediate asynchronous tasks to finish (provisioning and, later, tenant init), before redirecting to the real Che server URL initially requested ?

Am I correct that this would be a new app hosted on osd ? I personally like this idea more than the other proposal - https://docs.google.com/presentation/d/1P8p_6Va1hExB3y7vZvmAxkHjliDpzOZVDaT6ox-2lG8/edit#slide=id.g3e4795d877_0_75

@slemeur @l0rd improving the situation with fixing the registration flow would definitely require more time to fix, which would delay the Phase 1 of migration to codenvy.io -> che.openshift.io even more. Could we consider explicitly stating that the RHD account is required in order to get started with factories on https://www.eclipse.org/che/getting-started/ similar to codenvy.io account info that is currently on the web-site?

[davidfestal]

What I wonder is: shouldn't we simply provide a sort of facade / proxy small application (mainly some client-side Javascript code) that would chain these steps as necessary, waiting for the intermediate asynchronous tasks to finish (provisioning and, later, tenant init), before redirecting to the real Che server URL initially requested ?

Am I correct that this would be a new app hosted on osd ? I personally like this idea more than the other proposal [1]

yes, or there could be an even simpler solution implemented fully in rh-che by overriding the che.keycloak.js_adapter_url in order to use a customized version of the Keycloak client script (that would delegate to the standard one, but simply add the provisionning + init tenant steps automatically when necessary after the initial login).

That would make things fully transparent.

I'm currently testing this fully locally in a test html page (since it's pure client-side javascript). And if it works locally, it would be pretty easy to test it on dev-cluster by simply overriding the che.keycloak.js_adapter_url property to the new script available on a GitHub branch.

Do you want me to open an new issue in rh-che for the POC work ?

[ibuziuk]

Do you want me to open an new issue in rh-che for the POC work ?

@davidfestal yes, please. We discussed it with @slemeur and he confirmed that we could spend time in the current sprint on POC that would provide better UX for registrations via che.openshift.io

[davidfestal]

@slemeur @ibuziuk great !

[ibuziuk]

@slemeur @mindreeper2420 is any work still planned to re-branding of the registration pages ?

[ibuziuk]

@slemeur @l0rd FYI confirmation emails still have openshift.io branding for e2e che.openshift.io registration flow. IMO it is high time to introduce che specific template: