Re: [keycloak-dev] Keycloak URL and backchannel requests

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