Here we are: I want to contribute the first real integration test. It is using Testcontainers (of course) and ensures that configurability of an OIDC provider via MPCONFIG as well as using that provider with a Keycloak instance in a container for a Bearer Token Access to the API @Johannes D
Anyone feeling adventurous enough to try mvn clean verify on the PR branch? https://github.com/IQSS/dataverse/pull/9273 Only Docker, Java and Maven required!
Here's the test code BTW https://github.com/IQSS/dataverse/pull/9273/files#diff-104cf13998a3494cd46bf6cd92eba934c96744f84d4330ae378fcbf222bf58ea
BTW @Guillermo Portas I have had a strange experience: when importing the realm you created to Keycloak 20 or 21, I could no longer access Keycloak userinfo endpoint with the retrieved access token. (Works perfectly fine with Keycloak 19) I'm a bit puzzled about that and wondering if we need to re-export or re-create our test realm from a more modern version. It says it was created with Keycloak 16, so maybe something is not right here?
@Guillermo Portas as this PR does (try to) add PKCE support for the OIDC provider, maybe we need to alter the realm anyway? I would like to add an integration test for that as well!
Aaaand I have a working integration test with PKCE for the normal Auth Code Flow. Had to re-create the realm though. The exported realm from Keycloak 16 seems not be fully compatible with Keycloak 19. We'll see if that fixes the upgrade issue, too
@Philip Durbin I would like to create some more users in the realm. I'd go for some users following our role model if that is OK. (admin, curator, user)
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
INFO: STDOUT: 2023-05-22 10:39:16,653 INFO [org.keycloak.services] (main) KC-SERVICES0009: Added user 'kcuser' to realm 'master'
Seems promising!
@Oliver Bertuch I would suggest making some noise in #dv-rearchitecture-auth as well.
@Oliver Bertuch sure, please go ahead and create users. You're using the default master realm instead of the realm we're adding with a JSON file?
No, you shall (and cannot) use the master realm for that
I created a new realm "test"
And I'm loading it as JSON
Gotcha. I wonder why we have that out above then. :thinking: Added user 'kcuser' to realm 'master'
That is completely normal and fine
Oh wait no it might not be
That is the "normal" user...
Anyway - I am setting up a nice and clean realm
admin, user, curator and affiliate as users
even created groups for them, although the OIDC provider doesn't support groups (yet!)
That must change...
We might need to edit the realm again later when we start testing things like attribute mapping for affiliatons etc
Awesome. Go, go, go! ![]()
There you go :-) Replaced the realm, added the third test and pushed the changes
Even updated the docs :-D
No longer a draft! Great!
Now let's see if you're trigger happy again :stuck_out_tongue_wink:
Yes @Oliver Bertuch, It may be a version incompatibility by having exported the original realm json file with an older version of Keycloak. I see in your PR that you have included a new realm, I guess exporting a new one from the new version has fixed the problem.
If I remember correctly, the PKCE configuration is exported to the realm file with the rest of the config values of the realm, so I guess that you have included the new PKCE config in the realm file as well.
Guillermo Portas said:
If I remember correctly, the PKCE configuration is exported to the realm file with the rest of the config values of the realm, so I guess that you have included the new PKCE config in the realm file as well.
No, I didn't add any PKCE in the realm. I looked for it but could not find any option to enforce it. Maybe because I only added a confidential client so far and no public client?
PKCE as an addendum works though - the integration test sends the challenge so that should be fine.
If you happen to know where to enforce PKCE plz let me know! Happy to include it
Ha I might just have found it... looks like you need to activate an enforcing policy.
Will look I to that when back at desk
What about real integration tests for S3 direct upload? Discuss here or in a new topic?
Sounds like you got a taste for it now!
What can I say... IIRC there is a LocalStack Testcontainers module, so it should be easy to use.
Yeah, that's the one @Don Sizemore keeps reminding me of. Or maybe we could use Minio.
"real" integration testing? for when that fake integration testing just won't do?
More like "cover more than just the API" :wink:
@Oliver Bertuch currently the title of your PR is this: 9268 mpconfig OIDC provider #9273
It does more than that, though, right?
@Johannes D have you had a chance to take a look?
Yes, it contains more.
What should I write?
"OIDC and OAuth refactor, MPCONFIG, more tests"?
Hope ya like "9268 - OIDC auth: MPCONFIG provisioning, PKCE support and integration tests"
Much better! Thanks!
(We could probably drop 9268 since we have it under "closes".)
But but but when I joined you lot in 2018 you wanted me to add the issue number! Is this yesterdays news?
Oh, I love, love, love, the issue number in the name of the branch. :heart: But in the title it's a bit noisy if you ask me. Sorry for the miscommunication!
D'Oh!
@Oliver Bertuch nice demo at tech hours! Thanks! ![]()
Glad you liked it
May it be an icebreaker for more!
I'm hacking in this very moment on combined coverage reports...
Pre:
image.png
Post:
image.png
Nice! As usual, go, go, go!
Waiting on CI....
image.png
Smooooooooth operator
image.png
Nice! If I'm reading Coveralls right, in develop OIDCAuthProvider.java has 1.3% coverage but in the PR you're working on (#9273), it now has 69.5% coverage.
Last updated: Nov 01 2025 at 14:11 UTC