ba65a3db82
* [FEATURE] Add auth query param to /api/verify (#1353) When `/api/verify` is called with `?auth=basic`, use the standard Authorization header instead of Proxy-Authorization. * [FIX] Better basic auth error reporting * [FIX] Return 401 when using basic auth instead of redirecting * [TESTS] Add tests for auth=basic query param * [DOCS] Mention auth=basic argument and provide nginx example * docs: add/adjust basic auth query arg docs for proxies Co-authored-by: Amir Zarrinkafsh <nightah@me.com>
3.0 KiB
| layout | title | parent | nav_order |
|---|---|---|---|
| default | Single Factor | Features | 3 |
Single Factor
Authelia supports single factor authentication to let applications send authenticated requests to other applications.
Single or two-factor authentication can be configured per resource of an application for flexibility.
For instance, you can configure Authelia to grant access to all resources
matching app1.example.com/api/(.*) with only a single factor and all
resources matching app1.example.com/admin with two factors.
To know more about the configuration of the feature, please visit the documentation about the configuration.
HTTP Basic Auth
Authelia supports two different methods for basic auth.
Proxy-Authorization header
Authelia reads credentials from the header Proxy-Authorization instead of
the usual Authorization header. This is because in some circumstances both Authelia
and the application could require authentication in order to provide specific
authorizations at the level of the application.
API argument
If instead of the Proxy-Authorization header you want, or need, to use the more
conventional Authorization header, you should then configure your reverse-proxy
to use /api/verify?auth=basic.
When authentication fails and auth=basic was set, Authelia's response will include
the WWW-Authenticate header. This will cause browsers to prompt for authentication,
and users will not land on the HTML login page.
Session-Username header
Authelia by default only verifies the cookie and the associated user with that cookie can access a protected resource. The client browser does not know the username and does not send this to Authelia, it's stored by Authelia for security reasons.
The Session-Username header has been implemented as a means to use Authelia with non-web services such as PAM. Basically how it works is if the Session-Username header is sent in the request to the /api/verify endpoint it will only respond with a sucess message if the cookie username and the header username match.
Example
These examples are for demonstration purposes only, the original use case and full instructions are described here. You will need to adjust the FORWARDED_HOST and VERIFY_URL vars to achieve a functional result.
PAM Rule
auth [success=1 default=ignore] pam_exec.so expose_authtok /usr/bin/pam-authelia
PAM Script
#!/bin/bash
# The password from stdin
PAM_PASSWORD=$(cat -)
# url from which authelia session key was created
FORWARDED_HOST=auth.example.com
# internal path to verify api
VERIFY_URL=http://127.0.0.1:80/api/verify
AUTH_RESULT=$(curl -b "authelia_session=${PAM_PASSWORD}" -H "Session-Username: ${PAM_USER}" -H "X-Forwarded-Host: ${FORWARDED_HOST}" -H "X-Forwarded-Proto: https" -s -o /dev/null -I -w "%{http_code}" -L "${VERIFY_URL}")
if [[ "$AUTH_RESULT" == 200 ]]; then
echo "Auth verify ok"
exit 0
else
echo "Auth verify failed $AUTH_RESULT"
exit 1
fi