Before reporting an issue

• I have read and understood the above terms for submitting issues, and I understand that my issue may be closed without action if I do not follow them.

Area

authentication

Describe the bug

When using 26.0.0, any type of docker/podman/skopeo login succeeds on a Docker Registry v2, but it is impossible to use any of the clients to push (or pull) an image to/from the registry due to denied: requested access to the resource is denied message.
Docker registry configuration was done through the "Download adapter config" functionality of docker-v2 client type.

podman push --log-level=debug <registry>/<some_image> tries to authorize, but fails eventually due to insufficient_scope errors for the token.

Downgrade to 25.0.6 solves the issue and images can be pushed/pulled properly.

A decoded JWT Token obtained from docker-v2 auth protocol on 26.0.0 returns an incorrect JWT payload, despite scope being sent in the URL parameter.

Since podman/docker/skopeo are not very useful in obtaining the raw JWT token, this can be verified by running some token obtaining command with curl or similar, e.g.

curl -u "some_user:some_pwd" -vvL '<keycloak-url>/realms/master/protocol/docker-v2/auth?account=<username>&scope=repository%3Abusybox%3Apull%2Cpush&scope=repository%3Abusybox%3Apull&service=docker-test-registry'

Decode and compare the JWT payload between 26.0.0 and 25.0.6 (e.g. using jwt.io or similar).

We found that a request made on 26.0.0 returned the following:

  access: []

The same request on 25.0.6 returns a different access dictionary inside the JWT payload:

  "access": [
    {
      "type": "repository",
      "name": "busybox",
      "actions": [
        "pull",
        "push"
      ]
    }
  ]

I am new to Keycloak codebase, however this looks like a relevant change from 26.0.0 with 25.0.6: #29967. This is the one that prompted us to downgrade.

Additionally, it looks like this regression case might not be covered by the existing DockerClientTest, given that it checks whether docker login works properly, but that doesn't cover any actual registry operation which would require access: [] to be populated.

Version

26.0.0

Regression

• The issue is a regression

Expected behavior

It is expected for the pull/push & other operations authorized via docker-v2 to succeed on versions >25.0.6.

Additionally, the existing tests could cover more than only "docker login", since testing docker login is not enough to verify the correctness of the token.

Actual behavior

Push/pull operations for Docker Registry using docker-v2 auth provider fail on versions >25.0.6, most likely due to access: [] part of JWT Payload not being populated correctly.

How to Reproduce?

1. Using Keycloak 26.0.0 and assuming a configured docker-v2 client, take a repository running docker-v2 auth in keycloak, run docker login, observe Login Succeeded
2. Run docker push with any image on the Docker Registry managed by docker-v2 keycloak
3. Observe that the operation fails with denied: requested access to the resource is denied

Anything else?

No response