Hostname SPI

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

In standalone.xml it would look like this:

<spi name="baseURL">
    <default-provider>request</default-provider>
    <provider name="fixed">
       <properties>
         <property name="hostname" value="localhost"/>
         <property name="httpPort" value="-1"/>
         <property name="httpsPort" value="-1"/>
       </properties>
   </provider>
</spi>

For production the default-provider should be changed to fixed and the hostname value should be changed. This can be handled either through manual editing standalone.xml or with jboss-cli. If allowRealmOverride is set to true it should be possible to configure a base url for a realm that will override the global base url.

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.