<div dir="ltr">In your backend services you should use "auth-server-url-for-backend-requests" to specify the internal url of Keycloak, and "auth-server-url" should be set to the external url. For more details take a look at:<div><a href="http://keycloak.github.io/docs/userguide/html/applicationClustering.html#relative-uri-optimization">http://keycloak.github.io/docs/userguide/html/applicationClustering.html#relative-uri-optimization</a><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 24 September 2015 at 11:54, Kevin Thorpe <span dir="ltr"><<a href="mailto:kevin.thorpe@p-i.net" target="_blank">kevin.thorpe@p-i.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I, and others are having problems using this in the real world because of the 'identity' of Keycloak.<div><br></div><div>I'm running Keycloak in a Docker(Rancher) container. Alongside it are my backend containers holding</div><div>the internal components of the application. On top of the application is an nginx container containing</div><div>an AngularJS application and proxying Angular's service calls to the backend container.</div><div><br></div><div>The problem comes when I sit an external load balancer/SSL layer in front of the application. The </div><div>user is now contacting the application on its external hostname in our DMZ. Authentication then has</div><div>to be performed against Keycloak on a DMZ IP/URL. Easy enough to arrange, just use Nginx again</div><div>as a proxy for Keycloak. This all works for the frontend and the user can log in.</div><div><br></div><div>The problem occurs when the backend service containers try and validate the user token. They </div><div>cannot do this directly to Keycloak inside the Docker ecosystem. All I get in that case is this </div><div>token was issued by <external hostname:port> and you are presenting it to <internal hostname:port> </div><div>(can't remember the exact wording).</div><div><br></div><div>I can get this to work by getting my backend containers to authenticate against <external hostname></div><div>but that is creating traffic out of the docker LAN and back in again, not the most efficient way to </div><div>do things. </div><div><br></div><div>Would this be a good use case for Keycloak aliases? Then I can present a token issued by </div><div><external URL> to <internal URL> and Keycloak will understand that it was actually issued by</div><div>itself under a different identity. Better still I could proxy Keycloak within the URL of the front-end</div><div>application which would place the whole application; website, service and authentication under the</div><div>one hostname.</div><span class="HOEnZb"><font color="#888888"><div><br clear="all"><div><div><div dir="ltr"><div dir="ltr"><div><font color="#000000"><b>Kevin Thorpe<br></b></font></div>
<div>CTO<br></div>
<div><br>
</div>
<div><br></div></div></div></div></div>
</div></font></span></div>
<br>_______________________________________________<br>
keycloak-user mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br></blockquote></div><br></div>