On Thu, 18 Jul 2019 at 22:24, Luke McDougall <luke.mcdougall(a)gmail.com&gt; 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&gt; > 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&gt; >> 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&gt; >>> 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&gt; >>>> 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 >>>>> >>>>