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.
Before this fix an anonymous user was not able to access a resource
that were configured with a bypass policy. This was due to a useless
check of the userid in the auth session. Moreover, in the case of an
anonymous user, we should not check the inactivity period since there
is no session.
Also refactor /verify endpoint for better testability and add tests
in a new suite.
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.
In order to redirect the user after authentication, Authelia uses
rd query parameter provided by the proxy. However an attacker could
use phishing to make the user be redirected to a bad domain. In order
to avoid the user to be redirected to a bad location, Authelia now
verifies the redirection URL is under the protected domain.
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.
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.
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.
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.
Client and server now have their own tsconfig so that the transpilation is only
done on the part that is being modified.
It also allows faster transpilation since tests are now excluded from tsconfig.
They are compiled by ts-node during unit tests execution.
