From 1648dfaa4e08e26b61108ad16910117cc5ee7447 Mon Sep 17 00:00:00 2001 From: Stian Thorgersen Date: Wed, 4 Jan 2017 08:18:45 +0100 Subject: [PATCH] KEYCLOAK-3558 Add note that original host header needs to be preserved --- topics/clustering/load-balancer.adoc | 27 ++++++++++++++++++++++++--- 1 file changed, 24 insertions(+), 3 deletions(-) diff --git a/topics/clustering/load-balancer.adoc b/topics/clustering/load-balancer.adoc index 1234f67e9b..299b54c01a 100755 --- a/topics/clustering/load-balancer.adoc +++ b/topics/clustering/load-balancer.adoc @@ -15,11 +15,12 @@ The usual setup is that you have a frontend proxy sitting on a public network th to backend {{book.project.name}} server instances located in a private network. There is some extra configuration you have to do in this scenario so that the actual client IP address is forwarded to and processed by the {{book.project.name}} server instances. Specifically: -* Configure your reverse proxy (loadbalancer) to properly set `X-Forwarded-For` and `X-Forwarded-Proto` HTTP headers. +* Configure your reverse proxy or loadbalancer to properly set `X-Forwarded-For` and `X-Forwarded-Proto` HTTP headers. +* Configure your reverse proxy or loadbalancer to preserve the original 'Host' HTTP header. * Configure the authentication server to read the client's IP address from `X-Forwarded-For header`. -Configuring your proxy to generate the `X-Forwarded-For` and `X-Forwarded-Proto` HTTP headers is beyond the scope of this -guide. Take extra precautions to ensure that the +Configuring your proxy to generate the `X-Forwarded-For` and `X-Forwarded-Proto` HTTP headers and preserving the + original `Host` HTTP header is beyond the scope of this guide. Take extra precautions to ensure that the `X-Forwared-For` header is set by your proxy. If your proxy isn't configured correctly, then _rogue_ clients can set this header themselves and trick {{book.project.name}} into thinking the client is connecting from a different IP address than it actually is. This becomes really important if you are doing any black or white listing of IP addresses. @@ -104,6 +105,26 @@ Then add a new `socket-binding` element to the `socket-binding-group` element: ---- +==== Verify Configuration + +You can verify the reverse proxy or load balancer configuration by opening the path `/auth/realms/master/.well-known/openid-configuration` +through the reverse proxy. For example if the reverse proxy address is `https://acme.com/` then open the URL +`https://acme.com/auth/realms/master/.well-known/openid-configuration`. This will show a JSON document listing a number +of endpoints for {{book.project.name}}. Make sure the endpoints starts with the address (scheme, domain and port) of your +reverse proxy or load balancer. By doing this you make sure that {{book.project.name}} is using the correct endpoint. + +You should also verify that {{book.project.name}} sees the correct source IP address for requests. Do check this you can +try to login to the admin console with an invalid username and/or password. This should show a warning in the server log +something like this: + +[source] +---- +08:14:21,287 WARN XNIO-1 task-45 [org.keycloak.events] type=LOGIN_ERROR, realmId=master, clientId=security-admin-console, userId=8f20d7ba-4974-4811-a695-242c8fbd1bf8, ipAddress=X.X.X.X, error=invalid_user_credentials, auth_method=openid-connect, auth_type=code, redirect_uri=http://localhost:8080/auth/admin/master/console/?redirect_fragment=%2Frealms%2Fmaster%2Fevents-settings, code_id=a3d48b67-a439-4546-b992-e93311d6493e, username=admin +---- + +Check that the value of `ipAddress` is the IP address of the machine you tried to login with and not the IP address + of the reverse proxy or load balancer. + ==== Using the Built-In Load Balancer This section covers configuring the built in load balancer that is discussed in the