[keycloak-dev] Keycloak URL and backchannel requests

Tue Jul 31 06:08:35 EDT 2018

I assume you're creating the initial access token when logged-in to the
master realm right? Will add a testcase for that specifically and fix it.
Probably just need to change the realm in the KeycloakContext when creating
the token.

On Tue, 31 Jul 2018 at 10:59, Johannes Knutsen <johannes at kodet.no> wrote:

> Just tested this branch. This seems like a good change.
> However, I have an issue when creating an Initial Access Token in a
> realm configured with a fixed hostname different from the hostname
> used when accessing the admin console. The resulting initial access
> token gets the request hostname as issuer and not the fixed hostname
> configured for the realm. I expected the issuer to have the same
> hostname as the fixed realm configuration.
>
> - Johannes
>
> On Mon, Jul 30, 2018 at 10:56 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
> > I've got a working prototype now. If anyone wants to take a look and
> review
> > that would be great. It's mainly missing tests at the moment.
> >
> > https://github.com/stianst/keycloak/tree/KEYCLOAK-7967
> >
> > Some implementation details:
> >
> > * There's two providers: request (current Keycloak behaviour) and fixed
> > * When 'fixed' provider is selected the admin console will let you set a
> > hostname for a realm
> > * 'fixed' provider by default uses http and https port -1. This will
> result
> > in no ports in the URLs. If for some reason you need to set different
> than
> > default http/https ports for public URLs then you can set the
> > httpPort/httpsPort properties on the fixed provider (this can't be
> > overridden per realm)
> >
> > Now I need to figure out how to test it, which is going to be a bit
> tricky
> > as we don't have support to restart the server from the tests at the
> moment.
> >
> >
> > On Mon, 30 Jul 2018 at 13:51, Stian Thorgersen <sthorger at redhat.com>
> wrote:
> >
> >>
> >>
> >> On Mon, 30 Jul 2018 at 13:28, Sebastian Laskawiec <slaskawi at redhat.com>
> >> wrote:
> >>
> >>>
> >>>
> >>> On Mon, Jul 30, 2018 at 1:05 PM Stian Thorgersen <sthorger at redhat.com>
> >>> wrote:
> >>>
> >>>> Keycloak needs to know its public URL for a number of reasons. For
> >>>> example
> >>>> in the OIDC well-known endpoint, issuer in tokens and emails sent to
> >>>> users.
> >>>>
> >>>> At the moment we retrieve this from the request headers and have
> >>>> documented
> >>>> how to block requests with invalid URLs (
> >>>> https://www.keycloak.org/docs/latest/server_admin/index.html#host).
> The
> >>>> latter is important in production installations.
> >>>>
> >>>> There's two problems with the current approach:
> >>>>
> >>>> 1) Clients in the same subnet can't use internal IP to communicate
> with
> >>>> Keycloak
> >>>> 2) Configuring the valid URLs is an important step to secure a
> production
> >>>> installation, but the current approach is probably not well known and
> is
> >>>> rather messy to configure
> >>>
> >>>
> >>>> I propose we introduce an BaseURL SPI to allow a flexible way to
> >>>> determine
> >>>> the base URL. We would add two implementations OOTB:
> >>>>
> >>>> 1) Request - this would be set as the default-provider and would
> >>>> determine
> >>>> the base url from request headers as we do today
> >>>> 2) Fixed - this would allow setting a hardcoded public URL
> >>>>
> >>>
> >>> How about adding a third option - "None". This would mean the Keycloak
> >>> operates without a fixed public IP (the implementation could probably
> call
> >>> back into "localhost:8080/auth" using a "Fixed" implementation).
> However,
> >>> with "None" we would be explicitly saying that there's no public IP
> and all
> >>> requests need to be local (e.g. from the same machine or Pod (sidecar
> >>> approach)).
> >>>
> >>
> >> Keycloak has to know what URL users should be accessing it on. That can
> be
> >> an internal URL or external URL, but Keycloak needs to know the actual
> URL.
> >> There's really no such thing as a Keycloak server only reached
> internally.
> >> Users needs to be able to login, they need links in password recovery
> >> emails, etc, etc.
> >>
> >>
> >>>
> >>>
> >>>>
> >>>> In standalone.xml it would look like this:
> >>>>
> >>>> <spi name="baseURL">
> >>>>     <default-provider>request</default-provider>
> >>>>     <provider name="fixed">
> >>>>        <properties>
> >>>>          <property name="baseURL" value="localhost:8080/auth"/>
> >>>>        </properties>
> >>>>    </provider>
> >>>> </spi>
> >>>>
> >>>> For production the default-provider should be changed to fixed and the
> >>>> baseURL value should be changed. This can be handled either through
> >>>> manual
> >>>> editing standalone.xml or with jboss-cli.
> >>>>
> >>>
> >>> How about using the "None" as the default here?
> >>>
> >>>
> >>>>
> >>>> Once this is incorporated it will make it easy to add support for
> >>>> backchannel URL back to the adapters to allow adapters to use
> internal IP
> >>>> address when communicating with Keycloak.
> >>>>
> >>>> Implementation shouldn't be hard. It's mainly about making sure that
> >>>> UriInfo is retrieved from KeycloakSession#KeycloakContext and not
> >>>> injected
> >>>> directly.
> >>>>
> >>>> If anyone has more complex requirements for determining the public URL
> >>>> they
> >>>> can implement their own provider to handle it.
> >>>>
> >>>> One thing I'm not sure about is if it's common to use different URLs
> for
> >>>> different realms. If that's the case we may consider adding some
> support
> >>>> for mapping different realms to different baseURLs. I don't think
> this is
> >>>> common though.
> >>>> _______________________________________________
> >>>> keycloak-dev mailing list
> >>>> keycloak-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>
> >>>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>