I understand your point of view : I agree the fallback would be easier to implement and I assume it may fit most use cases.
At the time I wrote the pull requests, I had thought over it, and I was not comfortable with a fallback, as it means you might have two "sources of truth" for authentication that might be used at the same time (however I can be wrong as I do not have enough experience about this subject) : that is how I ended with two different kind of solutions : use the new standard for new releases (4474) or let administrators be able to configure the plugin for their specific use case (4479). But I remain open to the fallback if it fits after all. Jean-Marie Le lun. 1 juin 2026 à 03:23, lamine lamine via users <[email protected]> a écrit : > you should have one PR per issue. > I'd choose the first one (4474) with probably a fallback to javax > Lamine > Le samedi 30 mai 2026 à 16:17:52 UTC−5, Jean-Marie HEITZ < > [email protected]> a écrit : > > I published two PR : https://github.com/apache/solr/pull/4474 and > https://github.com/apache/solr/pull/4479 . The first just updates the > attribute name, while the second introduces a new configuration parameter > for security.json. > > I enabled the patch review in the Jira issue. Is there something more that > I should do (these PR are my first ones on this project) ? > > Thanks > > Jean-Marie > > Le ven. 29 mai 2026 à 13:34, Jean-Marie HEITZ <[email protected]> a > écrit : > > > Thanks for the JIRA account. I have just created the issue ( > > https://issues.apache.org/jira/browse/SOLR-18270). I am working on > > the pull requests. > > > > Jean-Marie > > > > Le ven. 29 mai 2026 à 12:37, Jan Høydahl <[email protected]> a > écrit : > > > >> I approved your JIRA request. Thanks for contributing a fix. That will > be > >> really helpful! > >> > >> Jan > >> > >> > 29. mai 2026 kl. 09:38 skrev Jean-Marie HEITZ <[email protected]>: > >> > > >> > I prepared two branches, one with the simple adjustment ( > >> > https://github.com/heitzjm/solr/tree/CERT_AUTH_PLUGIN_EASY) and > another > >> > which expose a parameter ( > >> > > >> > https://github.com/heitzjm/solr/tree/CERT_AUTH_PLUGIN_REQUEST_ATTRIBUTE_PARAM > >> ). > >> > I applied for a Jira account a few hours ago, so I guess it is just a > >> > matter of time until I am able to open an issue and then make a PR > >> > referencing the issue. > >> > > >> > Le jeu. 28 mai 2026 à 20:47, Gus Heck <[email protected]> a écrit : > >> > > >> >> That sounds like a bug. Creating a JIRA and a PR would be helpful if > >> you > >> >> are able. > >> >> > >> >> On Thu, May 28, 2026 at 5:43 AM Jean-Marie HEITZ <[email protected] > > > >> >> wrote: > >> >> > >> >>> Good morning, > >> >>> > >> >>> While trying to migrate from SOLR 9 to 10 using the official Docker > >> >> images, > >> >>> I noticed that authentication using SSL certificates did not work > >> >> anymore. > >> >>> I found out that, as I was using SOLR_SSL_NEED_CLIENT_AUTH, and that > >> the > >> >>> SSL connection level does work and is established, the request > >> attribute > >> >>> that carries the client cert is not > >> >>> "javax.servlet.request.X509Certificate" anymore in jetty-12, which > is > >> >> used > >> >>> in the Official SOLR Docker image : it > >> >>> became "jakarta.servlet.request.X509Certificate". I tested the > >> attribute > >> >>> change by building SOLR and the Docker Image from source : it > worked. > >> So > >> >> I > >> >>> guess it might be good to change, or add a parameter to be able to > >> >>> configure the lookup attribute in security.json. > >> >>> Can someone have a look ? > >> >>> > >> >>> Besides that, I also tried the CertAuthPlugin User Principal > >> Extraction , > >> >>> and noticed something strange with the "subject.dn" path : the order > >> of > >> >> the > >> >>> components in the Distinguished Name was not the same as the default > >> >>> method. In detail : > >> >>> - openssl x509 -text outputs O, OU and then CN for the SSL > certificate > >> >>> - CertAuthPlugin.DEFAULT_PRINCIPAL_RESOLVER gives CN, OU, O > >> >>> - Extraction with "subject.dn" gives CN, O, OU > >> >>> I assume the Role Based Authorization Plugin uses the principal > >> >> extraction > >> >>> as a string, so the order of the elements does matter. However, I > >> haven't > >> >>> investigated this behavior further yet. > >> >>> > >> >>> Thanks > >> >>> > >> >>> Jean-Marie Heitz > >> >>> > >> >> > >> >> > >> >> -- > >> >> http://www.needhamsoftware.com (work) > >> >> https://a.co/d/b2sZLD9 (my fantasy fiction book) > >> >> > >> > >> >
