Cyclic redirect on UI authentication via Keycloak 25

[sergey-katunin-atom-team]

Description

Registry Version: 2.5.11.Final, 2.6.2.Final Persistence type: kafkasql Keycloak version: 25.0.0, 25.0.4

Environment

Kubernetes v1.27 Pod environment variables:

AUTH_ENABLED : true CLIENT_CREDENTIALS_BASIC_AUTH_ENABLED : true CORS_ALLOWED_ORIGINS : http://kafka-04.apicurio-registry,https://kafka-04.apicurio-registry,https://sso.e-kama.com KAFKA_BOOTSTRAP_SERVERS : rc1a-o0i23tfpor5mbrse.mdb.yandexcloud.net:9091 KEYCLOAK_API_CLIENT_ID : kafka-04-ar-api-dev-default KEYCLOAK_REALM : e-kama KEYCLOAK_UI_CLIENT_ID : kafka-04-ar-ui-dev-default KEYCLOAK_URL : https://sso.e-kama.com QUARKUS_PROFILE : prod REGISTRY_AUTH_ANONYMOUS_READ_ACCESS_ENABLED : true REGISTRY_KAFKASQL_SCRAM_PASSWORD : secret(kafka-04)[password] REGISTRY_KAFKASQL_SCRAM_USER : apicurio-registry REGISTRY_KAFKA_COMMON_SASL_JAAS_CONFIG : org.apache.kafka.common.security.scram.ScramLoginModule required username='$(REGISTRY_KAFKASQL_SCRAM_USER)' password='$(REGISTRY_KAFKASQL_SCRAM_PASSWORD)'; REGISTRY_KAFKA_COMMON_SASL_MECHANISM : SCRAM-SHA-512 REGISTRY_KAFKA_COMMON_SECURITY_PROTOCOL : SASL_SSL REGISTRY_KAFKA_COMMON_SSL_TRUSTSTORE_LOCATION : /etc/registry-kafkasql-scram-truststore/ca.p12 REGISTRY_KAFKA_COMMON_SSL_TRUSTSTORE_PASSWORD : secret(yandex-ca-truststore)[ca.password] REGISTRY_KAFKA_COMMON_SSL_TRUSTSTORE_TYPE : PKCS12 REGISTRY_PROPERTIESPREFIX : REGISTRY REGISTRY_UI_FEATURES_READONLY : true

Steps to Reproduce

1. Go to external URL (in our case): https://kafka-04-registry.dev-default.int.e-kama.com/
2. Login via Keycloak
3. Cyclic redirect: keycloak -> apicurio -> keycloak -> apicurio -> ... (see .har file)

Expected vs Actual Behaviour

Expected successful login to UI (worked on Keycloak 22) with same config

KC client for UI: kafka-04-ar-ui-dev-default.json KC client for API: kafka-04-ar-api-dev-default.json

Logs

HAR file: kafka-04-registry.dev-default.int.e-kama.com_Archive [24-08-27 14-05-32].zip

PS

Authentication to API works fine

[apicurio-bot[bot]]

Thank you for reporting an issue!

Pinging @jsenko, @EricWittmann to respond or triage.

[marcantoine-bibeau]

I would suggest to update UI and use "react-oidc-context" ?

[tartina]

The same thing is happening to me. I tried both direct access and behind a reverse proxy, but there's a loop between keycloak and apicurio which only ends when the URL becomes too long for the proxy to manage.

[justinaslelys]

I have exactly the same issue with Apicurio 2.6.2.Final

First of all I though Keycloak is to blame. I did refactor configuration to work with their hostname:v2 feature according to migration guide but didn't help. I also tried fresh Keycloak 25 install, but also have the same issue.

Observed this behaviour during the migration from 24 series to 25.0.4

[davidvoit]

We have the same problem here, looks like a exception in the javascript code?

[davidvoit]

Setting the js backend to oidc (REGISTRY_UI_AUTH_TYPE=oidc) avoids the endless loop, but the a idToken is used as access Token and then RBAC is failing.

Seems like a javascript incompability in the keycloakjs code, but I'm not a frontend guy, can't debug more here

[davidvoit]

If the UI_AUTHTYPE=oidc is used I think the code should be changed like this. Using id_tokens as Bearer token is wrong

public getOidcToken = () => {
    return this.oidcUser.id_token;
};

I think this should be:

public getOidcToken = () => {
    return this.oidcUser.access_token;
};

For keycloakjs (the default) I think a update should be made as the library is quite old with version 21.1.1, to avoid this exception in the js code and the endless loop

[davidvoit]

The problem with keycloakjs seems to be this one: https://www.keycloak.org/docs/latest/upgrading/index.html#nonce-claim-is-only-added-to-the-id-token

[davidvoit]

Do you still accept patches for the 2.6.x branch? I have built a version with the newest keycloakjs version and then authentication works fine. Should I create a pull request?