Zunächst einmal this section(8.3. Setting Up a Load Balancer or Proxy) Keycloak Dokumentation war absolut hilfreich. Ich war in der Lage, Dinge irgendwie funktionieren zu lassen, aber ich fühle immer noch, dass Dinge besser und sicherer erledigt werden können!
Ich werde nicht die erforderliche Konfiguration für die Keycloak-Seite wiederholen, aber ich gebe eher einige Hinweise für Sie, falls Sie Nginx als Reverse-Proxy verwenden.
Hier ist meine nginx.conf die configs erforderlich enthält:
`` `
upstream rock-app {
server rock-app:8080;
}
upstream keycloak {
server keycloak:9080;
}
server {
listen 80;
listen 443 ssl http2;
...
add_header Strict-Transport-Security "max-age=86400; includeSubdomains; preload" always;
...
}
location/{
proxy_set_header HOST $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X_FORWARDED_PROTO $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://rock-app;
}
location /auth {
proxy_set_header HOST $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X_FORWARDED_PROTO $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://keycloak;
}
` ``
Hinweis: add_header Strict-Transport-Security ... Teil wichtig ist, und sicherzustellen, dass wir Nutzer in https-Protokoll bleiben, wenn Sie betreten die Site mit einer https-URL. Bitte korrigieren Sie mich, wenn ich falsch liege !?
Wenn ich nun folgende URL besuchen:
https://my-example.com/auth/realms/jhipster/.well-known/openid-configuration
ich diese Antwort sehen: statt
{
"issuer": "http://my-example.com/auth/realms/jhipster",
"authorization_endpoint": "http://my-example.com/auth/realms/jhipster/protocol/openid-connect/auth",
"token_endpoint": "http://my-example.com/auth/realms/jhipster/protocol/openid-connect/token",
"token_introspection_endpoint": "http://my-example.com/auth/realms/jhipster/protocol/openid-connect/token/introspect",
"userinfo_endpoint": "http://my-example.com/auth/realms/jhipster/protocol/openid-connect/userinfo",
"end_session_endpoint": "http://my-example.com/auth/realms/jhipster/protocol/openid-connect/logout",
"jwks_uri": "http://my-example.com/auth/realms/jhipster/protocol/openid-connect/certs",
"check_session_iframe": "http://my-example.com/auth/realms/jhipster/protocol/openid-connect/login-status-iframe.html",
"grant_types_supported": ["authorization_code", "implicit", "refresh_token", "password", "client_credentials"],
"response_types_supported": ["code", "none", "id_token", "token", "id_token token", "code id_token", "code token", "code id_token token"],
"subject_types_supported": ["public", "pairwise"],
"id_token_signing_alg_values_supported": ["RS256"],
"userinfo_signing_alg_values_supported": ["RS256"],
"request_object_signing_alg_values_supported": ["none", "RS256"],
"response_modes_supported": ["query", "fragment", "form_post"],
"registration_endpoint": "http://my-example.com/auth/realms/jhipster/clients-registrations/openid-connect",
"token_endpoint_auth_methods_supported": ["private_key_jwt", "client_secret_basic", "client_secret_post"],
"token_endpoint_auth_signing_alg_values_supported": ["RS256"],
"claims_supported": ["sub", "iss", "auth_time", "name", "given_name", "family_name", "preferred_username", "email"],
"claim_types_supported": ["normal"],
"claims_parameter_supported": false,
"scopes_supported": ["openid", "offline_access"],
"request_parameter_supported": true,
"request_uri_parameter_supported": true
}
Wie Sie http://my-example.com/... wird bemerken können https://my-example.com/... gezeigt
Deshalb hatte ich um die folgende Konfiguration meines Realms (jhipster-realm.json) von zu ändern zu "sslRequired" : "none", was ich nicht weiß, ob es eine schlechte Sache ist? unter Berücksichtigung (1) verlässt mein Browser niemals https, wenn ich den Login-Workflow teste und (2) meine Keycloak-Instanz ist nicht zugänglich über einen öffentlichen Port.
Nun, ich werde nicht meine eigene Antwort als akzeptierte Antwort akzeptieren, denn wie ich bereits sagte, ich Dinge besser fühlen lassen können getan und in sicherer Weise. Vielen Dank!
Dockerfile
FROM jboss/keycloak:3.4.1.Final
standalone.xml
<server name="default-server">
...
<http-listener name="default" socket-binding="http" redirect-socket="proxy-https" proxy-address-forwarding="${env.PROXY_ADDRESS_FORWARDING}" certificate-forwarding="true" enable-http2="true"/>
<https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" proxy-address-forwarding="${env.PROXY_ADDRESS_FORWARDING}" certificate-forwarding="true" enable-http2="true"/>
...
<socket-binding-group ...
<socket-binding name="proxy-https" port="443"/>
...
01:
aktualisieren
Ich habe für die Verwendung von HTTPS-Protokoll folgende Änderungen vorgenommen
nginx.conf
upstream keycloak {
server keycloak:9443;
}
...
server {
listen 80;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
...
location /auth {
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X_FORWARDED_PROTO $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass https://keycloak;
}
...
jhipster-realm.json
...
"sslRequired": "external",
HTH, Dank!
Ich fand folgende Frage: https://Stackoverflow.com/q/42342367/2179502 dieser Frage ziemlich ähnlich, und zur Verfügung gestellt Workaround: https://StackOverflow.com/a/42504805/2179502 als eine Möglichkeit, voranzukommen . Aber als Autor dieser Lösung erwähnt, ist der Nachteil, dass jede Anfrage durch das Web gehen muss, um Keycloak-Instanz zu finden! und wir können nicht von unserem lokalen Netzwerk für die Kommunikation mit der Keycloak-Instanz profitieren. –