3.0 KiB

Raw Blame History

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

3.0 KiB Raw Blame History