Home / server / Questions / 1000567
Accepted
user540468
Asked: 2020-01-28 06:30:49 +0800 CST

Keycloak blank page behind nginx reverse proxy

  • 772

After unpacking and starting keycloak to listen on 127.0.0.1, I configured nginx to work as a reverse proxy accessible from a publicly available domain via https.

This is the nginx configuration:

http
{
    server_tokens off;

    upstream keycloak { ip_hash; server 127.0.0.1:8080; }

    server
    {   
        server_name name.domain.tld;
        listen 443 ssl http2; # managed by Certbot
        ssl_certificate /path/to/cert; # managed by Certbot
        ssl_certificate_key /path/to/key; # managed by Certbot
        include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
        ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

        location /
        {   
            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-Proto $scheme;
            add_header Access-Control-Allow-Origin *;
            proxy_pass http://keycloak;
        }
    }


    server
    {   
        server_name name.domain.tld;
        listen 80;
        location / { return 301 https://$server_name; }
    }

}

Nothing has been changed at any file inside the keycloak directory.

Keycloak is accessible, however when navigating to the login page, I encouter a blank page because of a mixed-content javascript from "/auth/js/keycloak.js?version=df45z".

This can be temporarily solved by disabling the browsers protection against mixed content, however this will get me to an dysfunctional loginpage giving me this error message: " We are sorry... Invalid parameter: redirect_uri".

Also, a HTTP 400 was returned from "/auth/realms/master/protocol/openid-connect/auth?client_id=security-admin-console&redirect_uri=https%3A%2F%2Fname.domain.tld%2Fauth%2Fadmin%2Fmaster%2Fconsole%2F&state=5abb646f-d1c8-49ef-8ae1-9358bfc50d6d&response_mode=fragment&response_type=code&scope=openid&nonce=525b593c-07ab-4afa-8ca0-bd64499061eb".

(Hoping it's origin is of any value)

Previous questions relating this issue only suggested to add the proxy_set_header directives, which avoided a blank screen of the initial dashboard you see when you access keycloaks webpage but not helped in the latter mentioned problem.

Please take into account I'm quite new to this subject matter should I've missed something trivial.

Any advice to fix this behaviour is highly appreciated.

nginx reverse-proxy single-sign-on mixed-content

3 Answers

  1. Best Answer

    Your Nginx configuration looks fine. I recently had the same issue as you had and had more or less the same Nginx configuration.

    The only thing I still needed to do is to update the standalone configuration file in the KeyCloak folder. You can find this file at keycloak_folder/standalone/configuration/standalone.xml.

    Here you will have to look for the following (+- line 572):

    <server name="default-server">
    <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true" />
    ...
</server>

    And add the proxy-address-forwarding=true like this:

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

    This will make sure that your internal KeyCloak JBoss server is aware of the proxy address.

    • 10

  2. Keycloak accepts PROXY_ADDRESS_FORWARDING env which gets placed in the standalone.xml

    <http-listener name="default" socket-binding="http" redirect-socket="https" proxy-address-forwarding="${env.PROXY_ADDRESS_FORWARDING:false}" enable-http2="true"/>

    provide PROXY_ADDRESS_FORWARDING to docker either with docker -e or docker-compose environment section

    • 2

  3. Additional to what Thorchy wrote:

    I had http_auth enabled at nginx. I missed to restart nginx after removing it from the configuration.

    Disabling http_auth by restarting nginx finally solved the problem.

    • 0