Missing "s" in auth

1

JSF project
Wildfly + App (on 8080)
Same Server Keycloak (on 8180)

When I trigger a login (by going to a page that needs login) I go to this link:

https://thexxxxxx.nz/auth/realms/TheXxxxxXxxxx/protocol/openid-connect/auth?response_type=code&client_id=thexxxxxxxxx&redirect_uri=https%3A%2F%2Fthexxxxxxx.nz%2Fthexxxxxxx%2Fpages%2Fmy%2Fdashboard.jsf&state=8a73b245-b8b2-41ff-8dd4-9c28d4066e17&login=true&scope=openid

This gives:
Invalid parameter: redirect_uri

If I then change the redirect to https:

https->

redirect_uri=https%3A%2F%2Fthexxxxxxx.nz%2Fthexxxxxxx%2Fpages%2Fmy%2Fdashboard.jsf&state=8a73b245-b8b2-41ff-8dd4-9c28d4066e17&login=true&scope=openid

then I get to keycloak (more problems later; but I would like to fix this first)

The question is where do I look to set the redirect to be https?

Note:
These are the changes I did to cope with https and nginx (based on the doco):

<subsystem xmlns="urn:jboss:domain:undertow:10.0" default-server="default-server" default-virtual-host="default-host" default-servlet-container="default" default-security-domain="other" statistics-enabled="${wildfly.undertow.statistics-enabled:${wildfly.statistics-enabled:false}}">
            <buffer-cache name="default"/>
            <server name="default-server">
                <http-listener name="default" socket-binding="http" redirect-socket="proxy-https" enable-http2="true" proxy-address-forwarding="true" />
                <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>
                <host name="default-host" alias="localhost">
                    <location name="/" handler="welcome-content"/>
                    <http-invoker security-realm="ApplicationRealm"/>
                </host>
            </server>

and

    <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
    <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
    <socket-binding name="http" port="${jboss.http.port:8080}"/>
    <socket-binding name="https" port="${jboss.https.port:8443}"/>
    <socket-binding name="proxy-https" port="443"/>
    <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
    <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
    <socket-binding name="txn-recovery-environment" port="4712"/>
    <socket-binding name="txn-status-manager" port="4713"/>
    <outbound-socket-binding name="mail-smtp">
        <remote-destination host="localhost" port="25"/>
    </outbound-socket-binding>
</socket-binding-group>

On wildfly app server:

 <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
        <secure-deployment name="thexxxxx.war">
            <realm>TheXxxxXxxxx</realm>
            <resource>thexxxxxxx</resource>
            <public-client>true</public-client>
            <auth-server-url>https://thexxxxx.nz/auth/</auth-server-url>
            <ssl-required>EXTERNAL</ssl-required>
        </secure-deployment>
    </subsystem>

This is nginx config

server {

    # SSL configuration
    #
    # listen 443 ssl default_server;
    # listen [::]:443 ssl default_server;
    #
    # Note: You should disable gzip for SSL traffic.
    # See: https://bugs.debian.org/773332
    #
    # Read up on ssl_ciphers to ensure a secure configuration.
    # See: https://bugs.debian.org/765782
    #
    # Self signed certs generated by the ssl-cert package
    # Don't use them in a production server!
    #
    # include snippets/snakeoil.conf;

    root /var/www/html;

    # Add index.php to the list if you are using PHP
    index index.html index.htm index.nginx-debian.html;
server_name www.thexxxxx.nz thexxxxxxx.nz; # managed by Certbot


    location / {
            # First attempt to serve request as file, then
            # as directory, then fall back to displaying a 404.
            try_files $uri $uri/ =404;
    }

location /thexxxxxx/ {
    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;
    proxy_pass http://127.0.0.1:8080/thexxxxxx/;
    client_max_body_size 10M;
}


location /auth/ {
    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;
    proxy_pass http://127.0.0.1:8180/auth/;
    client_max_body_size 10M;
}

    # pass PHP scripts to FastCGI server
    #
    #location ~ \.php$ {
    #       include snippets/fastcgi-php.conf;
    #
    #       # With php-fpm (or other unix sockets):
    #       fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
    #       # With php-cgi (or other tcp sockets):
    #       fastcgi_pass 127.0.0.1:9000;
    #}

    # deny access to .htaccess files, if Apache's document root
    # concurs with nginx's one
    #
    #location ~ /\.ht {
    #       deny all;
    #}


listen [::]:443 ssl ipv6only=on; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/www.thexxxxxx.nz/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/www.thexxxxx.nz/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}
server {
if ($host = thexxxxxx.nz) {
    return 301 https://$host$request_uri;
} # managed by Certbot


if ($host = www.thexxxxx.nz) {
    return 301 https://$host$request_uri;
} # managed by Certbot


    listen 80 ;
    listen [::]:80 ;
server_name www.thexxxxxx.nz thexxxxxxx.nz;
return 404; # managed by Certbot

}

2

Does anyone have an idea.
Getting this going is stopping a quite public launch.
I have googled and there are lots and lots of posts on this problem; but nothing yet has helped find any solution.

3

I found a workaround
Probably a huge security hole; but it works:

badsolution
badsolution946×84 3.02 KB

Put a star in the Valid Redirect URIs

4

Without knowing the full setup I can only mention what I can see from the configuration files you posted.

In your Nginx config you can take a look at the following

  • proxy_pass http instead of https -> never mind this one, I though you were using domains
  • listen 443 ssl -> listen 443 ssl http2 …

Check https://www.keycloak.org/docs/latest/server_installation/index.html#verify-configuration and verify through the url and log files if everything is sent as expected.

Are you terminating TLS on Nginx or have you setup Keycloak with a Keystore?

5

I changed to listen 443 ssl http2
I also added the http redirect and that seems to work… which is really odd; but at least it’s working and probably a lot more secure.