The rules section in the Authelia configuration file have some important notes to consider:
Rules are read by Authelia from top to bottom
Therefore, you should practice putting the most restrictive rules last.
A catch-all wildcard rule at the very end will safeguard you by applying a default policy on anything you have enabled Authelia on, without needing a specific rule.
There may be times when you want to allow certain apps to be covered by single-factor authentication, and others to be covered by two-factor authentication.
You can specify the user, groups, or both that can access a particular resource.
You can restrict access to a particular subfolder of a URL rather than the entire URL. For example, if you want to protect the Admin page of an application but not the main page itself.
You may have a combination of all the above if you so choose.
For a more in-depth look at access control, please see the official Authelia docs here.
WARNING
Below you will find a comprehensive list to read through as an example. This is a valid and working example, however, we do not recommend blindly copying it without fully understanding what the rules are doing.
For a more in-depth look at access control, please see the official Authelia docs here.
In the above, you may notice that certain rules are allowing API endpoints. This is important when you want to protect an application that uses API communications to send and receive data and do not want it to be hindered by Authelia.
A classic example is Sonarr or Radarr. These applications need the API to talk to other applications and since they are unable to 'sign in' to Authelia themselves, we need to tell Authelia that:
We want to protect sonarr.domain.com with Authelia
However, we want to bypass Authelia for traffic coming in and out of the API endpoint of Sonarr
Here's how that would look (extracted from the example above):
Again, remember the hierarchy. We want the bypass to be above any restrictive rules so that Authelia knows that bypassing this endpoint comes first.