Keycloak authorization: "Invalid identity" (userId=null) #20089
Labels
area/keycloak
area/kubernetes
kind/bug
Something isn't working
triage/needs-feedback
We are waiting for feedback.
Comments
|
/cc @geoand, @iocanel, @pedroigor, @sberyozkin |
|
Hi @vicentini in
|
|
@vicentini I run your steps with some changes:
The cUrl command is the same. In addition to using
I could not reproduce the issue by following your steps. Could you please check if any of the highlights above help? Or perhaps I'm still missing something ? |
|
Thanks @pedroigor for having a look at it. I see what key information is missing or not clear from my original post. The problem starts, when the service can't access the "public" domain or ip address of the Keycloak server. In a setup where Keycloak and other services are deployed in the same cluster, the services should access Keycloak with the internal ip address and not the public domain/ip. Therefore I used the additional docker network in my example, where the service directly connects to Keycloak on the internal network (with the corresponding auth-server-url setting) and not from the outside. |
The exception trace in the issue description is reported at the KC level and you also copied a log message reported by |
|
Sorry, poor choice of words. When using the internal Keycloak url in a cluster as auth-server-url it's still no connection problem, but I get the log above with the PERMISSION_TOKEN_ERROR. |
|
@vicentini np, thanks for the clarification. |
|
I used the security-keycloak-authorization-quickstart example without any changes with the provided realm configuration. In the example all authorization configuration is specified in the 'backend-service' client on the Keycloak server. So far I didn't have time to test your suggestion to configure everything in quarkus. |
|
After debugging the application (based on the exception below), I wasn't able to see any differences in the parameters passed to KeycloakAdapterPolicyEnforcer.requestAuthorizationToken method other than different frontend/backend urls. Therefore it's definitely the keycloak server not accepting the given access token, but for me it's not clear why. |
|
@vicentini |
|
@sberyozkin @vicentini Perhaps Sergey is right and the error is related to the issuer mismatch. We lack a better message but you can try to force the frontend URL and see if it helps. That setting should for Keycloak to issue tokens using the same issuer despite the URL you are using to reach out to the server. By default, the server calculates the issuer based on the host from the request. |
|
@sberyozkin @pedroigor Defining the frontend url is unfortunately not working in this case, because the As far as I understand and tested it, it's also no solution to disable OIDC discovery and manually define |
|
Hi @vicentini @pedroigor We've had several issues before with the internal vs external set ups but they were all affecting By the time it is called
My guess is that it might be Keycloak itself which is affected by the internal vs external case when it verifies the token Quarkus posts to it |
|
@pedroigor I had a look at Keycloak debug output and it's like you @sberyozkin stated in the last post. Keycloak doesn't accept the token due to a different issuer. To sum the situation up a little: For Keycloak we now have two options, though for both of them the authorization is failing.
As far as I can tell, there's currently no possibility to use Keycloak authorization when deployed on the same cluster using internal urls. I believe it's a conceptual issue which would have to be resolved first. |
|
|
@vicentini Thanks for this investigation - can you please open a Keycloak issue and CC there to Pedro @pedroigor ? And link to it here for us to be aware of it. thanks |
|
Thanks @sberyozkin I created a Keycloak issue but couldn't find @pedroigor to cc. |
|
@vicentini Thanks, that is fine, Pedro is CC-ed from this issue so he is aware :-) |
|
@pedroigor Hi Pedro - the same problem can be easily reproduced without Kubernetes, simply start Keycloak server as described in the guide (both HTTP 8180 and HTTPS 8543 ports are available) - then use a curl command to request a token for |
|
@pedroigor Hi Pedro - the same problem can be easily reproduced without the docker, simply start Keycloak server as described in the guide (both HTTP 8180 and HTTPS 8543 ports are available) - then use a curl command to request a token for |
|
I had the same problem and solved it by entering the Realm settings -> General -> Frontend URL Reason: I issued my tokens with Postman using localhost so the token issuer was localhost. But internally the backend referenced keycloak by container name keycloak, so I got following error After changing the frontend url, the token request's base url gets overriden and that fixed my problem. |
|
We are now running into this issue for all of our containerized workloads. Furthermore, production workloads have a non-customer-facing DNS name for Keycloak (e.g. Now this doesn't work when the JWT is issued from, for example, Section 4.1.1 of RFC 7519 indicates the |
|
@dcnis nailed it with his answer. here is how my compose file looks like: version: '3.8'
services:
homelab:
image: __REGISTRY__/__IMAGE_NAME__:__IMAGE_TAG__
restart: unless-stopped
environment:
QUARKUS_OIDC_AUTH_SERVER_URL: http://auth:8080/realms/__REALM__
QUARKUS_OIDC_CREDENTIALS_SECRET: __SECRET_FROM_REALM_CLIENT__
QUARKUS_DATASOURCE_JDBC_URL: jdbc:postgresql://db:5432/db?schema=public
QUARKUS_OIDC_TOKEN_ISSUER: http://localhost:9080/realms/__REALM__
ports:
- 8080:8080
depends_on:
- db
- auth
db:
image: postgres:16.1-alpine3.19
restart: unless-stopped
ports:
- 5432:5432
environment:
POSTGRES_USER: admin
POSTGRES_PASSWORD: admin
POSTGRES_DB: db
volumes:
- dbdata:/var/lib/postgresql/data
auth:
image: __REGISTRY__/__CUSTOM_KEYCLOAK_IMAGE__:__IMAGE_TAG__
restart: unless-stopped
command: start-dev
ports:
- 9080:8080
environment:
KC_PROXY: none
KC_HEALTH_ENABLED: false
KC_METRICS_ENABLED: false
KC_HOSTNAME: localhost
KC_HOSTNAME_ADMIN: localhost
KEYCLOAK_ADMIN: admin
KEYCLOAK_ADMIN_PASSWORD: admin
KEYCLOAK_FRONTEND_URL: http://localhost:9080/
adminer:
image: adminer:4.8.1
restart: always
ports:
- 8090:8080
volumes:
dbdata:with that, I can issue an access token for a user of the realm using the client and secret, then use the token to access protected resources using the policy enforcer. |
|
Is this still an issue? |
|
Closing for lack of feedback |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Trying the security-keycloak-authorization-quickstart, there is a problem when running in a containerized environment (Kubernetes or even single node docker installation). The retreived access token is not working and I see the following log outputs when running both Keycloak and quickstart application running in containers.
Keycloak log:
Authorization quickstart example log:
The
userId=nullis probably the culprit, but why is it null in the first place?Running only Keycloak in a container and the REST application on the host machine with the quarkus-app.jar file, the example is working as expected (even with the same access token retrieved from Keycloak).
Expected behavior
No response
Actual behavior
No response
How to Reproduce?
Build quickstart example container image with additional dependency quarkus-container-image-docker and property quarkus.container-image.build=true.
On a host machine with docker installation (+quarkus network)
docker container run -d --name keycloak -e KEYCLOAK_USER=admin -e KEYCLOAK_PASSWORD=admin -e DB_VENDOR=H2 --network quarkus -p 8080:8080 jboss/keycloak:15.0.2 -b=0.0.0.0Import keycloak realm from quickstart example
docker container run -d -e QUARKUS_OIDC_AUTH_SERVER_URL="http://keycloak:8080/auth/realms/quarkus" -e QUARKUS_OIDC_TOKEN_ISSUER="http://localhost:8080/auth/realms/quarkus" --network quarkus -p 8081:8080 quarkus/security-keycloak-authorization-quickstart:1.0.0-SNAPSHOTcurl -L -X GET 'http://localhost:8081/api/users/me' -H 'Authorization: Bearer <retrieved-access-token>'When running the quickstart example jar file directly on the host (QUARKUS_HOST_PORT=8081, accordingly) with the same Keycloak container instance, the authorization is working.
Output of
uname -aorverNo response
Output of
java -versionNo response
GraalVM version (if different from Java)
No response
Quarkus version or git rev
No response
Build tool (ie. output of
mvnw --versionorgradlew --version)No response
Additional information
We observed the problem with one of our own REST services when trying to enable authorization. After some investigation I was able to reproduce the same behavior with the keycloak authorization quickstart example version 2.2.1.Final. I tested with images of Keycloak 14.0.0 and 15.0.2 with the same result.
The text was updated successfully, but these errors were encountered: