Keycloak SPI for Builtin Users Authentication

[GPortas]

What this PR does / why we need it:

The only modifications I made to Dataverse include:

• Adding an endpoint to validate credentials (email/username and password).
• Making a slight adjustment to the logic of lookupUserByOIDCBearerToken to first check whether the username from the bearer token belongs to a built-in user in AuthenticatedUser before querying AuthenticatedUserLookup.

This PoC can serve as a foundation for a more refined implementation. However, there are still aspects to explore, such as handling potential account duplication (when a user has both built-in and external IDP accounts) and further improving the SPI implementation.

The SPI has been implemented following the docs https://www.keycloak.org/docs/latest/server_development/index.html#_user-storage-spi

Before running the environment, you need to build the SPI .jar file. Use mvn -Pextension clean install -DskipTests=true located inside the conf/keycloak/builtin-users-spi folder.

If you want to run this branch on your localhost, once the containers are up and running, you need to register the SPI in Keycloak. In a future iteration, it would be interesting to move this configuration to the realm config JSON file so that it auto-configures on startup.

You can do this as shown below:

kccconf.mov

You can run the SPI in the dataverse-frontend (branch: https://github.com/IQSS/dataverse-frontend/tree/poc/oidc-builtin-users) by running the environment pointing to this branch with ./run-env.sh 11157-builtin-users-oidc-auth

Remember to add the SPI provider through the Keycloak admin console ( http://localhost:8000/admin/ kcadmin/kcpassword)

builtinusersspa.mov

Which issue(s) this PR closes:

• Closes #

Special notes for your reviewer:

Suggestions on how to test this:

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

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

Additional documentation:

https://www.keycloak.org/docs/latest/server_development/index.html#_user-storage-spi

[coveralls]

coverage: 22.681% (-0.05%) from 22.726%
when pulling e60f4a3 on 11157-builtin-users-oidc-auth
into 4e1238e on develop.

[GPortas]

@qqmyers @pdurbin

As discussed during standup, moving to ready for review to get an early review and feedback, not with the goal of merging but to be able to continue the implementation if the approach makes sense. Thanks.

[pdurbin]

I haven't even looked a the code yet but I'll at least share some screenshots showing it works great! 🎉 🚀

However, there are still aspects to explore, such as handling potential account duplication (when a user has both built-in and external IDP accounts)

Yes, I do wonder about duplicate accounts. Hmm. 🤔

[qqmyers]

FWIW: In general Keycloak can link accounts. At QDR, if you login via ORCID or Google and we can match the account based on email, Keycloak pops up a 'do you want to link your account' dialog rather than creating a new account that conflicts with an existing one. I'm guessing it's just a matter of Keycloak config to make that happen here too.

[pdurbin]

Yeah, I'm a bit worried that emails can be spoofed though. 😟

[qqmyers]

What you match one, whether emails are verified, etc. are all configurable. I'm not saying it's solved - just that it's probably a matter of configuration rather than programming.

[github-actions]

📦 Pushed preview images as

ghcr.io/gdcc/dataverse:11157-builtin-users-oidc-auth

ghcr.io/gdcc/configbaker:11157-builtin-users-oidc-auth

🚢 See on GHCR. Use by referencing with full name as printed above, mind the registry name.