[keycloak-user] Zuul (Gateway) -> Keycloak Adapters Missing pieces

Fri Sep 8 05:00:27 EDT 2017

One option would be to use multi tenant setup so your applications can trust multiple issuer urls, in your case internal and external.

http://www.keycloak.org/docs/2.3/securing_apps_guide/topics/oidc/java/multi-tenancy.html

We're not using zuul but we do have multiple services behind load balancers and reverse proxies. In our situation we setup proxy address forwarding as below. All of the micro services use the public issuer URL as their authority and as token service for service accounts.

http://www.keycloak.org/docs/1.9/server_installation_guide/topics/clustering/load-balancer.html

Not sure if this helps.

________________________________
From: keycloak-user-bounces at lists.jboss.org <keycloak-user-bounces at lists.jboss.org> on behalf of Mauricio Salatino <salaboy at gmail.com>
Sent: Friday, September 8, 2017 4:00:00 AM
To: Sebastien Blanc
Cc: keycloak-user
Subject: Re: [keycloak-user] Zuul (Gateway) -> Keycloak Adapters Missing pieces

After spending another day thinking about how this should work, I decided
to post some other questions that might help us to get the conversation
forward:
@Sebastien I will appreciate your feedback, I'm a complete newbie on this
as well so no judgments will be emitted ;)

In the case that someone uses a gateway / reverse proxy in front of
keycloak:

*a) do we expect the token to be issued for the internal (DNS internal
name) services only? *
   The only problem that we are facing when we do this, is the keycloak UI
forms that point to the internal ip instead of the external. In order to
fix this we will try to
   only forward the X-Forwarded-* headers when we call the UI forms. But
all the token verification will be done with the internal host DNS name.

*b) or the token should be issued to the external issuer by using
X-Forwarded-* Headers? *
   For covering this case the problem is the configuration in the adapters,
and I think that to solve that the "auth-server-url-for-backend-requests"
was added and then removed.
While I understand how we can solve some of those issues with
internal/external DNS name resolution, the Token Verification is to strict
and it does a simple string comparison of the whole ISS which includes
several things: http/s (protocol) + host (internal/external) + port (might
be different the internal/external). So even thought if we manage to
resolve the host via DNS the port and the protocol might still be a
problem. Also notice that because of this there are two unrelated things
coupled together: 1) token verification 2) how to contact the keycloak
server at least in my head this is calling for some extra flexibility on
the configuration side.

I think that I've summarised most of the problems that everyone will have
while trying to use a reverse proxy (like Zuul) and Keycloak, I might be
missing something big here, so please advise.

On Thu, Sep 7, 2017 at 3:21 PM, Mauricio Salatino <salaboy at gmail.com> wrote:

