feat(tls): add an option for optional TLS client authentication #1163
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously there were only two options for client authentication – either no authentication or mandatory authentication. With this change, a server can allow for optional authentication with a given root CA certificate and enforce client authentication on a per-request basis.
Refs: #687
Motivation
Currently, there is no easy way of performing client authentication on a per-request basis with the API provided by
ServerTlsConfig
. This behavior is useful in scenarios like the one described in #687, i.e., when some endpoints should be publicly accessible while others not.Solution
Since
rustls
providesClientCertVerifier
with the desired behavior, it only needs to be made accessible fromServerTlsConfig
. Currently, when the methodclient_ca_cert
is called on aServerTlsConfig
, it forces mandatory client authentication with a given root CA certificate.I propose to rename this method and change its input to a three-valued enum – no authentication (default), optional authentication with a provided root CA certificate, and mandatory authentication with a provided root CA certificate. I understand this is a breaking change, but it seems like a much cleaner solution than introducing a new method along
client_ca_certificate
that would set someoptional
flag inServerTlsConfig
, since the flag would have no meaning if theclient_ca_certificate
was not used.