In order to simplify the deployment of Authelia for
testing, LDAP is now optional made optional thanks
to users database stored in a file. One can update
the file manually even while Authelia is running.
With this feature the minimal configuration requires
only two components: Authelia and nginx.
The users database is obviously made for development
environments only as it prevents Authelia to be scaled
to more than one instance.
Note: Configuration has been updated. Key `ldap` has
been nested in `authentication_backend`.
This commit should fix#225.
In order to avoid stalling LDAP connections, Authelia creates new
sessions for each set of queries bound to one authentication, i.e.,
one session for authentication, emails retrieval and groups
retrieval.
Before this commit, a failing query was preventing the session to
be closed (unbind was not called). Now, unbind is always called
whatever the outcome of the query.
I took the opportunity of this commit to refactor LDAP client in
order to prepare the work on users database stored in a file.
(#233)
Before this patch, when Authelia started, if Mongo was not
up and running, Authelia failed to connect and never retried.
Now, everytime Authelia faces a broken connection, it tries
to reconnect during the next operation.
Currently notifications reflow the document which causes the interface
to jump twice which can be frustrating if you're trying to click
something.
This change makes the notification appear at the top of the form as
such:
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.
A link to U2F explains what is a U2F security key and how they are used.
A tooltip on U2F device registration link is telling the user he needs a
security key to register.
The u2f-api package does not use the official u2f script provided by Yubikey.
Unfortunately, it was blocked by Firefox. This change reintroduces the
official u2f script.
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.
Issuer is customizable in configuration so that a company can set its own name
or website. If not provided, default value is 'authelia.com'.
The username is used as label.
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.
This URL is used when user access the authentication domain without providing
the 'redirect' query parameter. In that case, Authelia does not know
where to redirect the user.
If the parameter is defined, Authelia can redirect the user to a default page
when no redirect parameter is provided.
When user is already authenticated and tries to access the authentication
domain, the "already logged in" page is rendered and it now tells the user he
is to be redirected in few seconds and uses this URL to redirect.
This parameter is optional. If it is not provided, there is only a notification
message at the end of the authentication process, as before, and the user is
not redirected when visiting the authentication domain while already
authenticated.