> We are using a Reverse Proxy already .. I was checking that.. do we need
> something specifically from it? I want to understand what is keycloak
> expecting from that reverse proxy.
>
> Cheers
>
> On Thu, Sep 7, 2017 at 2:53 PM, Mauricio Salatino <salaboy at gmail.com>
> wrote:
>
>> Sebastien, thanks a lot for the answer,
>> regarding the discussion about removing "auth-server-url-for-backend-requests"
>> I do understand why that was made.
>> The main problem that we are facing right now is that solving those
>> issues with DNS will work for most of the cases but not
>> for environments such as docker compose and minikube, where the
>> token verification is done comparing Strings and those strings contains
>> hosts and ports all together.
>>
>> I good idea might be to add more flexibility to that verification, where
>> we can compare that the host is the same but ports might be different. DNS
>> resolution will work out the names but not the ports.
>>
>> Regarding a Reverse proxy, we are looking into it.
>>
>> On Thu, Sep 7, 2017 at 1:42 PM, Sebastien Blanc <sblanc at redhat.com>
>> wrote:
>>
>>> Here is the discussion on why "auth-server-url-for-backend-requests"
>>> was removed : http://lists.jboss.org/piperma
>>> il/keycloak-dev/2016-March/006783.html
>>>
>>> Can't you use a Reverse Proxy ? TBH I don't master enough this subject
>>> and would liek to hear the opinions from the community on this subject.
>>>
>>> On Thu, Sep 7, 2017 at 12:35 PM, Mauricio Salatino <salaboy at gmail.com>
>>> wrote:
>>>
>>>> Because I failed to mention that I'm using the Spring Boot Adapter, I'm
>>>> wondering now if we need something like this:
>>>> "auth-server-url-for-backend-requests"
>>>>
>>>> ->
>>>> https://github.com/keycloak/keycloak/search?utf8=✓&q=auth-se
>>>> rver-url-for-backend-requests&type=
>>>>
>>>> Or if it was deprecated or not recommeneded to use.
>>>>
>>>>
>>>>
>>>> On Thu, Sep 7, 2017 at 11:14 AM, Mauricio Salatino <salaboy at gmail.com>
>>>> wrote:
>>>>
>>>> > Hi everyone,
>>>> > We using Keycloak behind a gateway (Zuul) and we are having issues
>>>> with
>>>> > keycloak adapters not being able to validate the JWT token issued on
>>>> behalf
>>>> > of an external client. Our Gateway is forwarding all the X-FORWARDED-*
>>>> > headers correctly so the token is issued correctly but the problem is
>>>> that
>>>> > our adapters (in our services) contains the following configuration:
>>>> >
>>>> > keycloak.auth-server-url=*<local ip of keycloak server>:<port>/auth*
>>>> >
>>>> > Now the problem that we are facing is that the token will not be able
>>>> to
>>>> > be validated by the adapter, because it was issued for the external
>>>> IP and
>>>> > the adapter is pointing to the local ip, so the token validation
>>>> fails.
>>>> >
>>>> > I've seen several threads and jira issues about this problem without a
>>>> > clear solution and it sounds like the adapter's code can be easily
>>>> extended
>>>> > to support this scenario. Now the question is where that information
>>>> should
>>>> > live:
>>>> > 1) It can be set to the realm configuration so the adapter picks that
>>>> up
>>>> > on start up and then use that information for the token validation
>>>> > 2) I can be picked up by the service that is getting the external IP
>>>> in
>>>> > the X-FORWARDED-* headers (this might cause a security issue ??? )
>>>> >
>>>> > We can provide the code for the solution but before start coding we
>>>> want
>>>> > to know what are your opinions on the matter and if this have been
>>>> solved
>>>> > before.
>>>> >
>>>> > Cheers
>>>> >
>>>> > Mauricio
>>>> >
>>>> >
>>>> > --
>>>> >  - MyJourney @ http://salaboy.com <http://salaboy.wordpress.com>
>>>> >  - Co-Founder @ http://www.jugargentina.org
>>>> >  - Co-Founder @ http://www.jbug.com.ar
>>>> >
>>>> >  - Salatino "Salaboy" Mauricio -
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>>  - MyJourney @ http://salaboy.com <http://salaboy.wordpress.com>
>>>>  - Co-Founder @ http://www.jugargentina.org
>>>>  - Co-Founder @ http://www.jbug.com.ar
>>>>
>>>>  - Salatino "Salaboy" Mauricio -
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>
>>>
>>
>>
>> --
>>  - MyJourney @ http://salaboy.com <http://salaboy.wordpress.com>
>>  - Co-Founder @ http://www.jugargentina.org
>>  - Co-Founder @ http://www.jbug.com.ar
>>
>>  - Salatino "Salaboy" Mauricio -
>>
>
>
>
> --
>  - MyJourney @ http://salaboy.com <http://salaboy.wordpress.com>
>  - Co-Founder @ http://www.jugargentina.org
>  - Co-Founder @ http://www.jbug.com.ar
>
>  - Salatino "Salaboy" Mauricio -
>

--
 - MyJourney @ http://salaboy.com <http://salaboy.wordpress.com>
 - Co-Founder @ http://www.jugargentina.org
 - Co-Founder @ http://www.jbug.com.ar

 - Salatino "Salaboy" Mauricio -
_______________________________________________
keycloak-user mailing list
keycloak-user at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user