authelia/config.minimal.yml
Philipp Rintz 326a763343
Changed example file location for users_database
If using Docker as a medium for Authelia, having both the storage and users_database in one directory is preferable due to only one volume being needed. /etc/authelia cant be this directory, since there are other files in there, hence the subdirectory.
2018-10-12 07:39:04 +02:00

171 lines
5.8 KiB
YAML

###############################################################
# Authelia minimal configuration #
###############################################################
authentication_backend:
file:
# The path to the database file. The file is at the root of the repo.
path: /etc/authelia/volume/users_database.yml
session:
# The secret to encrypt the session cookies with.
secret: unsecure_session_secret
# The domain to protect.
# Note: Authelia must also be served by that domain.
domain: example.com
# Configuration of the storage backend used to store data and secrets.
# i.e 2FA data
# You must use only an available configuration: local, mongo
storage:
# The directory where the DB files will be saved
local:
path: /etc/authelia/volume
# TOTP Issuer Name
#
# This will be the issuer name displayed in Google Authenticator
# See: https://github.com/google/google-authenticator/wiki/Key-Uri-Format for more info on issuer names
totp:
issuer: example.com
# Authentication methods
#
# Authentication methods can be defined per subdomain.
# There are currently two available methods: "single_factor" and "two_factor"
#
# Note: by default a domain uses "two_factor" method.
#
# Note: 'per_subdomain_methods' is a dictionary where keys must be subdomains and
# values must be one of the two possible methods.
#
# Note: 'per_subdomain_methods' is optional.
#
# Note: authentication_methods is optional. If it is not set all sub-domains
# are protected by two factors.
authentication_methods:
default_method: two_factor
per_subdomain_methods:
single_factor.example.com: single_factor
# Access Control
#
# Access control is a set of rules you can use to restrict user access to certain
# resources.
# Any (apply to anyone), per-user or per-group rules can be defined.
#
# If 'access_control' is not defined, ACL rules are disabled and the `allow` default
# policy is applied, i.e., access is allowed to anyone. Otherwise restrictions follow
# the rules defined.
#
# Note: One can use the wildcard * to match any subdomain.
# It must stand at the beginning of the pattern. (example: *.mydomain.com)
#
# Note: You must put the pattern in simple quotes when using the wildcard for the YAML
# to be syntaxically correct.
#
# Definition: A `rule` is an object with the following keys: `domain`, `policy`
# and `resources`.
# - `domain` defines which domain or set of domains the rule applies to.
# - `policy` is the policy to apply to resources. It must be either `allow` or `deny`.
# - `resources` is a list of regular expressions that matches a set of resources to
# apply the policy to.
#
# Note: Rules follow an order of priority defined as follows:
# In each category (`any`, `groups`, `users`), the latest rules have the highest
# priority. In other words, it means that if a given resource matches two rules in the
# same category, the latest one overrides the first one.
# Each category has also its own priority. That is, `users` has the highest priority, then
# `groups` and `any` has the lowest priority. It means if two rules in different categories
# match a given resource, the one in the category with the highest priority overrides the
# other one.
#
access_control:
# Default policy can either be `allow` or `deny`.
# It is the policy applied to any resource if it has not been overriden
# in the `any`, `groups` or `users` category.
default_policy: deny
groups:
admins:
# All resources in all domains
- domain: '*.example.com'
policy: allow
# Except mx2.mail.example.com (it restricts the first rule)
#- domain: 'mx2.mail.example.com'
# policy: deny
# User-based rules. The key is a user name and the value
# is a list of rules.
users:
john:
- domain: dev.example.com
policy: allow
resources:
- '^/users/john/.*$'
harry:
- domain: dev.example.com
policy: allow
resources:
- '^/users/harry/.*$'
bob:
- domain: '*.mail.example.com'
policy: allow
- domain: 'dev.example.com'
policy: allow
resources:
- '^/users/bob/.*$'
# Configuration of the authentication regulation mechanism.
#
# This mechanism prevents attackers from brute forcing the first factor.
# It bans the user if too many attempts are done in a short period of
# time.
regulation:
# The number of failed login attempts before user is banned.
# Set it to 0 to disable regulation.
max_retries: 3
# The time range during which the user can attempt login before being banned.
# The user is banned if the authenticaction failed `max_retries` times in a `find_time` seconds window.
find_time: 120
# The length of time before a banned user can login again.
ban_time: 300
# Default redirection URL
#
# If user tries to authenticate without any referer, Authelia
# does not know where to redirect the user to at the end of the
# authentication process.
# This parameter allows you to specify the default redirection
# URL Authelia will use in such a case.
#
# Note: this parameter is optional. If not provided, user won't
# be redirected upon successful authentication.
#default_redirection_url: https://authelia.example.domain
notifier:
# For testing purpose, notifications can be sent in a file
## filesystem:
## filename: /tmp/authelia/notification.txt
# Use your email account to send the notifications. You can use an app password.
# List of valid services can be found here: https://nodemailer.com/smtp/well-known/
## email:
## username: user@example.com
## password: yourpassword
## sender: admin@example.com
## service: gmail
# Use a SMTP server for sending notifications
# Use a SMTP server for sending notifications
smtp:
username: test
password: password
secure: false
host: 'smtp'
port: 1025
sender: admin@example.com