Utilizzando Keycloak dietro un proxy inverso: impossibile aprire l’Admin di partenza, perché il Contenuto misto

quindi ho un problema ottenere keycloak 3.2.1 lavorare dietro kong (0.10.3), un reverse proxy basato su nginx.

Scenario è:

Ho chiamata keycloak via il mio gateway-via https://{gateway}/auth e mi mostra il punto di accesso con keycloak logo, link alla console di amministrazione etc. – finora tutto bene.

Ma quando si fa clic su console di amministrazione -> chiamando il https://{gateway}/auth/admin/master/console/ , keycloak tenta di caricare il css/js via http (vedi screenie sotto), che il mio browser blocca a causa di contenuto misto.

Ho cercato in giro e ho trovato questo thread: keycloak apache server di configurazione con un Misto di Contenuto’ problemi che conducono a questo repo github: https://github.com/dukecon/keycloak_postgres_https

Da lì in poi, ho cercato di integrare la sua’ cli nel mio dockerfile con successo (non modificare i file di contenuto, appena copiato nel mio repo e aggiungere/eseguire dal dockerfile). Questo è il mio dockerfile ora:

FROM jboss/keycloak-postgres:3.2.1.Final

USER root

ADD config.sh /tmp/
ADD batch.cli /tmp/

RUN bash /tmp/config.sh

#Give correct permissions when used in an OpenShift environment.
RUN chown -R jboss:0 $JBOSS_HOME/standalone && \
    chmod -R g+rw $JBOSS_HOME/standalone

USER jboss
EXPOSE 8080

Purtroppo il mio problema persiste:
Utilizzando Keycloak dietro un proxy inverso: impossibile aprire l'Admin di partenza, perché il Contenuto misto

Quindi sono a corto di idee, per ora, e spero che possiate aiutarmi:

  • Come faccio a dire keycloak per chiamare il suo’ css file tramite https qui?

  • devo cambiare qualcosa nella cli script?

Ecco il contenuto dello script:

config.sh:

#!/bin/bash -x

set -e

JBOSS_HOME=/opt/jboss/keycloak
JBOSS_CLI=$JBOSS_HOME/bin/jboss-cli.sh
JBOSS_MODE=${1:-"standalone"}
JBOSS_CONFIG=${2:-"$JBOSS_MODE.xml"}

echo "==> Executing..."
cd /tmp

$JBOSS_CLI --file=`dirname "$0"`/batch.cli

# cf. http://stackoverflow.com/questions/34494022/permissions-error-when-using-cli-in-jboss-wildfly-and-docker
/bin/rm -rf ${JBOSS_HOME}/${JBOSS_MODE}/configuration/${JBOSS_MODE}_xml_history/current

e batch.cli:

embed-server --std-out=echo

# http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html
# 3.2.7.2. Enable SSL on a Reverse Proxy
# First add proxy-address-forwarding and redirect-socket to the http-listener element.
# Then add a new socket-binding element to the socket-binding-group element.

batch

/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=proxy-address-forwarding,value=true)

/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=redirect-socket,value=proxy-https)

/socket-binding-group=standard-sockets/socket-binding=proxy-https:add(port=443)

run-batch

stop-embedded-server

Può essere di interesse anche, che kong è distribuito su openshift con un percorso utilizzando un redirect da http a https ( “insecureEdgeTerminationPolicy”: “Redirect” ).

  • Avete risolto questo problema? C’è un esempio che posso vedere?
InformationsquelleAutor Dominik | 2017-11-08



2 Replies
  1. 14

    Questo suona un po ‘ come un duplicato di Keycloak scaricatore di porto dietro loadbalancer con https non riesce

    Impostare le intestazioni di richiesta X-Forwarded-For e X-Forwarded-Proto in nginx. Quindi è necessario configurare Keycloak (Wildfly, Risacca) collaborare con il di terminazione SSL proxy inverso (aka sistema di bilanciamento del carico). Vedere http://www.keycloak.org/docs/latest/server_installation/index.html#_setting-up-a-load-balancer-or-proxy per una descrizione dettagliata.

    Il punto è che nginx è di terminazione SSL e per l’inoltro delle richieste Keycloak come pure http. Pertanto Keycloak/Wildfly deve essere detto che l’arrivo di http richieste nginx devono essere trattati come se fossero https.

    • vado a controllare kong/nginx e accettare la risposta, quando sono sicuro (non è il mio banco di lavoro di atm, in modo che richiedono un certo tempo). Grazie finora!
    • Per chiunque sia bloccato nella stessa situazione, ti permetterà anche di questo suggerimento qui: a parte le cose che Boomer descritto (in realtà, kong invia il corretto intestazioni per default), abbiamo avuto un problema con il nostro openshift servizio, che è stato chiamato via 8080. la porta standard vincolanti per 8080 in kc è http, in modo kc servita http. Abbiamo cambiato il nostro openshift config di utilizzare 8443, et voilà. ha lavorato. 🙂
    • Un po ‘ estranei domanda, come si fa a Keycloak di risolvere l’url di base? Abbiamo un Keycloak esempio con un pubblico e privato l’indirizzo ip e la iss campo della JWT portatore di token (che è il regno url) cambia, cioè se abbiamo raggiunto l’auth endpoint dall’indirizzo pubblico il iss campo è public-ip/realms/master e dall’indirizzo ip privato è private-ip/realms/master. Questo è un HTTP magia o un Kycloak config? Docs parlare di impostazione del proxy inverso, ma questo è un caso diverso, suppongo.
  2. 11

    Aggiungere il X-Forwarded-For e X-Forwarded-Proto intestazioni (come Boomer detto) in tutto a monte bilanciatori di carico e assicurarsi che tali raggiungere Keycloak server.
    X-Forwarded-For dovrebbe essere il dominio del tuo Keycloak che le rotte per il LB e X-Forwarded-Proto dovrebbe essere il protocollo (la maggior parte dei casi https).

    Come passo finale è necessario modificare standalone.xml o standalone-ha.xml file e aggiungere il proxy-address-forwarding="true" attributo <http-listener> elemento sotto <server>.

    Se si utilizza la finestra Mobile è possibile utilizzare PROXY_ADDRESS_FORWARDING ambiente var dall’originale Keycloak contenitore di impostare l’attributo.

Lascia un commento