<div dir="ltr">Good day,<div><br></div><div>I&#39;m working with Keycloak 1.7.0.Final (in it&#39;s own Wildfly) behind a HAProxy instance.  A REST service is deployed (as .war) on another server (also behind HAProxy) in a JBoss EAP instance, protected using the Keycloak adapter.</div><div><br></div><div>The deployment is protected as follows in standalone.xml of the JBoss instance:</div><div><br></div><div><div>          &lt;secure-deployment name=&quot;mytest.war&quot;&gt;</div><div>                &lt;realm&gt;MyRealm&lt;/realm&gt;</div><div>                &lt;resource&gt;my-resource&lt;/resource&gt;</div><div>                &lt;use-resource-role-mappings&gt;true&lt;/use-resource-role-mappings&gt;</div><div>                &lt;enable-basic-auth&gt;true&lt;/enable-basic-auth&gt;</div><div>                &lt;public-client&gt;true&lt;/public-client&gt;</div><div>                &lt;realm-public-key&gt;MIIB...QAB&lt;/realm-public-key&gt;</div><div>                &lt;auth-server-url&gt;/auth&lt;/auth-server-url&gt;</div><div>                &lt;auth-server-url-for-backend-requests&gt;<a href="http://proxy:8080/auth">http://proxy:8080/auth</a>&lt;/auth-server-url-for-backend-requests&gt;</div><div>                &lt;ssl-required&gt;NONE&lt;/ssl-required&gt;</div><div>                &lt;principal-attribute&gt;preferred_username&lt;/principal-attribute&gt;</div><div>            &lt;/secure-deployment&gt;</div></div><div><br></div><div>Here is relevant section of mytest.war&#39;s web.xml:</div><div><br></div><div><div> &lt;security-constraint&gt;</div><div>    &lt;web-resource-collection&gt;</div><div>      &lt;web-resource-name&gt;All Admin&lt;/web-resource-name&gt;</div><div>      &lt;url-pattern&gt;/*&lt;/url-pattern&gt;</div><div>    &lt;/web-resource-collection&gt;</div><div>    &lt;auth-constraint&gt;</div><div>      &lt;role-name&gt;my-admins&lt;/role-name&gt;</div><div>    &lt;/auth-constraint&gt;</div><div>    &lt;user-data-constraint&gt;</div><div>      &lt;transport-guarantee&gt;NONE&lt;/transport-guarantee&gt;</div><div>    &lt;/user-data-constraint&gt;</div><div>  &lt;/security-constraint&gt;</div><div><br></div><div>  &lt;login-config&gt;</div><div>    &lt;auth-method&gt;KEYCLOAK&lt;/auth-method&gt;</div><div>    &lt;realm-name&gt;this is ignored currently&lt;/realm-name&gt;</div><div>  &lt;/login-config&gt;</div><div>  &lt;security-role&gt;</div><div>    &lt;description&gt;Admin access for admins.&lt;/description&gt;</div><div>    &lt;role-name&gt;my-admins&lt;/role-name&gt;</div><div>  &lt;/security-role&gt;</div></div><div><br></div><div>Due to the use of the old JBoss EAP 6.1 server, I&#39;ve had to add the following to mytest.war&#39;s jboss-web.xml to support proxying, with proxy headers added by HAProxy:</div><div><br></div><div><div>&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;</div><div>&lt;jboss-web&gt;</div><div>  &lt;security-domain&gt;keycloak-web&lt;/security-domain&gt;</div><div>  &lt;context-root&gt;mytest&lt;/context-root&gt;</div><div>  &lt;valve&gt;</div><div>    &lt;class-name&gt;org.apache.catalina.valves.RemoteIpValve&lt;/class-name&gt;</div><div>    &lt;param&gt;</div><div>      &lt;param-name&gt;protocolHeader&lt;/param-name&gt;</div><div>      &lt;param-value&gt;x-forwarded-proto&lt;/param-value&gt;</div><div>    &lt;/param&gt;</div><div>  &lt;/valve&gt;</div><div>&lt;/jboss-web&gt;</div></div><div><br></div><div><div>The hostname &quot;proxy&quot; is resolvable within the cluster behind HAProxy and will result in direct access to the Keycloak instance.   From outside the cluster, all the services are mapped to the same HTTP namespace by HAProxy.  So an external request to http://[external_haproxy]/auth will be proxied to Keycloak in the cluster. The &#39;my-resource&#39; Keycloak client has direct access grants enabled and is set to Public access.</div></div><div><br></div><div>In testing, where the entire cluster is launched in Vagrant running on Windows, if I access <a href="http://localhost/mytest/api/.">http://localhost/mytest/api/.</a>.. in a browser, I am shown the Keycloak login and get the REST service result as expected.  This tells me that the majority of my configuration above is good.</div><div><br></div><div>However, if I use a client like curl or JMeter to send a similar HTTP request with the Basic authentication header added:</div><div><table>
<tbody><tr>
  <td>    Authorization:</td>
  <td>Basic YWRtaW46YWRtaW4=</td>
</tr>
</tbody></table></div><div><br></div><div>Then the following is observed in the JBoss log from Keycloak adapter:</div><div><br></div><div><div>  2016-01-04 20:03:49,295 DEBUG [org.keycloak.adapters.BasicAuthRequestAuthenticator] (http-/0.0.0.0:8080-1) Failed to obtain token: java.net.ConnectException: Connection refused</div></div><div><br></div><div>Upon debugging through the Keycloak adapter code to watch the basic authentication process, I found myself in BasicAuthRequestAuthenticator,getToken() where I find that <b>deployment.getAuthServerBaseUrl()</b>  == &quot;<a href="http://localhost/auth">http://localhost/auth</a>&quot; which is not valid on the JBoss EAP system.  This tells me that the external hostname (Vagrant host) is being used to build the URI for contacting the internal Keycloak host.  In particular, the provided value for &lt;auth-server-url-for-backend-requests&gt; is not being used.  Since this Basic Auth code uses this URI to issue a &quot;backend&quot; request, I would have expected the &lt;auth-server-url-for-backend-requests&gt; value to be used.</div><div><br></div><div>So my question is whether I am missing a basic authentication specific configuration step or whether I&#39;ve encountered a defect in URI handling for basic auth + backend requests. Interestingly, in the attached Eclipse screenshot, the deployment object is aware of the <a href="http://proxy:8080">http://proxy:8080</a> URI backend but it is not being used for authServerBaseUrl.</div><div><br></div><div>Note, the scope of this problem is more than my Vagrant/localhost example.  I expect the same problem to manifest in our AWS test environment where external hostnames don&#39;t resolve for cluster members identified by internal hostnames only.  I&#39;m hoping to find a solution before this hits our test environment.</div><div><br></div><div>Thanks in advance,</div><div>Guy</div><div><br></div></div>