Lamine created SOLR-17308:
-----------------------------
Summary: Proposal to enhance Solr certificate-based authentication
(mTLS)
Key: SOLR-17308
URL: https://issues.apache.org/jira/browse/SOLR-17308
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: Authentication
Reporter: Lamine
TL;DR
Two proposed enhancements:
1. Flexibility to extract the Principal.
2. Identity check for security enhancement.
---
Solr supports certificate-based authentication (mTLS) via the CertAuthPlugin.
However, the feature offers limited flexibility and probably poses a potential
security vulnerabilities. In fact, the class contains minimal code, primarily
deferring certificate validation to Jetty and extracting the _Principal_ from
the subject's Distinguish Name (DN). The Authorization plugin then maps the
extracted _Principal_ to a role.
I've identified a couple of issues with this approach, as well as potential
areas for enhancement:
*1- Issues with Using DN*
- {*}Length and precision{*}: The DN is lengthy and requires an exact match for
roles mapping. Even a minor discrepancy, like an extra space, or order of
attributes (RDN), can break the mapping.
- {*}One DN per certificate{*}: If different certificates are used for
different hosts in a cluster, each DN has to be mapped separately to a
particular role, complicating role mapping and increasing risks of errors.
- {*}Not customizable{*}: The current implementation doesn't allow operators to
adapt the Principal extracting to their specific needs.
- {*}Bad user experience{*}: When logged into Solr Admin UI using
CertAuthPlugin the whole DN is displayed on the left menu as the 'username'.
_*Proposed Solution for DN Issues:*_
- Extraction flexibility: Grant operators the ability to specify the data they
wish to extract for the _Principal_, based on a defined path (for example:
_SUBJECT.DN_ (default), _SAN.URI_, _SAN.email_, etc.).
- Use of delimiters: Introduce optional delimiters (start and end) or
prefix/suffix to extract only the necessary data from a field, for example a
group ID.
*2- Concerns with certificate validation*
Over-reliance on cert validation: The current implementation allows any client
with a valid certificate (CA trusted) to authenticate, although not necessarily
getting authorized, leading to potential security lapses.
_*Proposed solution for certificate validation*_
- Identity check: Introduce a mechanism to verify the certificate's identity.
Extract the identity from the certificate based on a admin-configurable path,
such as SAN.URI, SAN.dNSName, etc.
- Establish an _allowedValues_ option: Once extracted, the identity should
match values from a predefined allowed list, ensuring only approved entities
can authenticate.
- Other more advanced features such as relying on serial number or fingerprint
are still possible.
I'd love to hear what you think.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
