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