On Mon, Jul 30, 2018 at 1:05 PM Stian Thorgersen <sthorger(a)redhat.com&gt; 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)).

> > 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >

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(a)redhat.com&gt; wrote: > > > On Mon, 30 Jul 2018 at 13:28, Sebastian Laskawiec <slaskawi(a)redhat.com&gt; > wrote: > >> >> >> On Mon, Jul 30, 2018 at 1:05 PM Stian Thorgersen <sthorger(a)redhat.com&gt; >> 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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(a)kodet.no&gt; 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(a)redhat.com&gt; > 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(a)redhat.com&gt; > > wrote: > > > >> > >> > >> On Mon, 30 Jul 2018 at 13:28, Sebastian Laskawiec <slaskawi(a)redhat.com&gt; > >> wrote: > >> > >>> > >>> > >>> On Mon, Jul 30, 2018 at 1:05 PM Stian Thorgersen <sthorger(a)redhat.com&gt; > >>> 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(a)lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>> > >>> > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev