libre.sh/keycloak-scim
2
0
Fork 0
Code Issues 14 Pull requests Releases Packages Activity Actions 6

KEYCLOAK-3558 Add note that original host header needs to be preserved

Browse source
This commit is contained in:
Stian Thorgersen 2017-01-04 08:18:45 +01:00
parent f99c341207
commit 1648dfaa4e
1 changed files with 24 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

27
topics/clustering/load-balancer.adoc
View file

@ -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:
</socket-binding-group>
----
==== 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