Authelia

Long time ago in a far far away galaxy, I have to use bunch of password. And now I don’t.

It was a dream, and later it comes as something that I can do, at least in scale of home environment. Quite obviously, solution should be simple, reliable and not consume every byte of my server’s memory.

Cloud solutions were out of scope, and only reasonable decision on first review was Keycloak. It’s good, even exist in the container, and fit for purpose, but configuration, integration with all my services seems to be quite boring task and very time consuming.

Next victim on the table become very nice and promising Authentik. At the very beginning it seems to be something that really could solve all the auth problems, but it appears to be a nice kiosk with all the links, but not a seamless SSO.

So, third shot is the lucky one, so I come across Authelia, that finally make it work. So, it makes really seamless authentication and authorization for internal services from inside and outside. Plus – 2FA for such services as radarr, sonarr and so on. And password reset also.

With AD backend or any other LDAP it’s possible to combine all the unprotected services with auth. Using this you can also perform password reset, that, eventually, works.

Multiple options of building DB backend also could be a cool option for someone who want to check. The only option, that should be avoided is the default one SQLite, that for sure will be a biggest issue on the later stages.

Long story short – that was something that I searched for.

Setup

As everything in the open-source world, it will be easy, if you brave enough. With docker-compose and power of all-mighty MySQL you will be able to set it up almost from the first attempt. The only thing that you should pay attention is configuration file, nginx configuration and mail service, as, without it, you won’t even able to start. Luckily, here is a couple of snippets, that can help you with this taught tasks:

Such not interesting tasks, as MySQL/Postgres/Maria I won’t explain, but it should be quite easy if you come to this part, as you already trying to setup SSO. This file should be placed during build. Here is the example of how it might looks like:

version: '3.3'
services:
  authelia:
    image: authelia/authelia:4.31
    volumes:
      - /storage/authila/config:/config
    ports:
      - 8101:9000
    restart: unless-stopped
    healthcheck:
      disable: true
    environment:
      - TZ=Europe/Berlin
    depends_on:
      - redis
    networks:
      authelia:
        ipv4_address: 172.100.0.3

  redis:
    image: redis:alpine
    volumes:
      - /storage/authila/redis:/data
    expose:
      - 6379
    restart: unless-stopped
    environment:
      - TZ=Europe/Berlin
    networks:
      authelia:
        ipv4_address: 172.100.0.2
networks:
  authelia:
    driver: bridge
    ipam:
     config:
       - subnet: 172.100.0.0/16

This configuration example is quite comprehensive and here you can see 3 different scenarios of usage:

• Quite straight-forward, if the application fully support it, or, you don’t care about granular access, you just set it up access on Nginx and it works. Such examples, is radarr, sonarr, lidarr, prowlarr and other arr’s.
• Second option – is usage of OIDC, this will integrate with applications and require additional configuration on application side, at the end of config file you can find couple of such examples – Nextcloud and Grafana. Unfortunately, Nextcloud is quite glitching with this config, as it not able to associate OIDC user with existing one, from LDAP, for example.
• Last, but not least option – is usage of header Remote-User. This is less secure option, but it still will be useful with applications, that not support any other options: Calibre-Web, Firefly, and Home Assistant.

After this moment of time Authelia itself should work, but obviously, it seems to be useless without proper configuration of the Nginx.

Nginx

With Nginx it’s quite easy to deal – you need to configure server and client parts to let all participants know about cookies, tokens and how to deal with them all.

Below you can find example of configuration, that might be useful in this case:

Here you need to understand how they referring with each other – sso.conf is configuration for the Authelia web, so, it’s proxing to proper sso container, site.conf – it’s an example of file, that should be protected with 2 references to auth-domain.conf and to auth.conf.

It depends how did you organize you nginx configuration files, so, if you want you can embed it in one huge file, or, as I do, use sever small, but it should be reachable by the relative or absolute path.

Conclusion

Configuration in general quite straight-forward, but, for some cases it might be not obvious how it might works, or, it could be some tiny things. Assuming, that we going to do it for open-source home-brewed applications – it will be plenty of such applications.

One funny story – during implementation of Home Assistant SSO I come across some issue in the middle – application didn’t get auth requests, and Authelia could not find resource. And the root cause was quite funny – module of HA using “auth” as initial part of path and in nginx config it was the same, so, just changing nginx config to something different, like “autho” fixed it.

This example should force you to expect unexpected.

Another point, is that you can do your own SSO and not provide your data to

References

During preparation and attempts to implement original Authelia documentation was really useful – https://www.authelia.com/configuration/prologue/introduction/ . For some examples like HA, this guy was really helpful. Also, github – is really helpful in getting different options and ideas.