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

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