[keycloak-dev] Supporting multiple front-end channels (KEYCLOAK-6073)

Fri Jul 19 08:47:26 EDT 2019

Ok, I'll give that a try thanks.

Would you be interested in an enhancement to the adapter which allows
configuring a list of valid issuer URLs through the keycloak.json file so
that this same behaviour can be achieved without using a custom
KeycloakConfigResolver?  We could probably provide this.

Also, I noticed I should have been doing reply-all, so I've added
keycloak-dev back to the 'cc' list.

Luke

On Fri, Jul 19, 2019 at 3:52 AM Stian Thorgersen <sthorger at redhat.com>
wrote:

>
>
> On Thu, 18 Jul 2019 at 22:24, Luke McDougall <luke.mcdougall at gmail.com>
> wrote:
>
>> Hi...thanks for continuing to help me with this.  I didn't know there was
>> a way to do this with existing functionality.  Here's what I think you're
>> suggesting:
>>
>>
>> SERVER SIDE
>>
>> Currently we're using the default 'Request' hostname provider.  I know
>> this is not recommended, but if I understand this properly then it will
>> work without any changes.  But we should either (a) setup an undertow
>> filter to prevent invalid hostnames, or (b) develop a custom hostname
>> provider that will make sure only valid hostnames are used.
>>
>>
>> CLIENT SIDE
>>
>> On the backend services, where the Keycloak adapter is used, I would
>> implement a KeycloakConfigResolver as described here:
>> https://www.keycloak.org/docs/latest/securing_apps/index.html#_multi_tenancy
>>
>> This resolver would:
>>
>>    1. determine which URL the client used when acquiring the JWT token
>>    (i.e., determine the token issuer).  This can be determined by (a) looking
>>    at the issuer in the token itself or (b) by looking at the Host header used
>>    to reach the backend server.
>>    2. if the issuer from step 1 is valid, the resolver would return a
>>    KeycloakDeployment with realmInfoUrl set to the appropriate issuer URL
>>
>> This would allow the token to pass the TokenVerifier.RealmUrlCheck test.
>>
>> And I would also need the changes in the PR submitted by Luca Graf to
>> KEYCLOAK-6073 which allows specifying a back-channel URL by which the
>> adapter would contact the Keycloak server.  This is required because the
>> URL used by clients (e.g., external.myapp.net) may not be resolvable
>> from the backend service.
>>
>>
>> Does that sound right?
>>
>
> Yes, that should do the trick
>
>
>>
>>
>> Luke
>>
>>
>>
>>
>> On Thu, Jul 18, 2019 at 8:49 AM Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> You can still achieve that by having a custom hostname provider to allow
>>> both 'loadbalancer.intra.myapp.net' and 'external.myapp.net'. Then on
>>> the client side you can use multi-tenancy to allow the adapters to accept
>>> tokens both from 'loadbalancer.intra.myapp.net' and 'external.myapp.net
>>> '.
>>>
>>> On Wed, 17 Jul 2019 at 17:33, Luke McDougall <luke.mcdougall at gmail.com>
>>> wrote:
>>>
>>>> Hi... there's still some misunderstanding of the situation I'm
>>>> describing so I'll try to clarify.
>>>>
>>>> We do not use multi-tenancy.  Each customer has their own Kubernetes
>>>> cluster running in their own private data center.  Keycloak and our product
>>>> microservices are running in the Kubernetes cluster.  There is only one
>>>> Keycloak realm.
>>>>
>>>> A customer has multiple users who may need to access the Kubernetes
>>>> cluster through different DNS names. For example on-site users point their
>>>> browsers at loadbalancer.intra.myapp.net, but off-site users point
>>>> their browsers at external.myapp.net.  Both sets of users are
>>>> connecting to the same Kubernetes cluster and same Keycloak realm but end
>>>> of with different 'issuers' in the JWT token.
>>>>
>>>> We need a way for our backend services that use the keycloak adapter to
>>>> accept both 'loadbalancer.intra.myapp.net' and 'external.myapp.net' as
>>>> valid issuers.
>>>>
>>>> I'm not sure this is a corner case as we've had requirements like this
>>>> from multiple customers.
>>>>
>>>> Thanks...
>>>>
>>>>
>>>> Luke
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Jul 17, 2019 at 9:46 AM Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> As I mentioned this is unrelated and out of scope of KEYCLOAK-6073.
>>>>> That issue is simply about allowing adapters to communicate with Keycloak
>>>>> using an internal IP, rather than with the public URL. In cases where the
>>>>> application and Keycloak is on the same internal network. As such this
>>>>> should not hold up that work.
>>>>>
>>>>> I believe this is a corner case and not a common scenario so it may
>>>>> not be something we want to support directly, but rather something we
>>>>> should find some way for you to achieve.
>>>>>
>>>>> I don't fully understand your issue though as say you have two
>>>>> customers:
>>>>>
>>>>> * Customer A uses keycloak.customerA.com, app.customerA.com,
>>>>> service.customerA.com, etc
>>>>> * Customer B uses keycloak.customerB.com, app.customerB.com,
>>>>> service.customerB.com, etc
>>>>>
>>>>> In that case you could use the multi-tenancy support in the adapters
>>>>> to provide different frontend/backend URLs for Keycloak depending on the
>>>>> incoming request. If it's app.customerA.com, then it's
>>>>> keycloak.customerA.com, etc.. You would also need to have a custom
>>>>> hostname provider for Keycloak.
>>>>>
>>>>> I assume you have different realms as well for the different
>>>>> customers? If so you have different token issuers regardless right? Also,
>>>>> you are probably already using the multi-tenancy option or have different
>>>>> instances of the apps/services per-customer?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, 17 Jul 2019 at 15:00, Luke McDougall <luke.mcdougall at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi...  I'd like to continue a discussion regarding supporting multiple
>>>>>> public realm URLs that was started on
>>>>>> https://issues.jboss.org/browse/KEYCLOAK-6073.
>>>>>>
>>>>>> We are using Keycloak to support single-sign on to our suite of
>>>>>> products.
>>>>>> Our products run in a Kubernetes cluster; we deploy a Kubernetes
>>>>>> cluster
>>>>>> into our customers data centers to host our products.  The products
>>>>>> consist
>>>>>> of microservices built on Widlfy, NGINX, Spring Boot, and others.  We
>>>>>> use
>>>>>> NGINX ingress controllers as the entry point into the cluster.
>>>>>>
>>>>>> Users may access the products through multiple DNS names and/or IP
>>>>>> addresses; this is driven by each customers requirements.  For
>>>>>> example,
>>>>>> regular customer employees may access the cluster using a
>>>>>> loadbalancer DNS
>>>>>> name while external contractors may need to connect via a VPN and are
>>>>>> required to use a different DNS name (maybe to a different
>>>>>> loadbalancer).
>>>>>> In other cases multiple IP (or VIP) addresses are used.  All users are
>>>>>> logging into the same Keycloak realm.
>>>>>>
>>>>>> The result is that the 'issuer' in the JWT tokens is different
>>>>>> depending on
>>>>>> how the user is required to access the cluster; we need the Keycloak
>>>>>> adapter in our backend services to accept each of these possible
>>>>>> issuers.
>>>>>>
>>>>>> We have developed proof-of-concept changes in the Keycloak adapter to
>>>>>> solve
>>>>>> this by allowing us to specify a list of valid realm URLs in the
>>>>>> keycloak.json file used by the adapter.  Our intent was to submit
>>>>>> this as a
>>>>>> pull request for KEYCLOAK-6073.  However at the same time as we were
>>>>>> working on this, someone else submitted a pull request against
>>>>>> KEYCLOAK-6073 to support a single frontend and a single backend URL.
>>>>>>
>>>>>> I commented on the JIRA issue asking whether we could enhance this PR
>>>>>> allow
>>>>>> multiple frontend channels.  I'm concerned that if this PR is merged
>>>>>> without supporting multiple frontend channels that it will be more
>>>>>> difficult to add this afterwards.  However at Stian Thorgersen's
>>>>>> request I
>>>>>> have moved the conversation off JIRA and onto the mailing list.
>>>>>>
>>>>>> What do you think?  Is there any reason Keycloak shouldn't support
>>>>>> multiple
>>>>>> frontend channels?  We have customers that are very strict about
>>>>>> separating
>>>>>> client access as described above, and I'm not sure how else we could
>>>>>> support this with Keycloak.
>>>>>>
>>>>>> Thanks...
>>>>>>
>>>>>>
>>>>>> Luke
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>