WX-723 Updating JM OAuth libraries

[JVThomas]

Addresses WX-723

NOTE/REMINDER: Make sure redirectUri is updated in GCP for all environments before merging code in

PR aims to replace Google's soon to be deprecated Sign-In With Javascript Platform Library flow with an implicit flow option facilitated by angular-oauth-oidc. Previously JM relied on this library to handle Authorization, Authentication, and Session management, which means the application is now on the hook to handle implementation for each.

Google provides their own library to handle the transition, but there are caveats.

• The authentication and authorization prompts are handled by two different clients, each with it's own user pop-flow. For context, authentication will provide details like user info whereas authorization handles API interactions through defined scopes and access_tokens. JM requires both in order to provide its current functionality.

  • With different pop-up flows, the user is forced to "log-in twice", once to approve authentication, the other to approve authorization

In order to avoid the double log-in prompt, I've opted to use the angular-oauth2-oidc and the Open ID Connect (OIDC) identity layer to handle both authorization and authentication in one step. In addition, I've opted to use the implicit flow over the authorization flow for the following reasons:

1. It supports JM instances in both Terra AND non-Terra environments. Simply copying over Terra's implementation does not work for JM instances that do not use and/or have access to SAM or Firecloud-Orchestration.

2. It's a quick update. Implementing a self-contained authorization flow would have required using either an in-memory store or database to associate users with their active refresh tokens for proper token management.

   • This would require more investigation and possible rewrites to the python backend. Off the top of my head active OAuth libraries (authlib for example) are compiled in python3. The libraries used with JM's Flask API are built with python2 so the upgrade path is going to break more than just a few things.
   • Requiring a datastore of any kind means that current maintainers of JM instances are on the hook for the set-up.

With that out of the way, if you want to test this locally you can go about it in one of two ways.

1. You can run JM locally against a local Cromwell instance. You can follow the server setup instructions to get it up and running.

   • In JM, update the clientId in ui/assets/environments/environment.json so that is uses the value from the JM dev instance on GCP (DSDE Development).
   • Visit http://localhost:4200/ to view the app.

2. You can mimic Terra by running local instances of Terra-UI and JM. This requires a bit more work to get going

   • In the terra-ui repo, update config > dev.json, update jobManagerUrlRoot so that is points to

     http://localhost:4200/jobs

   • In JM, update the clientId in ui/assets/environments/envirornment.cromwell.caas.json so that it uses the value from the JM dev instance on GCP (DSDE Development).

   • Update the CROMWELL_URL in cromwell-caas-compose.yml so that its set as...

     CROMWELL_URL=${CROMWELL_URL:-https://firecloud-orchestration.dsde-dev.broadinstitute.org/api/workflows/v1}

   • Ensure that you have a capabilities_config.json configured that enables and supports OAuth operations. See servers/cromwell/README.md for configuration steps.

   • Visit http://localhost:3000 to view your locally running Terra UI. By default it'll point to dev so you can test with the workspaces and jobs you have setup there.

[jgainerdewar]

@JVThomas Once the redirectUri is taken care of, do you expect this changeset to result in any user-visible changes?

[JVThomas]

@JVThomas Once the redirectUri is taken care of, do you expect this changeset to result in any user-visible changes?

The only visible change is that the user would be briefly redirected to the /redirect-from-oauth page before going to either a target page or the default value (for this PR its the root, on the job list PR it's /jobs)