[
https://issues.apache.org/jira/browse/CONNECTORS-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17007319#comment-17007319
]
Karl Wright commented on CONNECTORS-1629:
-----------------------------------------
Hi,
{quote}
About the ModifiedSolrClient - do I understand you correctly that you would
prefer to make the ModifiedSolrClient working in this setting as well? Ie by
creating a new ModifiedSolrClientKerberos and ModifiedLBSolrClientKerberos (not
touching the ones already in Manifold)? I can look at this, but I wonder if
this would still be needed as I did not observe any errors. Maybe the multipart
bit is fixed in higher Solr versions?
{quote}
I wish the multipart code was fixed but I fear it is not; I tried to get the
HttpClient team to agree to it but there was disagreement and I didn't get past
that. It's so long ago now that I don't even remember the discussion well, but
some team members thought that it was not the client's responsibility to
properly escape argument names when they were encoded in some cases but not in
others. If you are including metadata names and values that would require
encoding and this is working OK, then maybe this was resolved. But we should
evaluate that independently.
The multipart fix was only PART of the reason for ModifiedSolrHttpClient,
however. The other reason was that the Solr team essentially deprecated and
removed support for multipart posts entirely, which meant that streaming of
large documents to solr was not possible. I've kept that working and called
for them to rethink that problem, at which point I was told that nobody should
be using Solr Cell at all (!) So that stays until the Solr team figures this
out. The conversation there was at least relatively recent.
A github pull is fine. A diff gets generated by attaching a ".diff" to the URL
and then I can patch in svn.
> Support Solr Kerberos Authentication
> ------------------------------------
>
> Key: CONNECTORS-1629
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1629
> Project: ManifoldCF
> Issue Type: Improvement
> Components: Solr 7.x component
> Affects Versions: ManifoldCF 2.14
> Reporter: Jörn Franke
> Priority: Major
>
> Several enterprise deployments of Solr are leveraging SolrCloud Kerberos
> authentication.
> The integration seems to be rather simple and the goal of this Jira is to
> evaluate the possential needed step to eventually contribute the Kerberos
> integration to the ManifoldCF project.
> The following steps would be needed:
> * One can pass the JVM parameter java.security.auth.login.config to the
> ManifoldCF JVM using -Djava.security.auth.login.config=/path/to/jaas.confg in
> which Kerberos authentication details, such as keytab and principal that has
> the right access to Solr is configured
> * A small adaption to the SolrCloudClient that is used within Manifold needs
> to be done to enable Kerberos authentication:
> HttpClientUtil.setConfigurer(new Krb5HttpClientConfigurer());
> Should this be integrated in Manifold, one may want to consider one input
> field in the configuration in the UI where one can select / flow which user
> defined in the Jaas conf (you can define multiple one) should be chosen. By
> default one may simply select "client" or "SolrJClient" if Jaas.conf is
> present in the System properties. This does not mean the user needs to be
> named like this, but the configuration entry referencing any user should be
> named like this.
> Having a confiugration allows to have a different users per flow. This might
> also be needed in case you have multiple Solr clusters.
> Related discussion
> [http://mail-archives.apache.org/mod_mbox/manifoldcf-user/201912.mbox/browser]
> SolrJ Kerberos integration:
> [https://lucene.apache.org/solr/guide/8_3/kerberos-authentication-plugin.html#using-solrj-with-a-kerberized-solr]
> Jaas conf documentation:
> [https://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/tutorials/LoginConfigFile.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
