[keycloak-dev] Keycloak URL and backchannel requests

Tue Jul 31 06:26:27 EDT 2018

Yes, I was logged-in to the master realm when testing this.

On Tue, Jul 31, 2018 at 12:08 PM, Stian Thorgersen <sthorger at redhat.com> wrote:
> 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