Configuration file

Structure

The configuration file contains several main sections, where each is responsible for a particular category of runtime behavior. A full example is shown at the end of this document.

Features

realtime_blackhole_lists
cleartext_networks
relay_domains
brute_force
lua
backend_server_monitoring

General configuration settings

server
csrf_secret
cookie_store_auth_key
cookie_store_encryption_key
oauth2
ldap
lua

Each section has individual subsections. See details below. If you do not require some sections, please do not include it into the configuration file.

Reloading

You can send a HUP-signal to Nauthilus, which will stop LDAP connections, reload the configuration file and restart the database connections. The main web server process will be still alive.

If you change settings deticated to the web server itself, you must first reload the configuration file and send a second signal -SIGUSR1 to restart the server process itself.

warning

Changing environment variables need a full restart of the service. Re-reading variables can not be done by sending signals.

server

Meaning

This section defines all required settings that are required to run the server.

server::address

Default: "127.0.0.1:9080"

This is the IPv4 or IPv6 addresses combined with a TCP port.

server:
  address: "[::]:9443"

server::haproxy_v2

Default: false

If this setting is turned on (true), Nauthilus can make use of the HAproxy version 2 protocol header to identify the original client request.

server:
  haproxy_v2: true

server::http3

Default: false

Enable HTTP/3 support for the server. There does not exist the PROXY protocol for this version!

server::disabled_endpoints

New in version 1.4.9
Default: All endpoints are enabled

It is possible to disable certain HTTP location endpoints that are not needed.

server:
  disabled_endpoints:
    auth_header: false
    auth_json: false
    auth_basic: false
    auth_nginx: false
    auth_saslauthd: false

tip

Disableing unused endpoints may enhance overall security!

Meaning

