[keycloak-user] Passing External URL Bearer Token to Interior Proxy URL in Multi-Hop scenario

[Joe Strathern]

Stian
Thank you for your response.
I am using your Wildfly adapter to secure my WAR. As it is contained in a
cluster enviroment with a load balancing proxy, I updated my adapter to
have the following settings, much like the example provided at
http://keycloak.github.io/docs/userguide/keycloak-server/html/applicationClustering.html#relative-uri-optimization
:
{
   ...
   <auth-server-url>/auth</auth-server-url>

 <auth-server-url-for-backend-requests>http:/internal-hostname/auth</auth-server-url-for-backend-requests>
   ...
}

The auth-server-url is still working as expected for the external request,
however i am still getting the same 401 error, caused by the mismatching
Token audience and Domain when I try to make the hop with my new HTTP
request.
As i'm using Keycloak 1.7.0.Final currently, i downloaded the source and
debugged, looking for a bit more insight as to what may be occurring.

I noticed that the URL Keycloak is retrieving to compare against the token,
is retrieving it from the realmInfoUrl variable of the KeyCloakDeployment
object. This variable is unaffected by the
auth-server-url-for-backend-requests option. (Instead it affects numerous
other URL variabled stored). Therefore, the realmInfoURL remains
http://external-hostname/auth.

Then the error occurs as (in this case), the RSATokenVerifier directly
compares this Realm URL against the Token Issuer, which differ due hostname
(external vs internal, as before).

Is there an additional configuration, or concept I am missing to correct
this workflow?

Thanks,
Joe

On Wed, Jan 20, 2016 at 1:22 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> Assuming you are using our adapters there are two separate urls to
> configure: "auth-server-url" is the external
> one, auth-server-url-for-backend-requests is the internal one. See
> http://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#adapter-config
> for more details.
>
> On 19 January 2016 at 22:20, Joe Strathern <jstrathern at gmail.com> wrote:
>
>> Hello Keycloak Community
>>
>> I am looking for some assistance on how to pass a Keycloak bearer token
>> in the multi-hop scenario, where the keycloak instance is inside a proxy
>> environment, the next hop is within the proxy, and the original request
>> came from outside of that environment.
>>
>> For instance, the original request goes to http://external-hostname/auth,
>> where external-hostname is a proxy system. Login is successful, and I
>> receive a Bearer Token with Token issuer -
>> http://external-hostname/auth/realms/My_Realm.
>>
>> Now i need to take that token from the HTTP request, and attach it to a
>> new request from inside the proxy. I do so, redirecting to
>> http://interior-hostname/API, secured by the same Keycloak. Using
>> "external-hostname" as host once more is not an option, as we are within
>> the proxied environment. However, submitting the hop HTTP request,  i am
>> met with the error:
>>
>> *Failed to verify token: org.keycloak.common.VerificationException: Token
>> audience doesn't match domain. Token issuer
>> is http://external-hostname/auth/realms/My_Realm
>> <http://external-hostname/auth/realms/My_Realm>, but URL from configuration
>> is http://internal-hostname/auth/realms/My_Realm
>> <http://internal-hostname/auth/realms/My_Realm>*
>>
>> The token is rejected (Since the hostnames are not the exact same),
>> however external-hostname and internal-hostname are the same machine.
>>
>> Is there a way that Keycloak can identify these hostnames as equivalent
>> to accept the token, or another policy that should be followed in this
>> situation?
>>
>> Thanks,
>> Joe
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160121/9541a5c4/attachment-0001.html