I closed the 4479 PR and revised the 4474 PR to add the fallback, as suggested.
Jean-Marie Le lun. 1 juin 2026 à 14:47, Jean-Marie HEITZ <[email protected]> a écrit : > 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) >> >> >> >> >> >> >> >> > >
