docs(authorizer): important headers for access-control networks (#1794)

* Document X-Forwarded-For capabilities within access-control networks

Adds a short paragraph detailing X-Forwarded-For header behaviour
into the documentation.

* Update docs/configuration/access-control.md

Co-authored-by: James Elliott <james-d-elliott@users.noreply.github.com>

Co-authored-by: James Elliott <james-d-elliott@users.noreply.github.com>
pull/1800/head^2
David Chidell 2021-03-10 23:18:39 +00:00 committed by GitHub
parent c4864ca64c
commit 5cf11f87c8
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 3 additions and 0 deletions

View File

@ -139,6 +139,9 @@ A list of network addresses, ranges (CIDR notation) or groups can be specified i
policies when requests originate from different networks. This list can contain both literal definitions of networks policies when requests originate from different networks. This list can contain both literal definitions of networks
and [network aliases](#network-aliases). and [network aliases](#network-aliases).
Network addresses specified will be matched against the first IP in the X-Forwarded-For, and if there is none it will fall back to the IP address of the request. If using Authelia with a reverse proxy, additional configuration
may be required on the reverse proxy to ensure these headers are present and correct.
Main use cases for this rule option is to adjust the security requirements of a resource based on the location of Main use cases for this rule option is to adjust the security requirements of a resource based on the location of
the user. For example lets say a resource should be exposed both on the Internet and from an the user. For example lets say a resource should be exposed both on the Internet and from an
authenticated VPN for instance. Passing a second factor a first time to get access to the VPN and authenticated VPN for instance. Passing a second factor a first time to get access to the VPN and