Running this suite is the first advice given by the
bootstrap script to help the user move forward.
This commit also updates the documentation to reflect
changes introduced by the Go rewrite.
This is going to be the v4.
Expected improvements:
- More reliable due to static typing.
- Bump of performance.
- Improvement of logging.
- Authelia can be shipped as a single binary.
- Will likely work on ARM architecture.
* Removal of the Redirect header sent by Authelia /api/verify endpoint.
* Authelia does not consume Host header anymore but X-Forwarded-Proto and X-Forwarded-Host
to compute the link sent in identity verification emails.
* Authelia used Host header as the application name for U2F authentication but it's now using
X-Forwarded-* headers.
This is to allow broader support for proxies. In particular, this allows
support with Traefik.
This patch also includes some examples of configuration with Traefik.
Authelia was using links with href="#" that changed the URL when clicked
on. Therefore, this commit removes the href property and apply link style
to tags without href property.
Displaying only one option at 2FA stage will allow to add more options
like DUO push or OAuth.
The user can switch to other option and in this case the option is
remembered so that next time, the user will see the same option. The
latest option is considered as the prefered option by Authelia.
Authelia client uses hash router instead of browser router in order to work
with Kubernetes nginx-ingress-controller. This is also better for users having
old browsers.
This commit is breaking because it requires to change the configuration of the
proxy to include the # in the URL of the login portal.
On some LDAP servers, the `uid` attribute is more like a guid, while the
username exists instead in a dedicated field, like `username`. This
means the `uid` is not necessarily equal to `username`.
This is allows referencing using the `uid` to search for groups in the same
way as `dn` so that one can explicitly match the `memberuid` to the `uid` for
the user without the assumptions that come with using `{0}`.
Traefik handles auth forwarding but does not manage redirections like Nginx.
Therefore, Authelia must redirect the user and Traefik will forward this
request.
To support both Nginx and Traefik, /api/verify is now configurable with the
'redirect' get parameter. If the verification fails and 'redirect' is not
provided the response will be a 401 error as before.
If the parameter is provided and set to any URL, the response will be a
redirection (302) to this URL.
One can now access a service using the basic authorization mechanism. Note the
service must not be protected by 2 factors.
The Remote-User and Remote-Groups are forwarded from Authelia like any browser
authentication.
From this commit on, api endpoints reply with a 401 error code and non api
endpoints redirect to /error/40X.
This commit also fixes missing restrictions on /loggedin (the "already logged
in page). This was not a security issue, though.
The change also makes error pages automatically redirect the user after few
seconds based on the referrer or the default_redirection_url if provided in the
configuration.
Warning: The old /verify endpoint of the REST API has moved to /api/verify.
You will need to update your nginx configuration to take this change into
account.
Uses the crypt() function to do password encryption. This function handles
several schemes such as: MD5, Blowfish, SHA1, SHA2.
SHA-512 is used in Authelia for best security.
The algorithm is fully described in
https://www.akkadia.org/drepper/SHA-crypt.txt
The 'crypt3' npm package has been added as a dependency to use the crypt()
function. The package needs to be compiled in order to call the c function,
that's why python, make and C++ compiler are installed temporarily in the
Docker image.
These are 2 measures for improving security of cookies. One is used to
not send the cookie over HTTP (only HTTPS) and the other tells the browser to
disallow client-side code accessing the cookie.
One can now customize the default authentication method for all sub-domains,
i.e., either 'two_factor' or 'basic_auth' and define specific authentication
method per sub-domain.
For example, one can specify that every sub-domain must be authenticated with
two factor except one sub-domain that must be authenticated with basic auth.
