Rules

Understanding Rules

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.

########## EXAMPLE RULES #############

access_control:
  default_policy: deny
  rules:
    ## bypass rule
    - domain: 
        - "auth.domain.com"
      policy: bypass
    ## bypass api / triggers
    - domain: "*.domain.com"
      resources:
        - "^/api([/?].*)?$"
        - "^/identity.*$"
        - "^/triggers.*$"
        - "^/meshagents.*$"
        - "^/meshsettings.*$"
        - "^/agent.*$"
        - "^/control.*$"
        - "^/meshrelay.*$"
        - "^/wl.*$"
      policy: bypass
    ## block admin
    - domain: "bitwarden.domain.com"
      resources:
        - "^*/admin.*$"
      policy: one_factor
    ## bypass rule
    - domain:
        - "bitwarden.domain.com"
      policy: bypass
    ## two factor login - admin
    - domain: 
        - "proxy.domain.com"
        - "ipa.domain.com"
        - "opn.domain.com"
      subject: 
        - "group:admins"
      policy: two_factor
    ## one factor login - moderators
    - domain:
        - "sonarr.domain.com"
        - "radarr.domain.com"
        - "nzbhydra.domain.com"
        - "sabnzbd.domain.com"
        - "torrent.domain.com"
        - "domain.com"
      subject: 
        - "group:moderators"
        - "group:admins"
      policy: one_factor
    ## one factor login - requesters
    - domain:
        - "petio.domain.com"
        - "overseerr.domain.com"
      subject: 
        - "group:requesters"
        - "group:admins"
      policy: one_factor
    ## one factor login - catch all 
    - domain: "*.domain.com"
      subject: 
        - "group:admins"
      policy: one_factor

Bypass for APIs

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:

1. We want to protect sonarr.domain.com with Authelia

2. 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):

    ## bypass api / triggers
    - domain: "*.domain.com"
      resources:
        - "^/api([/?].*)?$"
      policy: bypass

Again, remember the hierarchy. We want the bypass to be above any restrictive rules so that Authelia knows that bypassing this endpoint comes first.