26369fff3d
* [FEATURE] Support Argon2id Passwords
- Updated go module github.com/simia-tech/crypt
- Added Argon2id support for file based authentication backend
- Made it the default method
- Made it so backwards compatibility with SHA512 exists
- Force seeding of the random string generator used for salts to ensure they are all different
- Added command params to the authelia hash-password command
- Automatically remove {CRYPT} from hashes as they are updated
- Automatically change hashes when they are updated to the configured algorithm
- Made the hashing algorithm parameters completely configurable
- Added reasonably comprehensive test suites
- Updated docs
- Updated config template
* Adjust error output
* Fix unit test
* Add unit tests and argon2 version check
* Fix new unit tests
* Update docs, added tests
* Implement configurable values and more comprehensive testing
* Added cmd params to hash_password, updated docs, misc fixes
* More detailed error for cmd, fixed a typo
* Fixed cmd flag error, minor refactoring
* Requested Changes and Minor refactoring
* Increase entropy
* Update docs for entropy changes
* Refactor to reduce nesting and easier code maintenance
* Cleanup Errors (uniformity for the function call)
* Check salt length, fix docs
* Add Base64 string validation for argon2id
* Cleanup and Finalization
- Moved RandomString function from ./internal/authentication/password_hash.go to ./internal/utils/strings.go
- Added SplitStringToArrayOfStrings func that splits strings into an array with a fixed max string len
- Fixed an error in validator that would allow a zero salt length
- Added a test to verify the upstream crypt module supports our defined random salt chars
- Updated docs
- Removed unused "HashingAlgorithm" string type
* Update crypt go mod, support argon2id key length and major refactor
* Config Template Update, Final Tests
* Use schema defaults for hash-password cmd
* Iterations check
* Docs requested changes
* Test Coverage, suggested edits
* Wording edit
* Doc changes
* Default sanity changes
* Default sanity changes - docs
* CI Sanity changes
* Memory in MB
1.9 KiB
| layout | title | parent | nav_order | has_children |
|---|---|---|---|---|
| default | Proxy Integration | Deployment | 4 | true |
Integration with proxies
Authelia works in collaboration with reverse proxies. In the sub-pages you can find the documentation of the configuration required for every supported proxy.
If you are not aware of the workflow of an authentication request, reading this documentation first is highly recommended.
How Authelia integrates with proxies?
Authelia takes authentication requests coming from the proxy and targeting the
/api/verify endpoint exposed by Authelia. Two pieces of information are required for
Authelia to be able to authenticate the user request:
- The session cookie or a
Proxy-Authorizationheader (see single factor authentication). - The target URL of the user request (used primarily for access control).
The target URL can be provided using one of the following ways:
- With
X-Original-URLheader containing the complete URL of the initial request. - With a combination of
X-Forwarded-Proto,X-Forwarded-HostandX-Forwarded-URIheaders.
In the case of Traefik, those headers are automatically provided and therefore don't appear in the configuration examples.
Redirection to the login portal
The endpoint /api/verify has different behaviors depending on whether
the rd (for redirection) query parameter is provided.
If redirection parameter is provided and contains the URL to the login portal served by Authelia, the request will either generate a 200 response if the request is authenticated or perform a redirection (302 response) to the login portal if not authenticated yet.
If no redirection parameter is provided, the response code is either 200 or 401. The redirection must then be handled by the proxy when an error is detected (see nginx example).