[keycloak-dev] Keycloak URL and backchannel requests

[Stian Thorgersen]

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
>>>
>>