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.
This timeout will prevent an attacker from using a session that has been
inactive for too long.
This inactivity timeout combined with the timeout before expiration makes a
good combination of security mechanisms to prevent session theft.
If no activity timeout is provided, then the feature is disabled and only
session expiration remains as a protection.
This refactoring aims to ease testability and clean up a lot of soft touchy
typings in test code.
This is the first step of this refactoring introducing the concept and
implementing missing interfaces and stubs. At the end of the day,
ServerVariablesHandler should completely disappear and every variable should
be injected in the endpoint handler builder itself.
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.
Sometimes, LDAP organization is such that groups membership cannot be computed
with username only. User DN is required to retrieve groups.
e.g. user Joe has a username joe and a cn of Joe Blogs, resulting in a dn of
cn=Joe Blogs,ou=users,dc=example,dc=com which is needed to retrieve groups
but cannot be computed from joe only.
Issue was reported in issue #146
A window of 1 means the token is checked against current time slot T
as well as at time slot T-1 and T+1.
A time slot is 30 seconds by default in Authelia.
Now, /verify can return 401 or 403 depending on the user authentication.
Every public API endpoints and pages return 200 with error message in
JSON body or 401 if the user is not authorized.
This policy makes it complicated for an attacker to know what is the source of
the failure and hide server-side bugs (not returning 500), bugs being potential
threats.
Example 1: The user has validated first factor when accessing a service
protected by basic auth. When he tries to access another service protected
by second factor, he is redirected to second factor step to complete
authentication.
Example 2: The user has already validated second factor. When he access auth
service, he is redirected either to /loggedin page that displays an "already
logged in" page or to the URL provided in the "redirect" query parameter.
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.
