We actually have clients reach keycloak through it's the internal address.
We use these for integration suff like client registration, user data
We haven't encountered any issues other than the one with introspection.
I'll look into undertow filters though.
On 8 March 2018 at 08:59, Stian Thorgersen <sthorger(a)redhat.com> wrote:
This is just one out of several issues you'll encounter if you
clients reaching Keycloak through an internal IP address.
I believe you can probably use Undertow filters to map the internal IP to
a fqdn so Keycloak will use the proper domain name regardless. That would
probably be the way we'd support this if/when we get around to doing it as
we need the ability to map an internal IP address to a domain name.
Keycloak always needs to know its domain name.
On 6 March 2018 at 19:59, Aron Bustya <aron.bustya.js(a)gmail.com> wrote:
> We are operating keycloak and an API gateway which protects our resource
> servers, the gateway uses the token introspection feature of keycloak to
> validate requests.
> Our problem is that keycloak only accepts introspection request when
> with the same fqdn as the token was issued for, so the gateway cannot call
> keycloak using its internal address.
> I know this is a 'solvable' problem, but solutions raise further
> and it would be simpler to just allow the introspection call without the
> url check.
> I see others have encountered the problem also:
> The RSATokenVerifier used for introspection actually has a checkRealmUrl
> setting, but it can't be influenced from any server configuration.
> So my question is: if I made the checkRealmUrl setting configurable using
> realm attribute or client attribute, would that be an acceptable feature
> for a pull request?
> Best regards,
> Áron Bustya
> keycloak-dev mailing list