How does the network work when encapsulating a service with an SSO service(Single Sign On)?
While working on a service, I had to figure out how a service is mounted by Docker and get all its components together, including the internal and external network.
Problem: lack of understanding of what is happening under the hood in a protective service using Docker compose, Traefik, forward-auth and an internal Authenticator provider.
In this article, you will have explained how the network communicates(Client-server Model: check out this article by
), DNS entries, and port bindings within the Docker network and outside.
All happening under the hood to get a service on top to make your app secure.
Part One
Microsoft Azure App registration will open two ports; 443 for HTTPS and 80 to bind it to the service.
We will define the whole service using a docker.yml file and compose instead of the stack as the Docker method.
For this program, we will use 2 bash scripts to Start and Stop the service with their executing permissions for both .sh scripts:
- Command: chmod +x start.sh
One docker-compose.yml file to define the docker instructions.
And a directory to mount our volume(for example: volume-service; service etc…)
The setup could look like this:
On our server-side
Now, let’s get into our run.sh and stop.sh scripts.
Now, let’s get into our docker-compose.yml file. How would this look like?
Here’s an example:
docker-compose.yml file example
In our example, we take the traefik/whoami service for testing our OAuth and the whole network requesting a path.
When we make a GET request we will have a path, usually without any security on top there is only a request and a response, but this request can contain some Headers.
So let’s assume we want to protect our service using an OAuth provider, in this case, OAuth:2.
We would need to first in our docker.yml file define what version of it we are using and the entry for the provider Traefik and then complete all the necessary info from our Traefik configuration.
We have the structure of this file like this:
traefik configuration
Do not forget about the volume mounts, in our machine we should have the volume-traefik/letsencrypt directories created if not like my manager said:
“We would have a car without wheels”
So that is done, and the 443 port for HTTPS (secure network) and port 80 bind to Traefik.
So any requests coming to 443 and 8080 will be handled by Traefik.
Now, let’s have a look at our Traefik forwarded auth configuration:
traefik-forward-auth configuration
Here we are using an OIDC provider which can be Microsoft or Federate Identity provider.
In our example, we needed from the provider some variables, the issuer_url, client_id, client_secret, secret and for debugging the log_level set to debug.
Some notes: here’s how you can bind your local host to display the Dashboard on Traefik in your machine, and how you see the logs from any docker container to see what are requests made:
How do we get to see the Traefik dashboard associated with our service?
- Using SSH: ssh -L 8080:localhost:8080 user@IPAddress_service of the service (assuming you have in place an SSH connection with the service and your local machine)
Then go to localhost: localhost:8080/dashboard/# and you are set!
Displaying logs in Docker
Other helpful commands in docker:
docker ps
watch docker ps
docker logs -f container_sufix
For testing, you could use this command:
- docker run -it –rm -p 8089:80 traefik/whoami
The default port for binding inside the container traefik/whoami is 80 and the other is one port that is open in our app or service.
We are biding ports outside our service with the network that Docker forms once we put on containers inside a YML file.
Another command using the VIM editor: vim docker-compose.yml +71(to go to line 71 in our file directly).
Here are some notes that helped me work with Docker.
I hope it helps you too! 🤗