9228 - add OIDC development setup for OIDC login feature testing

[GPortas]

What this PR does / why we need it:

As stated in #9228, developers currently don't have a way to test the login with OIDC feature of Dataverse.

This PR includes a dockerized Keycloak setup with OIDC support for development purposes, as well as its associated documentation.

TODOs.

• Add Keycloak-Docker config
• Add Keycloak-Docker documentation at (future version of) https://guides.dataverse.org/en/5.12.1/developers/remote-users.html
• Test current OIDC login flow with this setup

Which issue(s) this PR closes:

Closes #9228

Special notes for your reviewer:
Not yet.

Suggestions on how to test this:

Follow the next steps:

1. (Positioned in /conf/keycloak/) Run Keycloak docker container: You can use docker-compose file or run-keycloak.sh script.
2. Verify that Keycloak is running on http://localhost:8090/.
3. Verify that Dataverse is locally running
4. (Positioned in /conf/keycloak/) Execute the following API call which enables the Keycloak OIDC client as an authentication provider for Dataverse: curl -X POST -H 'Content-type: application/json' --upload-file oidc-keycloak-auth-provider.json http://localhost:8080/api/admin/authenticationProviders
5. Test that the new OIDC auth flow works. A new option "OIDC-Keycloak" should appear on the login screen. The credentials for the Keycloak test user are: kcuser / kcpassword (usr/pwd).

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

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

Additional documentation:
Not yet.

[pdurbin]

I gave this a size of 3. As long as a developer has Docker installed, it should be pretty easy to spin up Keycloak, add the config, and to a quick test. The docs @GPortas wrote are excellent.

[mreekie]

Prioritization note:
@siacus This is work that is coming out of the re-architecture work.
We haven't discussed yet how we're going to priortize these so for now I've added it directly to the ordered backlog.

[mreekie]

Prioritization note: @siacus This is work that is coming out of the re-architecture work. We haven't discussed yet how we're going to priortize these so for now I've added it directly to the ordered backlog.

Corrected. This is part of: "NIH OTA: 1.7.1" and so is part of the NIH Backlog items.
Put it at the top.

[pdurbin]

I tested this and it works amazingly well. Thank you, @GPortas!! I've wanted something like this for over three years, when OIDC support was added in PR #6433 by @poikilotherm and I never had an easy way to test it myself.

It's inconvenient to add screenshots and details in the review box but I'll add another comment in a minute. I did make a couple tiny doc tweaks.

Approved. Thanks again! 🎉 🚀

[pdurbin]

This pull request is a dream come true. Just works!

I did make a couple tiny tweaks to the docs (formatting stuff and a security warning not to run this config it prod since the client secret is in GitHub).

The Bash option was listed first so I tried it first. Worked great. Here's the output:

$ cd conf/keycloak
$ ./run-keycloak.sh
Unable to find image 'jboss/keycloak:16.1.1' locally
16.1.1: Pulling from jboss/keycloak
ac10f00499d5: Pull complete
96d53117c12e: Pull complete
1d929376eb7f: Pull complete
93e1e1b6d192: Pull complete
f353ba0db29e: Pull complete
Digest: sha256:abdb1aea6c671f61a594af599f63fbe78c9631767886d9030bc774d908422d0a
Status: Downloaded newer image for jboss/keycloak:16.1.1
cc78453726bb8292e241472b3d30351e651d8a35a431ad5ea4c7f7063787842b
INFO - Keycloak container created and running

I got a working Keycloak instance at http://localhost:8090 which looked like this:

Then I loaded up the auth provider:

$ curl -X POST -H 'Content-type: application/json' --upload-file oidc-keycloak-auth-provider.json http://localhost:8080/api/admin/authenticationProviders
{"status":"OK","data":{"id":"oidc-keycloak","factoryAlias":"oidc","title":"OIDC-Keycloak","subtitle":"OIDC-Keycloak","factoryData":"type: oidc | issuer: http://localhost:8090/auth/realms/oidc-realm | clientId: oidc-client | clientSecret: ss6gE8mODCDfqesQaSG3gwUwZqZt547E","enabled":true}}

Here are screenshots of the login process:

One thing to note above is that no username was prepopulated (given name, family name, and email were). @poikilotherm already wrote this bug up here:

• Bug in OAuth2 First Login page not using prefilled username from OAuth2UserRecord #6690

This PR means that issue will be MUCH easier for a developer to work on! 🎉

During the auth meeting today I said I was curious what gets stored as a persistentUserId for an Keycloak user. It turns out that it's a UUID, like this: "persistentUserId": "47411075-985b-4587-bbde-167e3fd8c949"

Here's the full output of a dump of this keycloak user:

$ curl -s http://localhost:8080/api/admin/authenticatedUsers/kcuser | jq .
{
  "status": "OK",
  "data": {
    "id": 2,
    "identifier": "@kcuser",
    "displayName": "Test Test",
    "firstName": "Test",
    "lastName": "Test",
    "email": "test@test.com",
    "superuser": false,
    "deactivated": false,
    "persistentUserId": "47411075-985b-4587-bbde-167e3fd8c949",
    "createdTime": "2023-01-06T19:57:37Z",
    "lastLoginTime": "2023-01-06T19:57:37Z",
    "authenticationProviderId": "oidc-keycloak"
  }
}

I also tested the rm-keycloak.sh script and the docker compose option. It all worked great. Thanks again, @GPortas!

[GPortas]

Very nice step-by-step guide with screenshots and good information about persistentUserId.

Thank you @pdurbin!

[mreekie]

Updated information.

• This was an add-on from Phil for the "free for all" sprint

[pdurbin]

I said I would pick this up during the auth meeting last week as we discussed the Dataverse - SPA Authentication V1 doc.

It seemed absolutely ready to merge. High value (extremely useful for ongoing auth work). Zero risk. So I went ahead and moved it to QA. Next time, I'm happy to simply merge it if that's better. I was certainly tempted! 😄