SPA - OIDC integration following the design implemented on the PoC

[g-saracca]

What this PR does / why we need it:

Change SPA authentication method to use Keycloak as OIDC provider using PKCE based on an initial PoC.

Which issue(s) this PR closes:

• Closes Establish OIDC integration following the design implemented on the PoC #528

Special notes for your reviewer:

This PR does not point to the develop branch but to a separate branch ( authentication-oidc ), the idea is in another PR to configure the deployment to another environment that is not Beta maybe to be able to test this not only locally before merging to develop.

All unit tests and e2e tests are working now with this new authentication method.
Application terms of use are empty for now as we don't have an API endpoint for it yet.

Suggestions on how to test this:

Step 1: Run the Development Environment

1. Execute npm i.
2. Navigate with cd packages/design-system && npm i && npm run build.
3. Return with cd ../../.
4. Ensure you have a .env file similar to .env.example, with the variable VITE_DATAVERSE_BACKEND_URL=http://localhost:8000.
5. Make sure your dev-env/.env file is filled with the appropriate data. For the REGISTRY variable, please set ghcr.io, as we will use a PR-generated dataverse image.
6. Navigate with cd dev-env.
7. Start the environment using ./run-env.sh 10959-bearer-token-auth-ext .
8. To verify the environment, visit http://localhost:8000 and check your local Dataverse installation.

Step 2: Test the feature in the SPA

1. Click the Log In button in the header.
2. You will be redirected to the Keycloak login page
3. Enter the credentials, there are 4 pre-set users in keycloak, you can log in with any of those users:

• [email protected] - pass: user
• [email protected] - pass: admin
• [email protected] - pass: affiliate
• [email protected] - pass: curator

4. After the first login, you will be redirected to finish the registration process, where you will have to accept the terms (although there are none for now) and you will also be able to optionally add the affiliation and position.
5. After submitting the form, you will be redirected to the “root” collection page with a welcome success alert and some confetti. 🎉 .
6. Click on the user drop-down menu in the header and go to Account Information, check that the data displayed there matches the data you have entered during the registration process.
7. Try creating a collection and a dataset as a smoke test.
8. Now log out and log in again, the registration process should not be required now 👍🏼

Another path:

1. Follow the first 4 steps as before (but with a different user that didn't complete the registration process yet), but now click the Cancel button in the Sign Up page, you should be able to navigate through the SPA as an unauthenticated user.

Does this PR introduce a user interface change? If mockups are available, please link/include them here:

signup-success.mov

Is there a release notes update needed for this change?:

No

Additional documentation:

No

[g-saracca]

@ekraffmiller Back to Ready For Review .. There was a single test failing when checking a checkbox (Terms Of Use), this was only happening in github actions, this was because the interactivity was happening too fast, I added a 300ms cy.wait and it's working as expected again.

[ekraffmiller]

This looks great, it's so nice to have OIDC in the SPA! 🎉

Regarding the testing, would it simplify things to add a script to docker-compose that completes the signup process for the OpenID users, and updates their permissions? That way it wouldn't have to be done for individual tests.

I did find one issue when I tried to give the Dataverse User account permissions through JSF. The Dataverse User isn't shown on the DataverseAdmin's dashboard, even though a user that I create within Dataverse is there. I can create a separate issue for that.

Also, what is the plan for Dataverse built-in users when we deploy to production? Will Dataverse be configured to do OpenID authentication for those users?

[ekraffmiller]

Is this going call to the API going to be replaced with a call to js-dataverse? If so, can we add a todo?

[g-saracca]

I think this was a decision to avoid creating a use case just for this (I wasn't around at the time) and the idea is to keep it that way, I just switch from using a simple fetch to the axios instance I created which automatically sends the authentication token.

[ekraffmiller]

I think I'm missing something - why does this ApiConfig.init() need to be run at the beginning every integration test, but it doesn't need to be run in the e2e tests?

[g-saracca]

You are right, there was no need, I don't know what I was thinking, what I did now is to initiate all the tests with the bearer token method from the Setup tests and removed all the unnecessary initializations in the integration tests and that's it, everything works in my local, let's hope they pass the tests in github actions. 🤞🏼

[g-saracca]

@ekraffmiller thanks for the review!

Regarding the testing, would it simplify things to add a script to docker-compose that completes the signup process for the OpenID users, and updates their permissions? That way it wouldn't have to be done for individual tests.

Also, what is the plan for Dataverse built-in users when we deploy to production? Will Dataverse be configured to do OpenID authentication for those users?

For these two blocks I think we can keep iterating and thinking about it on this same branch that this PR points to (remember it doesn't point to develop).

I did find one issue when I tried to give the Dataverse User account permissions through JSF. The Dataverse User isn't shown on the DataverseAdmin's dashboard, even though a user that I create within Dataverse is there. I can create a separate issue for that.

On this last comment, perhaps we can check with Guillermo on Monday to find out what is going on.