Keycloak (not) responding to multiple names behind reverse proxy

[nicokpn]

We have a setup where:
Setup working up to 16.x.x

keycloak:  https://kc-int.local/auth   ==>  https://localhost:8443/auth       (nginx reverse proxy on KC server)

App1:      https://app1.com/auth       ==>  https://kc-int.local/auth         (realm = realm-app1)
App1:      https://app1.com/whatever   ==>  https://appserver1.local/whatever (realm = realm-app1)
App1-int:  https://app1.local/auth     ==>  https://kc-int.local/auth         (realm = realm-app1)
App1-int:  https://app1.local/whatever ==>  https://appserver1.local/whatever (realm = realm-app1)
App2:      https://app2.com/auth       ==>  https://kc-int.local/auth         (realm = realm-app2)
App2:      https://app2.com/whatever   ==>  https://appserver2.local/whatever (realm = realm-app2)

Up to Keycloak 16.1.0 (11.0.2, 15.x.x etc.) all redirects/followup pages happened to the app1.com / app1.local / app2.com respective hostnames
Since Keycloak 17.0.0 the login page is shown, ANY follow up page is done using: kc-int.local/auth/… with the error that Cookies are invalid.
Understandable as the cookies are registerrd to app1.com, app1.local, app2.com respectively.

Each of the app’s does have it’s own realm inside Keycloak
Effectively keycloak could be used transparently for several environments where needed. Adding a realm where needed.

Keycloak has nginx as reverse proxy on the own host. (to filter some unwanted URL’s if they happen to be sent somehow).
All other services are behind a reverse proxy that dispatches to either the app server / keycloak depending on URL provided.

Unlike the unreachable admin pages issues described elsewhere, this is the opposite, the admin pages ARE reachable the various frontends are not, they al lredirect to the internal hostname for the keycloak server.

Note: I am aware of

Login action mail uses backend issuer URL

I’m trying to upgrade from Keycloak 15 (Wildfly) to Keycloak 18 (Quarkus). The upgade itself didn’t pose any issues but during testing I ran into the issue where when I’m sending a login action mail from keycloak it uses the internal admin url instead of the frontend URL. My setup is reverse proxied through Nginx with x-forwarded-for and x-forwarded proto set. For keycloak itself I’m using a docker-compose setup with an external postgresql database. The admin portal for my keycloak is accessi…

which adjusts the frontend-url in settings…, this would allow for a realm to be used once with a specific URL…, it does not work for a realm used with multiple different hostnames in the URL’s

[nicokpn]

in keycloak.conf:
Add:
hostname-strict=false
Remove
hostname=

Then the configuration works as intended…
This is not exactly clear from documentation.

[weltonrodrigo]

Just to make even more clear:

hostname-scrict=true means that keycloak only accepts being called by the hostname set in hostname=<myhostname.com>. The same for https, which can be disabled in production (not advisable) with the (undocumented) hostname-strict-https=false directive.

So, to trust the reverse proxy and answer to any hostname keycloak is called by (the old behavior):

# no hostname directive
hostname-scrict=false
proxy=edge

Via environment variables (container etc):

KC_HOSTNAME_STRICT
KC_PROXY

All configurations are documented here All configuration - Keycloak

[nicokpn]

IMHO:
The default behaviour of previous keycloak should be continued, or in the upgrade manual the exact settings needed to emulate it should be provided.

In this case it lead to a hunt for settings on various boards yielding a lot of erroneous, obsolete proposals.
Where an hunch that something not clearly documented & mentioned anywhere else proved to work.
Note: we use https, and hostname-strict-https=false didn’t produce.
hostname-strict=false also applies to https case.