4:31 p.m.
Hello everyone!
I'm trying to develop a very simple filter for an application to exchange
the user token with keycloak for another one with different scopes and I'm
in trouble with the issuer not matching.
Both the filter and keycloak are deployed in docker containers and connect
directly to each other.
The user authenticating into this application does it through a public
website, e.g. https://sample.com so the issuer in the token will look
something like https://sample.com/auth/realm or similar given the current
implementation.
The filter exchanging the token connects to keycloak through http, e.g.
http://my-keycloak the issuer would normally look like
http://my-keycloak/auth/realm, but because we are configuring the fixed
hostname provider to be sample.com it actually looks like
http://sample.com/auth/realm <https://sample.com/auth/realm>;, so it's
pretty close but it's http instead of https because the hostname SPI
introduced in KEYCLOAK-7967
<https://issues.jboss.org/browse/KEYCLOAK-7967> doesn't
support a fixed schema (as far as I could tell at least by looking at the
PR and configs). And because that's being used to validate the token, and
there's no way I'm aware of setting the schema I haven't been able to get
it running properly.
Is there any known solution to this limitation?
My take is that schema should be supported by the fixed hostname provider,
otherwise I think it misses the point of supporting a "backchannel URL back
to the adapters to allow adapters to use internal IP address when
communicating with Keycloak"
On top of that, I believe there's a confusion on what the issuer is;
As per RFC-7519:4.1.1 <https://tools.ietf.org/html/rfc7519#section-4>
The "iss" (issuer) claim identifies the principal that issued the
JWT. The processing of this claim is generally application specific.
The "iss" value is a case-sensitive string containing a StringOrURI
value. Use of this claim is OPTIONAL.
i.e. not a URL and certainly not necessarily linked to the URL of the
issuing system, it's just a URI value defined arbitrarily. I believe
that this concept is more closely related to realm application clients
rather than to the entire keycloak server; i.e. issuer/accepted
issuers could be defined per client.
Because of this I've taken the liberty to raise KEYCLOAK-8310
<https://issues.jboss.org/browse/KEYCLOAK-8310>
Still, is there any known/recommended way to workaround this issue?
Thanks for your time,
Fernando.