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

Stian Thorgersen sthorger at redhat.com
Wed Jul 17 09:45:58 EDT 2019


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
>


More information about the keycloak-dev mailing list