Authelia 4.37 is just around the corner. This version has several additional features and improvements to existing features. In this blog post we’ll discuss the new features and roughly what it means for users.
Note: These features are still subject to change however it represents the most likely features.
This blog entry (and technically the blog itself) is part of a new effort I’m making for which I’m not entirely sure how useful it’ll be but I’d love to hear your feedback regardless. We don’t use any analytics or interactive components to gauge the consumption or reception of the website so it is invaluable to get this feedback.
OpenID Connect Improvements
Several items from the OpenID Connect Roadmap are being checked off in this release.
Hashed Client Secrets
We’ll be supporting hashed OpenID Connect client secrets in this release. People will still be able to use plaintext secrets if they wish however we’ll be recommending people utilize PBKDF2, BCrypt or SHA512 SHA2CRYPT (see Password Algorithms for a full compatibility list). This doesn’t change anything for OpenID Connect Relying Parties, it only requires a change in the Authelia configuration.
Currently we support an explicit consent mode, and a pre-configured consent mode if the pre-configured duration is set. In this release we’re planning to support an implicit consent mode which will never ask users for any consent. In addition it will make the consent mode configuration slightly more explicit.
JWKS Certificate Chain
Currently we do not support JWKS certificates, we only support private keys. We will support advertising the Certificate Chain via the JWKS endpoint in this release. This means when provided with a Certificate Chain will be able to theoretically validate the level of trust associated with the JWKS.
Some applications theoretically require this, most probably don’t support it at all. However the beauty of this change is that if it’s not supported by the other party they can just ignore it. We’ve yet to have users request this but it’s likely inevitable that someone will ask or some third party will require it at some point, so we’re preemptively implementing it.
Container Annotations / Labels
For the time being we will also add the Annotations as container labels. This is because Annotations are a relatively unsupported specification at this stage. A majority of use cases for the Annotations either actually use labels or fallback to labels.
Several new password hashing algorithms will be supported in this release. The list of supported algorithms will become:
- Argon2id (previously supported)
- SHA2 CRYPT:
- SHA512 (previously supported)
Users YAML File Authentication Backend
In addition to the Password Algorithms changes we’ll also be adding a few major features to the Users YAML File Authentication Backend.
Administrators will be able to allow automatic reload the YAML file with the users database for deployments of the YAML File backend. This change will not extend to the main configuration file at this time.
Administrators will be able to allow users to use their email or their username to login similar to how this can be done with an LDAP filter already, bringing feature parity to the YAML File backend.
Mutual TLS Support
This release will add support for Mutual TLS for Redis, LDAP, and SMTP. This improves compatibility with these systems when password authentication is not desired.
Query Parameter Authorization Criteria
We’ll be adding a very specific query parameter matcher to the access control rules in this release. It will allow individually targeting specific query arguments and testing if they exist/don’t exist, equal/don’t equal a value, or if they match/don’t match a specific Regular Expression.
This rule type takes a performance hit when compared to the resources rule type, so the resources rule type is generally encouraged. However for complex matching of query parameters a Regular Expression is hard to get exactly right. This feature alleviates this issue.
Compatibility Features are toggle on features which allows operation with a third party. Usually they’re implemented to allow ignoring a specific specification the third party has not implemented correctly.
We’ll be adding the following compatibility features in this release:
- LDAP Servers which do not support querying the RootDSE for supported controls or extensions.
- SMTP Servers which advertise support for STARTTLS but do not actually support it.