Keycloak AdminURL infinite redirect loop (nginx proxy)

Question

I configured this setup before, however upon trying to replicate it on a new instance, I am unable to make it work. I am working with the standalone-ha mode, however trying it with standalone does not make a difference.

The instance is configured with frontendUrl https://example.com. Leaving only this setting in the standalone-ha.xml, both the frontend, as well as the admin console are accessible with no issues. Upon adding the adminUrl https://intra.example.com to the spi hostname section, in order for it too look like

        <spi name="hostname">
            <default-provider>default</default-provider>
            <provider name="default" enabled="true">
                <properties>
                        <property name="frontendUrl" value="https://example.com/auth/"/>
                        <property name="adminUrl" value="https://intra.example.com/auth"/>
                    <property name="forceBackendUrlToFrontendUrl" value="false"/>
                </properties>
            </provider>
        </spi>

accessing the admin console no longer works.

Upon using either the link on the welcome page, or browsing to it directly, the sign-in page (on https://example.com/auth) appears. Upon logging in with valid credentials, it redirects to https://intra.example.com/auth/admin/master/console/, and immediately after to https://intra.example.com/auth/admin/master/console/#state=4626eb82-6993-4fff-8c11-399a05cb8c66&session_state=3198da2f-f6eb-45be-aa87-ae7d52e22068&code=fd73f80a-fe43-4996-b245-efa42efb7b44.3198da2f-f6eb-45be-aa87-ae7d52e22068.e794bdbc-6497-4fc3-8502-e0afedb67492. It then redirects back to https://intra.example.com/auth/admin/master/console/, and then back to the long link, and then back again, and so forth. This cycle goes on forever.

The instance is behind an nginx proxy, which is configured with the necessary headers:

server {
    listen                  192.168.0.115:443 ssl http2;

    server_name             intra.example.com;
    ssl_certificate            <valid cert>;
    ssl_certificate_key     <key>;

    location                /auth {
            proxy_pass          https://192.168.0.115:8843/auth;
            proxy_ssl_verify    off;
            proxy_set_header    Host                $host;
            proxy_set_header    X-Real-IP           $remote_addr;
            proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;
            proxy_set_header    X-Forwarded-Host    $host;
            proxy_set_header    X-Forwarded-Server  $host;
            proxy_set_header    X-Forwarded-Port    $server_port;
            proxy_set_header    X-Forwarded-Proto   https;
    }
}
server {
    listen                  <public IPv4>:443 ssl http2;
    listen                  [<public IPv6]:443 ssl http2;

    server_name             example.com;

    ssl_certificate            <valid cert>;
    ssl_certificate_key     <key>;

    location                /auth {
            proxy_pass          https://192.168.0.115:8843/auth;
            proxy_ssl_verify    off;
            proxy_set_header    Host                $host;
            proxy_set_header    X-Real-IP           $remote_addr;
            proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;
            proxy_set_header    X-Forwarded-Host    $host;
            proxy_set_header    X-Forwarded-Server  $host;
            proxy_set_header    X-Forwarded-Port    $server_port;
            proxy_set_header    X-Forwarded-Proto   https;
    }

}

Upon researching I attempted various combinations:

• Proxying the root (/) instead of /auth

• Proxying to http instead of https

• Adding proxy-address-forwarding to the http/https listener:

   <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true" proxy-address-forwarding="true"/>
  

• Adding a proxy listener:

   <http-listener name="default" socket-binding="http" redirect-socket="proxy-https" enable-http2="true" proxy-address-forwarding="true"/>
  

  in combination with

   <socket-binding name="proxy-https" port="443"/>
  

  and

   <http-listener name="default" socket-binding="http" redirect-socket="proxy-https" enable-http2="true" proxy-address-forwarding="true"/>
  

• Temporarily setting the valid redirect URIs to * in the database

This seems to sum up the ideas from some of the existing threads on this issue. Other threads I found were using Docker, whereas I am working with a native instance.

I would greatly appreciate if anyone has an idea on what else could be tried. I need the admin console separated to a dedicated, internal, URL, and know to have had this scenario working before. I even copied the same proxy configuration from nginx, hence do not think the issue lays there, but am of course leaving that option open.

No log entries seem to be generated during the redirects. I attempted starting with --debug as well.

Thanks a lot for reading.

Answer 1

I think I had similar issue and long story short (after days of googling) the following helped me

      location / {
                ....
                proxy_pass_header       Set-Cookie;
                ....
      }

The credit goes to Thomas Duxbury. Here is his post and his subsequent explanation how he resolved it. It helped me ;-) https://keycloak.discourse.group/t/redirect-loop-logging-into-master-realm-behind-apache-reverse-proxy/8395