IdentityServer4 - Different behavior from docker-compose than manual run - docker

Question

I have three different projects in .net core 3.1 :
STS
Admin UI
Admin API
I have a dockerfile by project which are building my images well.
If I run my containers manually with these commands everything is ok :
docker run -e "ASPNETCORE_ENVIRONMENT=Development" -e "ASPNETCORE_URLS=http://+:80" -e "DOTNET_USE_POLLING_FILE_WATCHER=1" -p 5001:80 stsidentity:latest
docker run -e "ASPNETCORE_ENVIRONMENT=Development" -e "ASPNETCORE_URLS=http://+:80" -e "DOTNET_USE_POLLING_FILE_WATCHER=1" -p 5003:80 adminapi:latest
docker run -e "ASPNETCORE_ENVIRONMENT=Development" -e "ASPNETCORE_URLS=http://+:80" -e "DOTNET_USE_POLLING_FILE_WATCHER=1" -p 9001:80 admin:latest
My next step was to create a docker-compose to automatized it but I have some issues.
From Visual Studio, when I execute the docker-compose below, containers sts and api are working well.
When I try to access my Admin UI I have an error "InvalidOperationException: IDX20803: Unable to obtain configuration from: 'http://localhost:5001/.well-known/openid-configuration'."
If manually I copy/paste that Url in my browser I can access it normally.
I don't understand why a different behavior between the docker-compose and when I run containers manually from the same images.
version: "3.4"
services:
admin:
image: ${DOCKER_REGISTRY-}admin:latest
ports:
- "9001:80"
build:
context: .
dockerfile: src/IdentityServer/Admin/Dockerfile
container_name: IS4-admin
environment:
- ASPNETCORE_ENVIRONMENT=Development
- ASPNETCORE_URLS=http://+:80
- DOTNET_USE_POLLING_FILE_WATCHER=1
depends_on:
- sts.identity
- admin.api
admin.api:
image: ${DOCKER_REGISTRY-}admin-api:latest
ports:
- "5003:80"
build:
context: .
dockerfile: src/IdentityServer/Admin.Api/Dockerfile
container_name: IS4-admin-api
environment:
- ASPNETCORE_ENVIRONMENT=Development
- ASPNETCORE_URLS=http://+:80
- DOTNET_USE_POLLING_FILE_WATCHER=1
depends_on:
- sts.identity
sts.identity:
image: ${DOCKER_REGISTRY-}sts-identity:latest
ports:
- "5001:80"
build:
context: .
dockerfile: src/IdentityServer/STS.Identity/Dockerfile
container_name: IS4-sts-identity
environment:
- ASPNETCORE_ENVIRONMENT=Development
- ASPNETCORE_URLS=http://+:80
- DOTNET_USE_POLLING_FILE_WATCHER=1
It's probably something obvious but I don't see it.
--
-- Edit
--
I read it was a problem possibly related to localhost. So I tried to use a Traefik container as a reverse proxy and at the end I have the same issue.
I'm starting to think that my problem is maybe not related to containers but just with the fact to execute it in something different than my localhost on IISExpress.
From what I read on IdentityServer4 it could come from a problem with a certificate. I think I put everything in HTTP and I don't understand why I would have a problem with it in HTTP.
I succeed to obtain a more detailed error message :
IOException: IDX20807: Unable to retrieve document from: 'http://login.traefik.me/.well-known/openid-configuration'. HttpResponseMessage: 'StatusCode: 404, ReasonPhrase: 'Not Found', Version: 1.1, Content: System.Net.Http.HttpConnectionResponseContent, Headers:
{
Date: Wed, 08 Jul 2020 13:21:07 GMT
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Frame-Options: SameOrigin
Referrer-Policy: no-referrer
Content-Security-Policy: script-src 'self' 'unsafe-inline' 'unsafe-eval';style-src 'self' 'unsafe-inline' https://fonts.googleapis.com/ https://fonts.gstatic.com/;font-src 'self' https://fonts.googleapis.com/ https://fonts.gstatic.com/
Content-Length: 0
}', HttpResponseMessage.Content: ''.
Microsoft.IdentityModel.Protocols.HttpDocumentRetriever.GetDocumentAsync(string address, CancellationToken cancel)
InvalidOperationException: IDX20803: Unable to obtain configuration from: 'http://login.traefik.me/.well-known/openid-configuration'.
Microsoft.IdentityModel.Protocols.ConfigurationManager<T>.GetConfigurationAsync(CancellationToken cancel)
Thanks in advance,
Have a nice day

Answer 1

This is exactly the same than the one I was getting with my Docker Compose solution.
Here is a simplified overview of the solution:
Api
Admin
IdentityServer4
Traefik
I configured Traefik to forward requests on 'api.localhost' to the Api container, requests on 'admin.localhost' to be forwarded to the Admin container and request to 'identity.localhost' to be forwarded to the IdentityServer4 container.
Like you, request on both 'api.localhost', 'admin.localhost' and 'identity.localhost' are working fine in a browser.
The problem appears when I try to login on the Api or the Admin containers, because inter-container communication are not handled by Traefik. Furthermore, DNS such as '*.localhost' are handled in the container itself, for it is a loopback DNS, and is therefore not resolved as it should.
My solution to make it work as expected is the following:
STEP 1: Create a new network in your docker-compose file. That network is created to add your own subnet, and therefore specify a static IP for your Traefik container.
networks:
traefik:
ipam:
driver: default
config:
- subnet: 172.30.0.0/16 #replace by your desired subnet
STEP 2: Configure the Traefik container's static IP address:
networks:
default: #required to talk to containers
traefik:
ipv4_address: 127.30.1.1 #can be any address compatible with the subnet defined at step 1
STEP 3: Add the newly created network to all the containers that rely on IdentityServer4, and do not forget to add the 'default' network too. We will, in addition, create extra hosts corresponding to the DNS of our IdentityServer4 container, as configured in Traefik. Those additional hosts will point to the static IP address of the Traefik container.
admin:
image: ...
environment: ...
labels: ...
networks:
traefik:
default:
extra_hosts:
- "identity.localhost: 127.30.1.1 #replace by the configured traefik static address
At this point, if the Admin container tries to resolve the 'identity.localhost' DNS, it will be forwarded to Traefik, which in turn will redirect to the IdentityServer4 container: yaaai!
If you test it out, however, you will still run in a couple of issues, all related to HTTPS (which I strongly recommend you enable and configure)
Those issues are:
The SSL certificates you have configured in Traefik might not be trusted by your containers. If so, make sure to add the root CA (in case of self-signed certificates) in the container's '/etc/ssl/certs' directory.
To do so, you have to mount a volume, such as in the following example:
admin:
image: ...
environment: ...
labels: ...
networks:
traefik:
default:
extra_hosts:
- "identity.localhost: 127.30.1.1
volumes:
- "./localPathToMyCACertificateFiles/:/etc/ssl/certs/"
When Admin or Api containers will try to retrieve the well known configuration on the IdentityServer, it will probably complain that configuration endpoints are in http, instead of https. To fix this issue, you will need to configure forwarded headers for the IdentityServer4 containers and all containers relying on it. Check this out if you don't know how to do so. An important point is to make sure that 'RequireHeaderSymmetry' is set to false.
This should do the trick.