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(a)redhat.com>
wrote:
On Thu, 18 Jul 2019 at 22:24, Luke McDougall <luke.mcdougall(a)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(a)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(a)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(a)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(a)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(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>