Hi Jonathan, This is not only a development issue. Anyone running in NAT'd environments and/or more complex network setups will face this. I raised the same issue few days ago (http://lists.jboss.org/ pipermail/keycloak-user/2017-May/010788.html) and there is plenty of previous post highlighting the issue dating even few years back. I even offered myself to implement whatever changes are necessary to Keycloak adapters since this is an important feature for one of my clients. Unfortunately, it doesn't seem that the Keycloak maintainers/community really care about this issue or have any intention of doing something about it :/ Regards, -- *Juanjo Díaz* Software Architect @Intopalo Oy <https://intopalo.com> +358 50 4667571 <+358+50+4667571> | juanjo.diaz(a)intopalo.com On 3 June 2017 at 07:25, Jonathan Little <rationull(a)gmail.com&gt; wrote: > I'm trying to set up a devel environment with Keycloak in a Docker > container, a back-end service in a separate linked Docker container, and a > front end web app that authenticates against Keycloak and then uses a > bearer token with the back end service. Bearer token validation is failing > in this case due to the JWT's iss field not matching the realm URL: the > realm URL is based on a hostname in the Docker network but the login > occurred against localhost from the browser running outside Docker via a > host port mapping. > > This is obviously a devel specific scenario and I'd like to be able to opt > in to multiple allowed issuers, an issuer regex, skipping issuer > verification, or some other workaround. AFAIKT there is no mechanism for > this and the options are: > > 1) Add an entry to the devel machine's hosts file so that the browser can > use the same hostname as the Keycloak container has in the Docker network. > This is simple but undesirable because I'd rather not have to globally > modify the devel machine configuration for this. > > 2) Run the devel Keycloak server outside of Docker at a known externally > accessible hostname. This is potentially the cleanest solution (although > it > may have redirect issues with locally hosted devel websites -- I haven't > tried yet) but I'd really like to be able to run Keycloak locally. > > 3) Somehow hack or customize the token validation code. The issuer check > is > fairly deep and I don't see any convenient or palatable hacks though. > > > This seems to me like it'd be a common situation but is it legitimate or > am > I thinking about this wrong? Does anyone else have any ideas or think this > would be a worthwhile addition to the library? Seems to me that multiple > issuers or an issuer regex would be clean solutions. > > If this makes sense I will file a feature request (not sure if PRs are > accepted on this project), but it seems like such an ordinary situation > that I feel like I must be missing something! > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user >