Key-name	location	description
auth_header	/api/v1/auth/header	Turn off requests based on HTTP headers
auth_json	/api/v1/auth/json	Turn off HTTP JSON-POST requests
auth_basic	/api/v1/auth/basic	Turn off HTTP Basic Authorization requests (recommended!)
auth_nginx	/api/v1/auth/nginx	Turn off Nginx based requests used by the mail plugin of Nginx
auth_saslauthd	/api/v1/auth/saslauthd	Turn off saslauthd requests used with cyrus-sasl
custom_hooks	/api/v1/custom/*	Turn off all Lua based custom hooks

server::http_client

Whenever Nauthilus is acting as an HTTP client, a common shared Go-builtin HTTP client is used to handle all requests.

There do exist the following HTTP clients in Nauthilus:

Scope	Usage
core	If the Ory hydra frontend is turned on, all admin-API requests are handled by this client
action	Used for Lua actions, if HTTP requests are used
filter	Used for Lua filters, if HTTP requests are used
feature	Used for Lua featuress, if HTTP requests are used
hook	Used for Lua custom hooks, if HTTP requests are used

Settings are shared with all HTTP clients!

Setting	Meaning (Used from official Go docs)	Default
max_connections_per_host	Limits the total number of connections per host, including connections in the dialing, active, and idle states. On limit violation, dials will block.	0, no limits
max_idle_connections	Controls the maximum number of idle (keep-alive) connections across all hosts.	0, no limits
max_idle_connections_per_host	Controls the maximum idle (keep-alive) connections to keep per-host.	0, no limits
idle_connection_timeout	Is the maximum amount of time an idle (keep-alive) connection will remain idle before closing itself.	0, no limits

Units for the timeout option should add a time unit like

s - seconds
m - minutes
h - hours

server:
  http_client:
      max_connections_per_host: 10
      max_idle_connections: 5
      max_idle_connections_per_host: 1
      idle_connection_timeout: 60s

server::tls

This object defines TLS related settings.

server::tls::enabled

Default: false

This flag turns on (true) TLS support in the server.

server:
  tls:
    enabled: true

server::tls::cert and server::tls::key

Default: ""

These two settings define a path to an X509 PEM-formatted certificate and key.

server:
  tls:
    cert: /usr/local/etc/nauthilus/localhost.localdomain.pem
    key: /usr/local/etc/nauthilus/localhost.localdomain.key.pem

server::tls::http_client_skip_verify

Default: false

This flag turns on (true) insecure TLS connections for HTTP(s) requests that are originating from Nauthilus to some remote.

server:
  tls:
    http_client_skip_verify: true

server::basic_auth

This object defines basic authorization settings.

server::basic_auth::enabled

Default: false

This flag turns on (true) Basic Auth support in the server.

server::basic_auth::username and server::basic_auth::password

Default: ""

These settings define a username and its password that is required by HTTP(s) clients to communicate with Nauthilus.

server::instance_name

Default: "nauthilus"

This defines the application name. If not defined, it defaults to nauthilus

server::logs

This object defined logging relates settings.

server::log::json

Default: false

This flag turns on (true) logging in JSON format.

server:
  log:
    json: true

server::log::level

Default: "none"

This string defines the log level. It is one of:

Level	Comment
none	Entirely turn of logging
debug	See debug modules below!
info
warn
error

server:
  log:
    level: debug

server::log::debug_modules

Default: empty list

if debugging is turned on, only very limited debug messages are logged by default. You can increase logging by activating additional log modules. This is the list of all available debug modules:

Module	Application
all	Full debugging
auth	This turns on logging for the main authentication process
hydra	Communication with the Ory hydra server
webauthn	Turn on debugging for WebAuthn (under development)
statistics	Prometheus related debugging
whitelist	Show whitelist related debugging
ldap	Show LDAP command and filter related debugging
ldap_pool	Show LDAP-pool related debugging such as free/busy/closed connections and housekeeping
cache	Turn on cache backend related debugging
brute_force	Turn on brute-force releated debugging
rbl	Turn on RBL (realtime-blackhole-list) related debugging
action	Turn on Lua post-action related debugging
feature	Turn on feature related debugging
lua	Turn on Lua releated debugging
filter	Turn on filter related debugging

server:
  log:
    debug_modules:
      - auth
      - ldap 
      - filter

server::backends

Default: none
required

This object defines, which backends are enabled. You must define at least one backend!

Name	Comment
cache	The Redis cache backend is used for positive and failed login requests and should be enabled
ldap	This is the native LDAP backend. See settings below for configuration
lua	This is a Lua backend

note

The *cache backend not only caches positive and negative requests. It is also a major component for the brute force buckets to detect users with repetitive wrong passwords.

warning

The cache backend should always be the first backend. The order of backends matters!

server::features

Default: empty list

This object defines runtime features.

Here is a list of features that can be turned on:

Name	Usage
lua	General purpose Lua feature. You can have as many features as you like. They run in sequential order
tls_encryption	Clients must be connected securely to a service to be allowed to authenticate
relay_domains	If the login name equals to an email address, the domain component is compared to a list of known domains
rbl	Check a client IP address against realtime blackhole lists
backend_server_monitoring	This is a special feature that is not used for filtering

These features are primarely used to filter out requests before the main authentication process starts.

note

The features are run one-by-one. The rbl feature does query lists in parallel. The lua feature is always run as first feature and is the only one that can skip further processing of other features!

The backend_server_monitoring feature turns on a background job that does a health check for any kind of backend servers. It holds an in-memory list of alive servers that can be used in Lua scripts to select healthy servers.

server:
  features:
    - tls_encryption
    - lua
    - rbl 

server::brute_force_protocols

Default: empty list

This object defines a list of protocols for which the brute force protection is turned on.

When a service talks to Nauthilus, it must provide a protocol that is used by a remote client while authenticating.

This list describes protocols for which Nauthilus does brute force checks.

Here is a good working example that can be taken in a production environment:

server:
  brute_force_protocols:
    - imap
    - imaps
    - submission
    - smtp
    - smtps
    - ory-hydra
    - http

note

While most of the protocols are free to chose, ory-hydra has a special meaning for Nauthilus and is assigned to the communication between Nauthilus and the Ory hydra serverr.

server::ory_hydra_admin_url

Default: "http://127.0.0.1:4445"

This setting is the Ory hydra admin URL.

server:
  ory_hydra_admin_url: https://hydra.example.com:4445

server::dns

This object defines settings related to the DNS name resolver.

server::dns::resolver

Default: ""

If this setting is given, Nauthilus does not use the Go internal DNS resolver. Instead, it uses the provided resolver for DNS resolution.

server:
  dns:
    resolver: 192.168.0.1

server::dns::timeout

Default: 5

If a custom DNS resolver is set, you can specify a default timeout in seconds, after which DNS queries are aborted without waiting for a result.

server:
  dns:
    timeout: 3

server::dns::resolve_client_ip

Default: false

If a DNS reverse lookup should be done for incoming client requests, you can turn on (true) this feature.

server:
  dns:
    resolve_client_ip: true

warning

Turning on this feature will heavily increase network latency and DNS resolver load. It is suggested to use this feature with care.

server::insights

This object defines settings related to go pprof and is mainly useful for developers.

server::insights::enable_pprof

Default: false

Enable (true) pprof in Go for debugging purposes.

server:
  insights:
    enable_pprof: true

server::insights::enable_block_profile

Default: false

If pprof is enabled (required for this flag), you can also activate a block profile, which helps to find blocking code.

server:
  insights:
      enable_block_profile: true

server::redis

This object defines settings related to the Redis server.

server::redis::database_number

Default: 0

If Redis is configured to run standalone, master-slave or as sentinel, you can select the database number that Nauthilus must use.

server:
  redis:
      database_number: 2

server::redis::prefix

Default: ""

You can define a prefix that has to be used for any keys in Redis.

server:
  redis:
    prefix: "nt_"

note

This prefix is for Nauthilus internal keys only. If you chode to use Redis within Lua, you have to manage Redis keys yourself

tip

You may define custom prefixes in Lua with "ntc:" Like "Nauthilus-custom". That way you have a difference between built-in keys and user defined keys.

server::redis::pool_size

Default: 0
required

This is a Redis pool size. The pool is managed by the underlying redis library go-redis.

server:
  redis:
    pool_size: 10

server::redis::idle_pool_size

Default: 0

This is a Redis idle pool size. The pool is managed by the underlying redis library go-redis.

server:
  redis:
    idle_pool_size: 2

server::redis::positive_cache_ttl and server::redis::negative_cache_ttl

Default: 3600

Both values set the expiration value for Redis keys in seconds. The positive cache TTL is for authenticated users, while the negative cache TTL is for authentication failures. The latter may be larger as it is also used in the brute-force logic to detect users that try to log in with a repeating wrong password. Such requests are never treated as an attack.

server:
  redis:
    positive_cache_ttl: 3600
    negative_cache_ttl: 7200

Changes in version 1.4.9:

Units should now add a time unit like

s - seconds
m - minutes
h - hours

server::redis::master

If running Redis standalone or in master-slave mode, you have to define the master object.

server::redis::master::address

Default: "127.0.0.1:6379"

This is the socket for a Redis connection to either a standalone server or for a master.

server:
  redis:
    master:
      address: 127.0.0.1:6379

server::redis::master::username and server::redis::master::password

Default: empty

This is an optional username and password for Redis, if the service requires authentication.

Server:
  redis:
    master:
      username: some_user
      password: some_secret

server::redis::replica

This object defines a replica to a master. Currently, there is only support for one master and one replica. If you need more replica server, consider using sentinel instead or use some load balancer in front of Nauthilus that may distribute replica connections to more than one replica instance.

server::redis::replica::address

Deprecated in version 1.4.10
Default: ""

This is the socket for a Redis connection to a replica instance.

server:
  redis:
    replica:
      address: 10.10.10.10:6379

server::redis::replica::addresses

New in version 1.4.10
_Default: []

This is a list of one or more sockets for a Redis connection to a replica instance.

server:
  redis:
    replica:
      addresses:
        - 10.10.10.10:6379

server::redis::sentinels

NAuthilus can connect to Redis sentinels. The following options define such a setup.

server::redis::sentinels::master

Default: ""

This is the name of the sentinel master.

server:
  redis:
    sentinels:
      master: mymaster

server::redis::sentinels::addresses

Default: empty list

This is a list of Redis sentienl sockets.

server:
  redis:
    sentinels:
      addresses:
        - 127.0.0.1:26379
        - 127.0.0.1:26378
        - 127.0.0.1:26377

note

At least one sentinel address is required.

Here is an example for K8s redis-operator sentinel, if you run Nauthilus in Kubernetes on-premise and a NodePort service:

server:
  redis:
    sentinels:
      master: myMaster
      addresses:
        - redis-sentinel-sentinel-0.redis-sentinel-sentinel-headless.ot-operators.svc.cluster.local:26379
        - redis-sentinel-sentinel-1.redis-sentinel-sentinel-headless.ot-operators.svc.cluster.local:26379
        - redis-sentinel-sentinel-2.redis-sentinel-sentinel-headless.ot-operators.svc.cluster.local:26379

server::redis::sentinels::username and server::reids::sentinels::password

Default: ""

Both of these parameters are optional settings, if your Redis sentinels require authentication.

server:
  redis:
    sentinels:
      username: some_user
      password: some_secret

server::redis::cluster

If NAuthilus should be connected to a Redis cluster, the following settings can be set to do so.

server::redis::cluster::addresses

Default: empty list

This is a list of one or more Redis sockets pointing to a Redis cluster.

server:
  redis:
    cluster:
      addresses:
      - 127.0.0.1:6379
      - 127.0.0.1:6378
      - 127.0.0.1:6377

server::master_user

This object defines settings related to a so-called master user

server::master_user::enabled

Default: false

If this flag is turned on (true), Nauthilus honors login usernames that are master users. A master user looks something like this:

user@domain.tld*masteruser

As you can see, the master user is separated from the real login name by a "*" character followed by the name of a master user. If NAuthilus detecs such a user, it will do authentication against the master user.

server:
  master_user:
    enabled: true

server::master_user::delimiter

Default: "*"

This is the character that splits the real username from the master user.

server:
  master_user:
    delimiter: "*"

server::frontend

Nauthilus specific settings for the frontend (OIDC)

server::frontend::enabled

Default: false

Turn on the frontend.

server:
  frontend:
    enabled: true

server::frontend::csrf_secret

Default: ""
required

This key is required whenever CSRF (cross-site-request-forgery) attacks must be prevented. This is currently used, if Nauthilus is configured to communicate with Ory Hydra. The login, consent and logout pages are protected with a CSRF token. This value defines the secret used for that token.

This value MUST be 32 bytes long.

server::frontend::cookie_store_auth_key and server::frontend::cookie_store_encryption_key

Default: ""
required

These keys are used to encrypt and decrypt session cookies.

Both values MUST be 32 bytes long.

server::prometheus_timer

Turn on several Prometheus labels, which are timers for certain aspects of the application.

server::prometheus\timer::enabled

Turn on the prometheus timers.

server:
  prometheus_timer:
    enabled: true

server::prometheus\timer::labels

The following labels can be turned on:

Label name	Description
account	Mode "list-accounts" timer
action	Timers for Lua actions
backend	Timers for backends
brute_force	Timers for the brute force functions
feature	Timers for all features
filter	Timers for Lua filters
request	Timer for the entire client request without post actions
store_totp	Timer for storing a new TOTP secret to a backend
post_action	Timers for Lua post actions
dns	Timers for DNS queries

Example:

server:
  prometheus_timer:
    enabled: true
    labels:
      - request
      - dns

realtime_blackhole_lists

This is the rbl feature. It checks a remote client IP address against a list of defined RBL lists. The lists are run simultaneously. They may contain a weight parameter which is added to a total value. If that value raises a threshold, the features directly returns with a client reject.

realtime_blackhole_lists::lists:

Default: empty list

This section defines one or more RBL lists. A RBL list requires the following fields:

Field name	Description
name	Example RBL name
rbl	Domain part that is appended to the reversed IP address
ipv4	Boolean that enables the list for IPv4 support
ipv6	Boolean that enables the list for IPv6 support
return_code	Expected DNS return code, if an IP address was listed
allow_failure	Return a temporary failure, if a DNS lookup to the given list failed (not NXDOMAIN errors!)
weight	This value defines the weight for the given RBL list. See the threshold description for the meaning

The weight value may be negative.

tip

The suggested weight value should be between -255 and 255. A negative weight turns the list into a whitelist

realtime_blackhole_lists::threshold

Default: 0

The threshold parameter defines an absolute value which tells Nauthilus, when to abort further list lookups. If the sum of all weights is above the threshold value, the feature triggers an immediate client reject.

realtime_blackhole_lists::ip_whitelist

Default: empty list

You can define IPv4 and IPv6 addresses with a CIDR mask to whitelist clients from this feature. If a client was found on this list, the feature is not enabled while processing the authentication request.

realtime_blackhole_lists:
  ip_whitelist:
    - 127.0.0.0/8
    - ::1
    - 192.168.0.0/16
    - 172.16.0.0/12
    - 10.0.0.0/8
    - fd00::/8
    - 169.254.0.0/16
    - fe80::/10

cleartext_networks

Default: empty list

Nauthilus can check, if a remote client connected using TLS. This test will reject clients that do not communicate secured. The whitelist is for trusted local IPs and networks that are allowed to authenticate unencrypted.

note

Connections from "localhost" are allways trusted unencrypted!

IPs with an optional CIDR mask:

cleartext_networks:
  - 127.0.0.0/8
  - ::1

relay_domains

If the username equals to an email address, Nauthilus can split the login into the local and domain part. The latter is compared against a (currently) static list. If the domain is unknown, the client will be rejected.

relay_domains::static

Default: empty list

This key holds a list of domain names.

relay_domains:
  static:
    - example.com
    - foobar.org

backend_server_monitoring

If you have turned on the feature backend_server_monitoring, Nauthilus is able to do liveness probes for backend servers. The result is updated every 20 seconds (hard-coded for now). This information can be used in Lua scripts. The initial idea was to chose a backend server for the Nginx-based authentication process. Other usecases are also possible, depending on your needs.

backend_server_monitoring::backend_servers

This configuration block defines servers to be monitored.

The following protocols can be used to monitor a backend server:

smtp
lmtp
pop3
imap
sieve
http

Servers can have a lightweight check, where only the connection is tested.

note

A connect timeout of 5 seconds is used. Also for reading and writing to an established connection.

If the HAproxy flag is set, this is checked as well.

Having TLS settings for a backend, a handshake is done on top of the connection.

warning

We currently only support plain or TLS-on-connect connections. Only sieve has STARTTLS support

If deep checks are enabled, Nauthilus talks the configured protocol with each backend. Optionally, a givven test user and its password can be used to verify a successful connection to the backend. We recommend to have one test user for each backend to prevent technical problems with backend servers (for example index issues with Dovecot).

Example usage:

backend_server_monitoring:

  backend_servers:
    - protocol: imap
      host: 192.168.0.2
      port: 993
      deep_check: true
      test_username: some_unique_test_user
      test_password: some_password
      tls: true
      tls_skip_verify: true
      haproxy_v2: true

The settings should be self-explained.

brute_force

This feature allows you to define brute force buckets. A bucket is a container on Redis that will collect failed login attempts from remote clients. Each time a client fails the authentication process, the buckets are updated. If a bucket is full, a client is rejected directly without validating the credentials against password database backends.

A bucket has an expiration time stamp. As long as failed logins are stored, a bucket will be refreshed. A bucket will be removed from Redis, if no requests trigger the bucket and the TTL is expired.

You can define as many buckets as you want. A bucket has a name, a period, an indicator, if the bucket handles IPv4 or IPv6 IPs and a maximum allowed failed requests counter.

These buckets are independent of a user login name. They will count strictly each failed login request. Features like the realtime_blackhole_lists feature (and others) will also update the buckets directly.

If the brute_force feature recognizes a misconfigured MUA, it will not block the client forever!

Recommendation

If you define chains of buckets, user lower TTLs for buckets that hold IPs with a smaller IP range. Use higher TTLs for networks. See the example below.

brute_force::buckets

Default: empty list

This section lists chains of buckets. Here is the definition of a bucket:

Field name	Description
name	A user friendly name for the bucket
period	The TTL after which an unused bucket is removed from Redis
cidr	The network mask of an IP address
ipv4	Boolean that enables the bucket for IPv4 support
ipv6	Boolean that enables the bucket for IPv6 support
failed_requests	Threshold value unitl a client will be blocked directly without asking authentication backends

brute_force::ip_whitelist

Default: empty list

You can define a list of IPs and networks that are whitelisted from the brute_force feature.

brute_force:
  ip_whitelist:
    - 127.0.0.0/8
    - ::1
    - 192.168.0.0/16

brute_force::learning

By default, Nauthilus does not learn from features such as relay_domains or RBLs, as this could lead to incorrect learning. However, in environments where false positives can be ruled out, Nauthilus can also count violations in the buckets.

The learning parameter can include the following strings to enable learning:

realtime_blackhole_lists
cleartext_networks
relay_domains
brute_force
lua

brute_force:
  learning:
    - realtime_blackhole_lists
    - lua

password_nonce

Default: ""
required

This is a random string that is used to concatenate it with the password. The result will be hashed and truncated and is used in Redis.

oauth2

Default: nil

Nauthilus currently supports Ory Hydra to deal as authentication backend for OAuth2/OpenID Connect.

There are two sections that define the behavior of Nauthilus when it comes to the point of building the ID token.

Configuration flow

The first step is to create a new Ory Hydra client for your application. Here is an example:

hydra create oauth2-client \
    --endpoint https://ORY-HYDRA-ADMIN:4445 \
    --format json \
    --name "Some name for your application" \
    --secret SomeSecretPasswordForYourClient \
    --grant-type authorization_code,refresh_token \
    --response-type token,code,id_token \
    --token-endpoint-auth-method client_secret_post \
    --scope openid,offline,profile,email,dovecot \
    --redirect-uri https://your-redirect-url-that-MUST-exactly-match \
    --policy-uri https://link-to-a-policy-website/ \
    --tos-uri https://link-to-a-terms-of-service-website/ \
    --client-uri https://link-to-a-page-that-describes-the-application/

Some of these parameters are optional like --policy-uri, --tos-uri and --client-uri, but if they were found, Nauthilus will render them in the page templates.

Next step is to add a section to Nauthilus, where you tell the server what data from the authentication backends are used to build the ID- and access token. The most important field is the subject field.

warning

Make sure to pick a subject that is realy unique to identify your user inside your company. Furthermore, make sure to stay with the subject accross all your applications defined in Nauthilus, as it will for sure have unwanted behavior if mixing it!

Besides the subject, Nauthilus can send arbitrary data to Ory Hydra upon an accepted consent request that will be sent out to the remote client as claims. You need to define a mapping in Nauthilus that maps the LDAP attributes to claim names.

If a user was authenticated on the login page, the server will have LDAP results that will be taken with this mapping. Therefor it is important to tell each backend, which data needs to be retrieved. Data will be cached on Redis. If you modify applications and require more fields/results from the underlying backends, you must clear the Redis objects or wait for an expiration.

The LDAP backend section will tell you more about this later on this page.

After you have refreshed Nauthilus, you can configure your web application, Dovecot or whatever with the new settings.

About scopes and claims

Nauthilus is aware of the following built-in scopes:

profile
address
email
phone

The OpenID 1.0 core spec associates several claims to each of these scopes:

For the scope profile

name
given_name
family_name
middle_name
nickname
preferred_username
website
profile
picture
gender
birthdate
zoneinfo
locale
updated_at

For the scope address

address

Nauthilus does return addresses only as formatted JSON onject.

For the scope email

email
email_verified

For the scope phone

phone_number
phone_number_verfied

Each of these claims can be mapped in the oauth2 section.

Nauthilus does also support a groups claim, which is a list of strings, each containing a group membership value.

User defined scopes and claims

If the default scopes and claims are not enough for your application, you can define your own sets yourself. This has some current limitations! By defining claims, you must tell Nauthilus a type for each value. Currently supported types include:

Type	Name	Size	Example
String	string	-	custom_claim_foo
Boolean	boolean	-	true / false
Integer	integer	64	-45366473
Float	float	64	3.1415

Numers are signed. It may happen that the communication between Nauthilus and Ory Hydra will modify integers by using their exponential form. This is a known issue and can not be fixed at the moment. If this happens, try using a string instead and let the final application convert it into its representing value.

oauth2::clients

This section defines your OAuth2 clients, containing a name, the client_id, the subject and the claim mapping.

oauth2:
  clients:
    - name: Testing
      client_id: THIS-IS-THE-CLIENT-ID-FROM-ORY-HYDRA
      skip_consent: false
      skip_totp: false
      subject: entryUUID
      claims:
        name: cn
        given_name: givenName
        family_name: sn
        nickname: uniqueIdentifier
        preferred_username: uniqueIdentifier
        email: mail

Your LDAP backend does return results for attributes. The example is a mapping for OpenLDAP.

As you can see in the example, there is no need to deliver all possible claims. Which claims are required is dependent to your consuming application.

note

Make sure to list claims for which you have defined the matching scopes! If you define an email mapping whithout the matching scope, your user seeing the consent page will not be able to accept the scope and therefor the claim will not be available!

note

If you configure Nauthilus to deal with a service hosted at your companies site, you may want to skip the consent page. Do so by setting skip_consent to true.

note

Some applications provide their own second factor implementation. If you want to prevent duplicated second factor authentication, you can skip TOTP for a client, by adding skip_totp with a value of true.

oauth2::custom_scopes

This section allows you to define custom scopes and there claim definition as described earlier on this page. It lists objects like the following:

oauth2:
  custom_scopes:
    - name: dovecot
      description: Some description
      description_de: Optional German description
      description_fr: Optional French description
      claims:
        - name: dovecot_user
          type: string
    
        - name: dovecot_mailbox_home
          type: string
    
        - name: dovecot_mailbox_path
          type: string
    
        - name: dovecot_acl_groups
          type: string

note

Claims are not updated after first delivery! So do not send data that may change dynamically!

The description field will be used in the consent.html template to give the user more information about this scope. You can add descriptions with an underscore followed by a lower case country code, do translate the description into other languages. The default is English and taken from the description key.

Supported languages:

Database backends

Nauthilus needs database backends to validate user credentials. Besides the cache backend, which is special, Nauthilus can use LDAP and Lua based backends. The current implementation is limited to use one LDAP and one Lua backend at the same time.

If you define an LDAP and a Lua backend, both will be queried in the order you have defined in server::backends

warning

The "idea" of a backend is to check user credentials!

Do not mix password verification and policy tasks in the backends!

If you want to enforce policies, make use of Lua filters, because they never influence the brute-force-logic nor is it cached on Redis. If you combine both aspects in the backends, you will risk of learning correct passwords as wrong!

Protocols

Backends carry configuration information about protocols. A protocol is something like smtp or imap but can be anything else. As Nauthilus is used over HTTP(S), the protocol is shiiped with the HTTP-request header Auth-Protocol as described in the Nginx-protocol.

If Nauthilus has a protocol definition for a protocol, rules applied to that section are taken for password validation.

You may add a default protocol to LDAP and Lua, which will be used for protocols without having their own section. If there is no default keyword, the backend will fail for unknown protocols. In case of using Lua and LDAP at the same time, there will be a chance that the other backend has information for the requested protocol.

If all backends fail due to a missing definition, a temporary error is raised and the client can not authenticate.

Special protocols

If Nauthilus is called with the location /api/v1/service/nginx, the protocols smtp and imap will return additional HTTP response headers:

Auth-Server and Auth-Port ( see Nginx-protocol)

If Nauthilus is used for HTTP basic authentication (Nginx backend), the protocol http and internal-basic-auth are understood.

Both protocols will honor the X-Forwarded-For header to identify the real client IP address. This is important to have the brute force feature working correctly. You do not want your reverse proxy (if any) be blocked.

Nauthilus can be protected with HTTP basic authorization, which is configured with the environment variables * HTTP_USE_BASIC_AUTH*, HTTP_BASIC_AUTH_USERNAME and HTTP_BASIC_AUTH_PASSWORD. If you do not want a static username and password, you can add the internal-basic-auth protocol to one of your protocol definitions and Nauthilus will use this backend for username and passowrd checks.

The protocol ory-hydra is for OAuth2/OpenID Connect. Note that it is ory-hydra and not oauth2, as other servers may appear in the future with different bindings/dependencies to Nauthilus.

Macros

As LDAP queries have to deal with usernames or other information, it may be required to define several macros inside the queries, which must be replaced by Nauthilus.

The main implementation is adopted from Dovecot, but only a subset of all possible macros is currently provided.

Macro form

The general form is as follows:

%Modifiers{long variables}

Modifier

Modifiers are optional. Currently, the following modifiers are known:

Modifier	Meaning
L	Treat all characters lower case
U	Treat all characters upper case
R	Reverse a string
T	Trim a string

Note:

Do not combine L and U at the same time for one macro, as this causes unpredictable results!

Long variables

The following macro names are known and described in the following table:

Varaible name	Meaning
user	Full username, i.e. localpart@domain.tld
username	The local part of {user}, if user has a domain part, else user and username are the same
domain	The domain part of {user}. Empty string, if {user} did not contain a domain part
service	The service name, i.e. imap, pop3, lmtp
local_ip	Local IP address
local_port	Local port
remote_ip	Remote client IP address
remote_port	Remote client port
totp_secret	This macros gets replaced when adding or removing a TOTP secret to a user account.

Macro example

Lower case form of a username (full email, if user string contains a '@' character).

%L{user}

Cache namespaces

Each protocol block can define a Redis cache namespace. That is especially useful, if you require different results for different protocols. By not using a namespace, a default namspace "__default__" is used.

You can apply the same namespaces to different protocols as long as the requested results carry the same information. If you use the Dovecot IMAP/POP3 server i.e. with the submission proxy feature, Dovecot requires the same information for * imap* and submission, but your protocol sections may serve different queries/filters. But the list of returned keys (not values) will be the same. See the full example below to get an idea.

Encrypted passwords

Passwords can be stored encrypted inside a SQL database (Lua backend). Nauthilus needs to know this and can deal with the following password schemas:

PHP versions:

{SSHA256}
{SSHA512}

Encoded formats:

MD5
SSHA256
SSHA512
bcrypt
Argon2i
Argon2id

The Lua backend can use a built-in function to compare such passwords.

LDAP

Default: nil

Structure

The LDAP section has two keywords config and search. The first is used for the backend configuration, the latter for certain protocols.

ldap::config

The config section defines the main pool settings and one or more LDAP servers. The principal of work is that Nauthilus tries to connect to the first available server. If a server connection fails, Nauthilus tries to reconnect to an LDAP server in the order that was defined.

The following table list keys and examples to configure LDAP:

Key	Required	Description	Example
lookup_pool_size	no	Maximum number of connection that can be opened	8
lookup_idle_pool_size	no	Minimum number of connections that must be kept open	2
auth_pool_size	no	Maximum number of connection that can be opened	8
auth_idle_pool_size	no	Minimum number of connections that must be kept open	2
server_uri	yes	A string containing a LDAP URI or a list of URIs	ldap://localhost:389/
starttls	no	Is STARTTLS used with the LDAP connection	true / false
tls_skip_verify	no	If you use self signed certificates, you may to skip TLS verification	ture / false
sasl_external	no	Use simple bind or SASL/EXTERNAL	true / false
pool_only	no	Use Lua to communicate with LDAP	true / false
connect_abort_timeout	no	New in version 1.4.12: If a pool is exhausted and a new connection can not be established within connect_abort_timeout, the request will temp-fail.	10s (default). Maximum 10m is allowed

The lookup pool settings define a pooling to find user objects in LDAP. The auth pooling is used to authenticate users.

note

By using the pool_only option, the authentication pool is not started and no authentication attempts are done against the ldap-backend. You have to implement the password-verify logic as well as the list-accounts routine completely in Lua.

To verify a user password, you must retrieve the userPassword attribute and make use of the compare-function in Lua.

The ldap backend must still be enabled!

If using SASL/EXTERNAL:

Key	Required	Description	Example
tls_ca_cert	(yes) if starttls is enabled	CA bundle or CA file in PEM format	/path/to/company/ca-file.pem
tls_client_cert	(yes)	X509 client certificate in PEM format	/path/to/client/cert.pem
tls_client_key	(yes)	X509 client key in PEM format	/path/to/client/key.pem

Note:

Make sure to remove a key passphrase from the key.

Pooling

Nauthilus will open as many connections, as the *_idle_pool_size value defines. All other connections are done on demand. A background thread (30 seconds delay) will observe a pool and will close unused connections.

If a new connection is required, Nauthilus first checks, if there is some free connection available and picks it up. If none is free, a new connection is opened. If the pool is exhausted, requests are enqueued until a new connection is free again.

Bind method

Nauthilus can either do a so-called simple bind, using a bind DN and a bind password, or it can do SASL/EXTERNAL usinga X509 client certificate and key. Please check your LDAP configuration to find out, which mode is available for you.

ldap::search

This section defines blocks that combine protocols and LDAP filters. Here is a table of keys that are known:

Definition of a search list

Key	Required	Description	Example
protocol	yes	A protocol name or a list of protocols in YAML format	imap
cache_name	no	A namespace for the Redis cache	dovecot
base_dn	yes	The LDAP base DN for the queries
filter	yes	Section of LDAP filters	-
mapping	yes	Query result attribute/logic mapping	-
attribute	yes	One string representing an attribute from the user object or a YAML-list of attributes from an user object. The results are used either in HTTP-response-headers with a X-Nauthilus-Attributename or used to assemble Open ID token claims	uid

Filter

Key	Required	Description	Example
user	yes	LDAP filter to retrieve a user DN for a re-bind operation	Example see below
list_accounts	no	Nauthilus may return a list of known account names in an HTTP response, if the GET query string contains mode=list-accounts	Example see below

Mapping

Key	Required	Description	Example
account_field	yes	This result of this attribute is returned as the user account	uid
totp_secret_field	no	Tell Nauthilus which field is used for the TOTP secret key	rns2FATOTPSecret

ldap:
  search:
    - protocol:
        - imap
        - pop3
        - lmtp
        - sieve
        - doveadm
        - indexer-worker
        - default
     
      cache_name: dovecot
      base_dn: ou=people,ou=it,dc=example,dc=com
        
      filter:
          user: |
            (&
              (memberOf=cn=Dovecot,ou=Mail,ou=groups,ou=it,dc=example,dc=com)
              (objectClass=rnsMSDovecotAccount)
              (rnsMSEnableDovecot=TRUE)
              (|
                (uniqueIdentifier=%L{user})
                (rnsMSRecipientAddress=%L{user})
              )
            )
          list_accounts: |
            (&
              (memberOf=cn=Dovecot,ou=Mail,ou=groups,ou=it,dc=example,dc=com)
              (objectClass=rnsMSDovecotAccount)
              (rnsMSEnableDovecot=TRUE)
              (!
                (rnsMSDovecotMaster=TRUE)
              )
            )
            
      mapping:
        account_field: rnsMSDovecotUser
        
      attribute:
        - uid
        - rnsMSMailboxHome
        - rnsMSMailPath
        - rnsMSACLGroups
        - rnsMSDovecotUser

If you need a schema for the TOTP stuff, you could use the following draft:

objectidentifier RNSRoot     1.3.6.1.4.1.31612
objectidentifier RNSLDAP     RNSRoot:1
objectidentifier RNS2FA      RNSLDAP:4
objectidentifier RNSLDAPat   RNS2FA:1
objectidentifier RNSLDAPoc   RNS2FA:2

attributetype ( RNSLDAPat:1
  NAME 'rns2FATOTPSecret'
  DESC 'TOTP secret'
  EQUALITY caseExactMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
  SINGLE-VALUE )

attributetype ( RNSLDAPat:2
  NAME 'rns2FATOTPRecoveryCode'
  DESC 'TOTP backup recovery code'
  EQUALITY caseExactMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

objectclass ( RNSLDAPoc:1
  NAME 'rns2FATOTP'
  DESC 'Time-based one-time passwords with backup recovery codes'
  SUP top AUXILIARY
  MAY ( rns2FATOTPSecret $ rns2FATOTPRecoveryCode ) )

It will be anhanced over time to support webauthn as well.

Lua backend

Default: nil

The Lua backend is described in detail in the Lua API.

lua::features

Features are scripts that are run before the actual authentication process is taken. A Lua feature has a name and a script path.

Scripts are run in order and the first script that triggers, aborts the execution for all remaining scripts.

Definition of a "feature" list

Key	Required	Description	Example
name	yes	A unique name for the Lua feature	demo
script_path	yes	Full path to the Lua feature script	-

lua::filters

Filters run after all backends have completed their work. A filter can override the existing result of an authentication request. The idea is to have some post checks (maybe remote REST calls, database queries...) that will lead to a different final result.

It is important that script honor the backend result, if they do not wish to change it! In that case they must pass the same result back to Nauthilus.

Key	Required	Description	Example
name	yes	A unique name for the Lua feature	geoip-policyd
script_path	yes	Full path to the Lua feature script	-

lua::actions

Actions have a type and script path element for each Lua script. An incoming request is waiting for all actions to be completed except of post actions. The latter run afterward, when the client already may have been disconnected.

Definition of an "actions" list

Key	Required	Description	Example
type	yes	The type of action. Can be repeated many times.	brute_force
name	yes	A unique name for the Lua action	logging
script_path	yes	Full path to the Lua action script	-

The following types are known:

Type	Description
brute_force	Run after a brute force attack has been detected
rbl	Runs after a requesting client IP was found on a real time blackhole list.
tls_encryption	Runs, if a client connection was not encrypted.
relay_domains	Runs, if the login name equals an e-mail address and the domain is not served.
lua	Runs, if any of the Lua features triggered.
post	Run always in background after the request already finished.

lua::config

Key	Required	Description	Example
backend_script_path	yes	Full path to the Lua backend script	./server/lua-plugins.d/backend/backend.lua
callback_script_path	no	Full path to the Lua callback script	./server/lua-plugins.d/callback/callback.lua
package_path	no	Set a Lua module path for custom Lua modules	/usr/local/etc/nauthilus/lualib/?.lua

note

The callback script can be used to provide additional information. If you use Dovecot, you might use this script to track a users' session and cleanup things on Redis. Look at the callback.lua script that is bundled with Nauthilus.

lua::search

This section defines blocks that combine protocols and Redis cache namespaces. Here is a table of keys that are known:

Definition of a "search" list

Key	Required	Description	Example
protocol	yes	A protocol name or a list of protocols in YAML format	imap
cache_name	no	A namespace for the Redis cache	dovecot

lua:
  features:
    - name: demo
      script_path: ./server/lua-plugins.d/features/demo.lua
    - name: comm
      script_path: ./server/lua-plugins.d/features/comm.lua

  filters:
    - name: geoip-policyd
      script_path: /some/path/to/lua/script.lua
      
  actions:
    - type: brute_force
      name: brute_force
      script_path: ./server/lua-plugins.d/actions/bruteforce.lua
    - type: post
      name: demoe
      script_path: ./server/lua-plugins.d/actions/demo.lua
    - type: post
      name: haveibeenpwnd
      script_path: ./server/lua-plugins.d/actions/haveibeenpwnd.lua
    - type: post
      name: telegram
      script_path: ./server/lua-plugins.d/actions/telegram.lua

  config:
    script_path: ./server/lua-plugins.d/backend/backend.lua

  search:
    - protocol:
        - imap
        - pop3
        - lmtp
        - sieve
        - doveadm
        - indexer-worker
        - default
      cache_name: dovecot

    - protocol:
        - smtp
        - submission
      cache_name: submission

    - protocol: ory-hydra
      cache_name: oidc

Full example (standalone)

server:
  address: "[::]:9443"
  http3: true
  haproxy_v2: false

  tls:
    enabled: true
    cert: /usr/local/etc/nauthilus/localhost.localdomain.pem
    key: /usr/local/etc/nauthilus/localhost.localdomain.key.pem
    http_client_skip_verify: true

  basic_auth:
    enabled: true
    username: nauthilus
    password: nauthilus

  instance_name: nauthilus_demo

  log:
    json: false
    level: debug
    debug_modules:
      - auth
      - lua
      - feature

  backends:
    - cache
    - lua
    - ldap

  features:
    - lua
    - relay_domains
    - backend_server_monitoring

  brute_force_protocols:
    - imap
    - imaps
    - submission
    - smtp
    - smtps
    - ory-hydra
    - http

  ory_hydra_admin_url: https://hydra.example.com:4445

  dns:
    resolver: 192.168.1.1
    timeout: 3
    resolve_client_ip: false

  insights:
    enable_pprof: true
    enable_block_profile: true

  redis:
    database_number: 2
    prefix: nt_
    pool_size: 10

    positive_cache_ttl: 3600s
    negative_cache_ttl: 7200s

    master:
      address: 127.0.0.1:6379

  master_user:
    enabled: true
    delimiter: "*"
  
  frontend:
    enabled: true
    csrf_secret: 32-byte-long-random-secret
    cookie_store_auth_key: 32-byte-long-random-secret
    cookie_store_encryption_key: 16-24-or-32-byte-long-random-secret

realtime_blackhole_lists:

  threshold: 10

  lists:
    - name: SpamRats AuthBL
      rbl: auth.spamrats.com
      ipv4: true
      ipv6: true
      return_code: 127.0.0.43
      weight: 10

    - name: AbusiX AuthBL
      rbl: YOUR-API-KEY.authbl.mail.abusix.zone
      ipv4: true
      ipv6: true
      return_code: 127.0.0.4
      weight: 10

  ip_whitelist:
    - 127.0.0.0/8
    - ::1
    - 192.168.0.0/16
    - 172.16.0.0/12
    - 10.0.0.0/8
    - fd00::/8
    - 169.254.0.0/16
    - fe80::/10

cleartext_networks:
  - 127.0.0.0/8
  - ::1
  - 192.168.0.200
  - 172.16.0.0/12

relay_domains:
  static:
    - domain1.tld
    - domain2.tld
    - domain3.tld

brute_force:
  ip_whitelist:
    - 127.0.0.0/8
    - ::1
    - 192.168.0.0/16
    - 172.16.0.0/12
    - 10.0.0.0/8
    - fd00::/8
    - 169.254.0.0/16
    - fe80::/10

  user_account:
    - name: ua_1d_ipv4
      period: 86400
      ipv4: true
      failed_requests: 10

    - name: ua_1d_ipv6
      period: 86400
      ipv6: true
      failed_requests: 10

  buckets:
    - name: b_1min_ipv4_32
      period: 60
      cidr: 32
      ipv4: true
      failed_requests: 10

    - name: b_1min_ipv6_128
      period: 60
      cidr: 128
      ipv6: true
      failed_requests: 10

    - name: b_1h_ipv4_24
      period: 3600
      cidr: 24
      ipv4: true
      failed_requests: 15

    - name: b_1h_ipv6_64
      period: 3600
      cidr: 64
      ipv6: true
      failed_requests: 15

    - name: b_1d_ipv4_24
      period: 86400
      cidr: 24
      ipv4: true
      failed_requests: 25

    - name: b_1d_ipv6_64
      period: 86400
      cidr: 64
      ipv6: true
      failed_requests: 25

    - name: b_1w_ipv4_24
      period: 604800
      cidr: 24
      ipv4: true
      failed_requests: 40

    - name: b_1w_ipv6_64
      period: 604800
      cidr: 64
      ipv6: true
      failed_requests: 40

oauth2:
  custom_scopes:
    - name: dovecot
      description: Some description that will be seen on the consent page
      claims:
        - name: dovecot_user
          type: string

        - name: dovecot_mailbox_home
          type: string

        - name: dovecot_mailbox_path
          type: string

        - name: dovecot_acl_groups
          type: string

  clients:
    - name: Testing
      client_id: SOME-CLIENT-ID
      subject: entryUUID
      claims:
        name: cn
        given_name: givenName
        family_name: sn
        nickname: uniqueIdentifier
        preferred_username: uniqueIdentifier
        email: mail
        groups: organizationalStatus
        dovecot_user: rnsMSDovecotUser
        dovecot_mailbox_home: rnsMSMailboxHome
        dovecot_mailbox_path: rnsMSMailPath
        dovecot_acl_groups: rnsMSACLGroups


# OpenLDAP
ldap:
  config:
    pool_size: 8
    idle_pool_size: 2

    server_uri: ldap://some.server:389/
    starttls: true
    tls_skip_verify: true
    sasl_external: true
    tls_ca_cert: /path/to/cacert.pem
    tls_client_cert: /path/to/client/cert.pem
    tls_client_key: /path/to/client/key.pem

  search:
    - protocol: http
      cache_name: http
      base_dn: ou=people,ou=it,dc=example,dc=com
      filter:
        user: |
          (|
            (uniqueIdentifier=%L{user})
            (rnsMSRecipientAddress=%L{user})
          )
      mapping:
        account_field: rnsMSDovecotUser
        attribute: rnsMSDovecotUser

    - protocol:
        - imap
        - pop3
        - lmtp
        - sieve
        - doveadm
        - indexer-worker
        - default
      cache_name: dovecot
      base_dn: ou=people,ou=it,dc=example,dc=com
      filter:
        user: |
            (&
              (objectClass=rnsMSDovecotAccount)
              (|
                (uniqueIdentifier=%L{user})
                (rnsMSRecipientAddress=%L{user})
              )
            )
        list_accounts: |
            (&
              (objectClass=rnsMSDovecotAccount)
              (rnsMSEnableDovecot=TRUE)
              (!
                (rnsMSDovecotMaster=TRUE)
              )
            )
      mapping:
        account_field: rnsMSDovecotUser
      attribute:
        - uid
        - rnsMSQuota
        - rnsMSOverQuota
        - rnsMSMailboxHome
        - rnsMSMailPath
        - rnsMSDovecotFTS
        - rnsMSDovecotFTSSolrUrl
        - rnsMSACLGroups
        - rnsMSDovecotUser

    - protocol:
        - smtp
        - submission
      cache_name: submission
      base_dn: ou=people,ou=it,dc=example,dc=com
      filter:
        user: |
            (&
              (objectClass=rnsMSPostfixAccount)
              (|
                (uniqueIdentifier=%L{user})
                (rnsMSRecipientAddress=%L{user})
              )
            )
      mapping:
        account_field: rnsMSDovecotUser
      attribute:
        - uid
        - rnsMSQuota
        - rnsMSOverQuota
        - rnsMSMailboxHome
        - rnsMSMailPath
        - rnsMSDovecotFTS
        - rnsMSDovecotFTSSolrUrl
        - rnsMSACLGroups
        - rnsMSDovecotUser

    - protocol:
        - ory-hydra
      cache_name: oauth
      base_dn: ou=people,ou=it,dc=example,dc=com
      filter:
        user: |
            (&
              (objectClass=inetOrgPerson)
              (|
                (entryUUID=%{user})
                (uid=%{user})
                (uniqueIdentifier=%L{user})
                (rnsMSRecipientAddress=%L{user})
              )
            )
      mapping:
        account_field: uid
        totp_secret_field: rns2FATOTPSecret
      attribute:
        - entryUUID
        - uid
        - cn;x-hidden
        - mail;x-hidden
        - givenName;x-hidden
        - sn;x-hidden
        - uniqueIdentifier
        - rnsMSDovecotUser
        - rnsMSMailboxHome
        - rnsMSMailPath
        - rnsMSACLGroups
        - rnsMSEnableDovecot
        - organizationalStatus
        - labeledURI;x-hidden

Structure​

Features​

General configuration settings​

Reloading​

server​

Meaning​

server::address​

server::haproxy_v2​

server::http3​

server::disabled_endpoints​

Meaning​

server::http_client​

server::tls​

server::tls::enabled​

server::tls::cert and server::tls::key​

server::tls::http_client_skip_verify​

server::basic_auth​

server::basic_auth::enabled​

server::basic_auth::username and server::basic_auth::password​

server::instance_name​

server::logs​

server::log::json​

server::log::level​

server::log::debug_modules​

server::backends​

server::features​

server::brute_force_protocols​

server::ory_hydra_admin_url​

server::dns​

server::dns::resolver​

server::dns::timeout​

server::dns::resolve_client_ip​

server::insights​

server::insights::enable_pprof​

server::insights::enable_block_profile​

server::redis​

server::redis::database_number​

server::redis::prefix​

server::redis::pool_size​

server::redis::idle_pool_size​

server::redis::positive_cache_ttl and server::redis::negative_cache_ttl​

server::redis::master​

server::redis::master::address​

server::redis::master::username and server::redis::master::password​

server::redis::replica​

server::redis::replica::address​

server::redis::replica::addresses​

server::redis::sentinels​

server::redis::sentinels::master​

server::redis::sentinels::addresses​

server::redis::sentinels::username and server::reids::sentinels::password​

server::redis::cluster​

server::redis::cluster::addresses​

server::master_user​

server::master_user::enabled​

server::master_user::delimiter​

server::frontend​

server::frontend::enabled​

server::frontend::csrf_secret​

server::frontend::cookie_store_auth_key and server::frontend::cookie_store_encryption_key​

server::prometheus_timer​

server::prometheus\timer::enabled​

server::prometheus\timer::labels​

realtime_blackhole_lists​

realtime_blackhole_lists::lists:​

realtime_blackhole_lists::threshold​

realtime_blackhole_lists::ip_whitelist​

cleartext_networks​

relay_domains​

relay_domains::static​

backend_server_monitoring​

backend_server_monitoring::backend_servers​

brute_force​

Recommendation​

brute_force::buckets​

brute_force::ip_whitelist​

brute_force::learning​

password_nonce​

oauth2​

Configuration flow​

Structure

Features

General configuration settings

Reloading

server

Meaning

server::address

server::haproxy_v2

server::http3

server::disabled_endpoints

Meaning

server::http_client

server::tls

server::tls::enabled

server::tls::cert and server::tls::key

server::tls::http_client_skip_verify

server::basic_auth

server::basic_auth::enabled

server::basic_auth::username and server::basic_auth::password

server::instance_name

server::logs

server::log::json

server::log::level

server::log::debug_modules

server::backends

server::features

server::brute_force_protocols

server::ory_hydra_admin_url

server::dns

server::dns::resolver

server::dns::timeout

server::dns::resolve_client_ip

server::insights

server::insights::enable_pprof

server::insights::enable_block_profile

server::redis

server::redis::database_number

server::redis::prefix

server::redis::pool_size

server::redis::idle_pool_size

server::redis::positive_cache_ttl and server::redis::negative_cache_ttl

server::redis::master

server::redis::master::address

server::redis::master::username and server::redis::master::password

server::redis::replica

server::redis::replica::address

server::redis::replica::addresses

server::redis::sentinels

server::redis::sentinels::master

server::redis::sentinels::addresses

server::redis::sentinels::username and server::reids::sentinels::password

server::redis::cluster

server::redis::cluster::addresses

server::master_user

server::master_user::enabled

server::master_user::delimiter

server::frontend

server::frontend::enabled

server::frontend::csrf_secret

server::frontend::cookie_store_auth_key and server::frontend::cookie_store_encryption_key

server::prometheus_timer

server::prometheus\timer::enabled

server::prometheus\timer::labels

realtime_blackhole_lists

realtime_blackhole_lists::lists:

realtime_blackhole_lists::threshold

realtime_blackhole_lists::ip_whitelist

cleartext_networks

relay_domains

relay_domains::static

backend_server_monitoring

backend_server_monitoring::backend_servers

brute_force

Recommendation

brute_force::buckets

brute_force::ip_whitelist

brute_force::learning

password_nonce

oauth2

Configuration flow