Enhance Builtin users SPI security

[GPortas]

What this PR does / why we need it:

Security improvements for api-bearer-auth-use-builtin-user-on-id-match

We’ve strengthened the security of the api-bearer-auth-use-builtin-user-on-id-match feature flag. It will now only work when the provided bearer token includes an idp claim that matches the Keycloak Service Provider identifier.

By enforcing this check, the risk of impersonation from other identity providers is significantly reduced, since they would need to be explicitly configured with this specific, non-standard identifier.

Which issue(s) this PR closes:

• Closes Secure API_BEARER_AUTH_USE_BUILTIN_USER_ON_ID_MATCH with hardcoded 'builtin' OIDC attribute #11689

Notes for the reviewer:

I’ve updated the warning in the documentation related to impersonation risk. With this additional security measure in place, user impersonation is unlikely to occur unless an IdP is intentionally misconfigured.

Suggestions on how to test this:

1. Run the containerized dev environment under conf/keycloak

2. Obtain a bearer token by logging into Keycloak with built-in account credentials

curl -X POST http://keycloak.mydomain.com:8090/realms/test/protocol/openid-connect/token -H "Content-Type: application/x-www-form-urlencoded" -d "client_id=test" -d "client_secret=94XHrfNRwXsjqTqApRrwWmhDLDHpIYV8" -d "grant_type=password" -d "username=dataverseAdmin" -d "password=admin1" -d "scope=openid"

2. Go to https://www.jwt.io/ and paste the access_token. You should see a new "idp" claim including the value "dv-builtin-users-authenticator" from the Keycloak SPI.

3. Test an API endpoint requiring auth using the generated access token, and make sure it correctly authenticates the user.

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?:

Yes, attached

Additional documentation:

N/A

[coveralls]

coverage: 23.375%. remained the same
when pulling cc6bd1c on 11689-builtin-users-api-auth-enhance
into ab2c661 on develop.

[github-actions]

📦 Pushed preview images as

ghcr.io/gdcc/dataverse:11689-builtin-users-api-auth-enhance

ghcr.io/gdcc/configbaker:11689-builtin-users-api-auth-enhance

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

[qqmyers]

Can this be part of the keycloak config, i.e. a static entry added there? Then we don't have to rely on the external provider. This is maybe less relevant for the internal users where you control the code, but it would be more under the site admin's control if there was a static value added to the token by keycloak (that was set for each login type).

[GPortas]

Yes. We could consider making the expected idp identifier configurable via a parameter in the SPI. Dataverse could then retrieve this value from a JVM option when verifying the token.

The main advantage I see in this approach is that it prevents the expected idp identifier claim value from being publicly exposed. This could indeed result in a more secure solution. That said, anyone who can successfully authenticate and obtain a token would still be able to decode it and see the idp claim value. Perhaps I’m missing other advantages of your approach.

[qqmyers]

I wasn't thinking about it being configurable - just using the Keycloak config to add a static value, e.g.

Doing this, I don't think there would be any way for someone to configure a shib idp (or build a built-in account source like yours) that could allow impersonation.

[qqmyers]

Looks OK to me. I left a question about an ~alternate design, but I think what's here is fine to use now/should help security. I did not try to set this up at all so having QA try the whole setup and checking the tests is important.

[ofahimIQSS]

Looks good to me - merging!