Last part should have left us, hopefully, with working database servers, caddy proxy and phpMyAdmin as a management tool for mariadb database.

Next step is to add authorization server as it is very important part of the infrastructure, so let’s add it. For that, we will need gitlab registry docker image(s) which brings us to next requirement: gitlab account. If you have that, you should login to gitlab docker registry:

docker login registry.gitlab.com --username <gitlab-username>

As usual, we are going to create external docker volume for authentication server:

docker volume create --label reco-authenticatomatic reco-authenticatomatic

Another requirement for authenticatomatic are two keys: encryption and signing. We can create them using Authenticatomatic.CLI tool or we may have them already prepared. If you have them - copy those two files to volume created above.

Being that we are using docker already, it may be of some interest to note that docker version of Authenticatomatic.CLI tool exists, and it may be fun way to test are we actually logged to the gitlab registry. To generate those keys, execute those two, very cumbersome, commands:

docker run --rm -v reco-authenticatomatic:/home registry.gitlab.com/tekelija/authenticatomatic/authenticatomatic-cli:latest cert signing -o /home/signing.pfx -y 10

docker run --rm -v reco-authenticatomatic:/home registry.gitlab.com/tekelija/authenticatomatic/authenticatomatic-cli:latest cert encryption -o /home/encryption.pfx -y 10

By some unknown sorcery, if everything goes without errors, you should have two .pfx files in reco-authenticatomatic docker volume: signing.pfx and encryption.pfx. Nice, ain’t it.

As requirements go, we have one just one more: persistance. Authenticatomatic needs some kind of database to store it’s data so we need to create one. Which one? We can use either of three supported (mysql, mssql or sqlite), and for this use case we will use mysql (as it is real database and we already have management tool installed). Without further ado, fire up mariadb.domain.com or whatever url you have set up, and create database named authenticatomatic

Now comes the fun part: update your compose.yml and Caddyfile as follows:

compose.yml:

 1volumes:
 2
 3  reco-caddy-data:
 4    external: true
 5  reco-caddy-config:
 6    external: true
 7  reco-mariadb:
 8    external: true
 9  reco-mssql:
10    external: true
11  reco-mongodb:
12    external: true
13  reco-authenticatomatic:
14    external: true
15
16services:

and service declaration:

69
70  authenticatomatic:
71    image: authenticatomatic:net7
72    environment:
73      - DATABASE__CONNECTIONSTRING=server=mariadb;database=authenticatomatic;username=root;password=pass;
74      - DATABASE__TYPE=mysql
75      - ENCRYPTION__PATH=/cert/encryption.pfx
76      - ENCRYPTION__PASSWORD=
77      - ENCRYPTION__CERTPEMFILEPATH=
78      - ENCRYPTION__KEYPEMFILEPATH=
79      - SIGNING__PATH=/cert/signing.pfx
80      - SIGNING__PASSWORD=
81      - SIGNING__CERTPEMFILEPATH=
82      - SIGNING__KEYPEMFILEPATH=
83      - SERILOG__MINIMUMLEVEL__DEFAULT=Debug
84      - ASPNETCORE_FORWARDEDHEADERS_ENABLED=true
85    volumes:
86      - reco-authenticatomatic:/cert:ro
87      - reco-authenticatomatic:/data:rw
88    depends_on:
89      - mariadb

Change database connection string in line 73 to suit your needs. Certificate specification is defined on lines 75, 79 and 86.

Caddyfile:

 1{
 2    auto_https disable_certs
 3}
 4
 5*.domain.com {
 6    tls /config/cert.pem /config/server.key
 7
 8    @mariadb host mariadb.domain.com
 9
10    handle @mariadb {
11        reverse_proxy phpmysqladmin:80
12    }
13
14    @authenticatomatic host authenticatomatic.domain.com
15
16    handle @authenticatomatic {
17        reverse_proxy authenticatomatic:80
18    }
19
20    handle {
21         respond "Hello world!"
22    }
23}

Added lines are 14 through 18, and they look almost exactly same as already existing @mariadb section. Well, it is almost exactly the same because it essentially does the same job, just different match and service for proxying to. Note that latest addition, authenticatomatic also has no exported ports. Caddy to the rescue, again.

One docker compose up -d will pull latest authenticatomatic image from gitlab container registry and start it. It may have take some time to start, as server will execute database migrations on first start. If in any kind of a problem, repeat. docker compose restart caddy should also come handy - every time that we have changed Caddyfile.

After all that, one authenticatomatic.domain.com in your browser should take you to the OpenIddict server landing page. If so - congratulations, that was the idea. If not - try checking docker compose ps to see what is running and what is not, and then use docker compose logs to find why it does not. Or use Docker Desktop gui tool to view logs and/or start/stop/restart containers.