This adds a feature to OpenID Connect 1.0 where clients can be restricted to a specific client authentication mode, as well as implements some backend requirements for the private_key_jwt client authentication mode (and potentially the tls_client_auth / self_signed_tls_client_auth client authentication modes). It also adds some improvements to configuration defaults and validations which will for now be warnings but likely be made into errors.
Signed-off-by: James Elliott <james-d-elliott@users.noreply.github.com>
This adds support to configure multiple session cookie domains.
Closes#1198
Co-authored-by: James Elliott <james-d-elliott@users.noreply.github.com>
Co-authored-by: Amir Zarrinkafsh <nightah@me.com>
This adds multiple consent modes to OpenID Connect clients. Specifically it allows configuration of a new consent mode called implicit which never asks for user consent.
This moves the OpenID Connect storage from memory into the SQL storage, making it persistent and allowing it to be used with clustered deployments like the rest of Authelia.
This adjusts the not found handler to not respond with a 404 on not found endpoints that are part of the /api or /.well-known folders, and respond with a 405 when the method isn't implemented.
Co-authored-by: Amir Zarrinkafsh <nightah@me.com>
This utilizes the referrer query parameters instead of current request query parameters for logging the requested URI and method. Minor performance improvements to header peek/sets.
This adds additional logging to the authentication logs such as type, remote IP, request method, redirect URL, and if the attempt was done during a ban. This also means we log attempts that occur when the attempt was blocked by the regulator for record keeping purposes, as well as record 2FA attempts which can be used to inform admins and later to regulate based on other factors.
Fixes#116, Fixes#1293.
* refactor(handlers): lower case error messages
also refactor verifyAuth function to detect malicious activity both with session
cookie and authorization header.
* refacto(handlers): simplify error construction
* fix(handlers): check prefix in authorization header to determine auth method
* fix(handlers): determining the method should be done with headers instead of query arg
* refacto(handlers): rollback changes of verifyAuth
* don't lowercase log messages
* Apply suggestions from code review
Make sure logger errors are not lowercased.
* fix: uppercase logger errors and remove unused param
* Do not lowercase logger errors
* Remove unused param targetURL
* Rename url variable to not conflict with imported package
Co-authored-by: Amir Zarrinkafsh <nightah@me.com>
* fix: oidc issuer path and strip path middleware
This ensures the server.path requests append the base_url to the oidc well-known issuer information and adjusts server.path configuration to only strip the configured path instead of the first level entirely regardless of its content.
* fix: only log the token error and general refactoring
* refactor: factorize base_url functions
* refactor(server): include all paths in startup logging
* refactor: factorize
* refactor: GetExternalRootURL -> ExternalRootURL
Co-authored-by: James Elliott <james-d-elliott@users.noreply.github.com>
* This gives admins more control over their OIDC installation exposing options that had defaults before. Things like lifespans for authorize codes, access tokens, id tokens, refresh tokens, a option to enable the debug client messages, minimum parameter entropy. It also allows admins to configure the response modes.
* Additionally this records specific values about a users session indicating when they performed a specific authz factor so this is represented in the token accurately.
* Lastly we also implemented a OIDC key manager which calculates the kid for jwk's using the SHA1 digest instead of being static, or more specifically the first 7 chars. As per https://datatracker.ietf.org/doc/html/draft-ietf-jose-json-web-key#section-8.1.1 the kid should not exceed 8 chars. While it's allowed to exceed 8 chars, it must only be done so with a compelling reason, which we do not have.
OpenID connect has become a standard when it comes to authentication and
in order to fix a security concern around forwarding authentication and authorization information
it has been decided to add support for it.
This feature is in beta version and only enabled when there is a configuration for it.
Before enabling it in production, please consider that it's in beta with potential bugs and that there
are several production critical features still missing such as all OIDC related data is stored in
configuration or memory. This means you are potentially going to experience issues with HA
deployments, or when restarting a single instance specifically related to OIDC.
We are still working on adding the remaining set of features before making it GA as soon as possible.
Related to #189
Co-authored-by: Clement Michaud <clement.michaud34@gmail.com>
* [MISC] Refactor and address most errcheck linter ignores
This is mostly a quality of life change.
When we first implemented the errcheck linter we ignored a number of items in our legacy codebase with intent to revisit down the track.
* Handle errors for regulation marks and remove unnecessary logging
* [FIX] Send correct HTTP status codes for 1FA
* use harmonious func to handle all 1FA attempt errors
* use same harmonious func to handle 2FA attempt errors
* always send a 401 which is correct according to https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401
* fix tests
* refactor isTargetURLAuthorized
* fix padding and imports
* harmonize remaining return messages
* fixup docs and layout of verifySessionHasUpToDateProfile
* [MISC] Ignore errcheck recommendations for legacy code
Some of this is likely intended to stay how it is, some could use refactoring, for now we will mark is and ignore it from the linter to be potentially addressed in the future.
* [MISC] Ensure files are gofmt-ed
When no rule is set to two_factor in ACL configuration, 2FA is
considered disabled. Therefore, when a user cannot be redirected
correctly because no target URL is provided or the URL is unsafe,
the user is either redirected to the default URL or to the
'already authenticated' view instead of the second factor view.
Fixes#683
* Redirect to default URL after 1FA when default policy is one_factor.
User is now redirected to the default redirection URL after 1FA if
the default policy is set to one_factor and there is no target URL
or if the target URL is unsafe.
Also, if the default policy is set to one_factor and the user is already
authenticated, if she visits the login portal, the 'already authenticated'
view is displayed with a logout button.
This fixes#581.
* Update users.yml
* Fix permissions issue causing suite test failure
* Remove unused mongo docker-compose file.
* Default redirection URL was not taken into account.
* Fix possible storage options in config template.
* Remove useless checks in u2f registration endpoints.
* Add default redirection url in config of duo suite.
* Fix log line in response handler of 2FA methods.
* Fix integration tests.
Co-authored-by: Amir Zarrinkafsh <nightah@me.com>
James Elliott
Manuel Nuñez
Clément Michaud
Amir Zarrinkafsh