Explore Openshift Implementation of next multi-zone for session sharing

[pbastia]

Description:

Following cas-obps/256

The excellent research below was done by @shon-button

Now that the POC work for this is working locally, we should see how this interacts in our openshift dev environment across different routes / services. Here are the steps I think we need to do this:

In the #1652 branch:

• Create a Dockerfile for the common dashboard

• Build the common dashboard & reporting app images (either manually or through CI)

• Create a helm deployment for the common dashboard including a new route/service pair

• Make sure to add the necessary env vars added in #1652 (ie: REGISTRATION_HOST, etc)

• Deploy the common dashboard & registration app to dev with the new images

• See if it works / troubleshoot issues

• Something to consider: Does this enable or work better using path based routing on 1 route rather than several (which is our current plan) https://kubernetes.io/docs/concepts/services-networking/ingress/

Definition of Ready (Note: If any of these points are not applicable, mark N/A)

• [ ] User story is included
• [ ] User role and type are identified
• [ ] Acceptance criteria are included
• [ ] Wireframes are included (if required)
• [ ] Design / Solution is accepted by Product Owner
• [ ] Dependencies are identified (technical, business, regulatory/policy)
• [ ] Story has been estimated (under 13 pts)

Definition of Done (Note: If any of these points are not applicable, mark N/A)

• [ ] Acceptance criteria are tested by the CI pipeline
• [ ] UI meets accessibility requirements
• [ ] Configuration changes are documented, documentation and designs are updated
• [ ] Passes code peer-review
• [ ] Passes QA of Acceptance Criteria with verification in Dev and Test
• [ ] Ticket is ready to be merged to main branch
• [ ] Can be demoed in Sprint Review
• [ ] Bugs or future work cards are identified and created
• [ ] Reviewed and approved by Product Owner

Notes:

This spike is to explore upgrading authentication to auth.js v5, and to explore sharing JWT session state across microfrontends using Next.js Multi-zones feature.

Background

auth.js v5
Auth.js provides JWT-based user session strategy using JSON Web Tokens (JWT). When a user signs in, a JWT is created in a HttpOnly cookie. Making the cookie HttpOnly prevents JavaScript from accessing it client-side (via document.cookie, for example), which makes it harder for attackers to steal the value. In addition, the JWT is encrypted with a secret key only known to the server. So, even if an attacker were to steal the JWT from the cookie, they could not decrypt it. Combined with a short expiration time, this makes JWTs a secure way to create sessions. When a user signs out, Auth.js deletes the JWT from the cookies, destroying the session. This JWT session strategy allows logging in once, for the time the JWT is valid, so users do not have to log in every single time they visit the site.

Next.js multi zones A zone refers to a single Next.js app running on a server. Multiple Next.js apps can be combined together using the multi-zones feature so to appear as a unified application. For example, let’s say we have a Next.js application that consists of three different micro-frontends: a home app, a registration app, and a reporting app. You could define each of the separate micro-frontend app as a separate “zone”, and then, through configurations of .env, next.config.js, package.json, the user can navigate the apps as if it was a single, monolithic application allowing sharing of the authentication session between apps deployed on separate subdomains.

auth.js v5

• [x] Authentication signIn/signOut functions as expected in our Siteminder/Keycloak environment (can signIn as different users in the same browser)

Multi-zones

• [x] home.domain app
• [x] home.domain\registration app
• [x] home.domain\reporting app
• [x] shared JWT user session across all zones

HOME APP

REGISTRATION APP

REPORTING APP

Blocking - #1621

[pbastia]

Tagging @shon-button for visibility, there will be one meeting where developers decide if this is the way to go

[dleard]

@hannavovk @patriciarussellCAS Suggest moving this into this sprint to continue the exploration on shared sessions. Shon has this working locally but the next step is to see if we can get it workin on openshift. I've adapted this empty card to handle this exploration cc @shon-button

[hannavovk]

DL: Shared auth now works locally based on @shon-button work on #258 . @dleard suggests it's time to test it in OpenShift to make sure it works. This is a key piece of the puzzle for a common dashboard. DL suggestion: @shon-button and @joshgamache could probably work on this together. Moved card to this sprint. (cc: @patriciarussellCAS @rdromey @patrickisaac )

[patriciarussellCAS]

Thanks @hannavovk - Can you confirm this has been pulled into Sprint 13? It doesn't appear to be listed in the sprint (though has been moved into the sprint backlog) - given the short week, are we making this a priority for Sprint 13 or pushing to Sprint 14?

[patrickisaac]

Will be an exploration ticket and 'backlog refinement' label will be removed after. Shon and Josh to review this ticket.

[hannavovk]

@patriciarussellCAS Sorry, we forgot to move it and assign the sprint in the Giraffe board. Done now. (cc @patrickisaac @rdromey ). It probably wont be completed in this sprint though so will carry over.

[patriciarussellCAS]

@shon-button and @joshgamache - does this ticket need to be estimated? Anything else related to backlog refinement, or can we remove the backlog refinement tag?

[joshgamache]

Finished up a POC deployment of this using the branch poc/258-bciers-dashboard, built on top of the local work Shon had done. A draft PR will be left up with the content of that branch and Shon's findings. Additional comments added from finding in a comment on the draft PR.

We'll be able to use the overall process (as well as some of the helm charts/configs almost verbatim) to implement the real version in future tickets.

[shon-button]

Capturing from developers channel:

[Tuesday 17:43] Gamache, Joshua ENV:EX Shon Running into something with AuthJS (I think) for the shared auth. When I run locally, everything works just fine as expected. When I run it deployed, the token is coming up as null. I'm able to log in, logged in user is showing in the header bar, but it gets stuck on the onboarding page. Attempting to connect to the /dashboard route just goes backl to /onboarding. Skimming the network, it looks like the cookie is getting marked as __Secure-, despite secure being set to false (dropped in a the local set, for comparison).

I think this is what is giving me trouble. If you have any insight, pass it my way! If you have time in the next day or two, maybe we could pair and see if we can hash this out?

[Yesterday 10:33] Hogan, Shon ENV:EX Gamache, Joshua ENV:EX I committed changes that might resolve the "deployed" token issue...using await auth() over await getToken() because we do not need the encrypted JWT for sharing sessions specifically (encrypted JWT needed for other use cases TBD)

See related ticket

[joshgamache]

After a discussion/dev walkthrough 2024-06-03, this POC is approved and will be left as a hanging branch to reference in future implementation. The 258 branch it was based off of will be used and put in for review.