[
https://issues.apache.org/jira/browse/SOLR-7468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14579636#comment-14579636
]
Gregory Chanan edited comment on SOLR-7468 at 6/9/15 10:47 PM:
---------------------------------------------------------------
Sorry for the delay, I took a look at this. Some notes below:
1) Great work [~ichattopadhyaya]! So glad to see this in Apache Solr.
2) The KerberosFilter should either check that kerberos is actually enabled
(via "type") or be a private nested class of the KerberosPlugin, to ensure it
is only used with Kerberos. That can be handled as a separate jira.
3) I'm a little concerned with the "NoContext" code in KerberosPlugin moving
forward (I understand this is more a generic auth question than kerberos
specific). For example, in the latest version of the filter we are using at
Cloudera, we play around with the ServletContext in order to pass information
around
(https://github.com/cloudera/lucene-solr/blob/cdh5-4.10.3_5.4.2/solr/core/src/java/org/apache/solr/servlet/SolrHadoopAuthenticationFilter.java#L106).
Is there any way we can get the actual ServletContext in a plugin? Again,
this doesn't need to change right now.
4)
{code}/**
43 * Test 5 nodes Solr cluster with Kerberos plugin enabled.
44 * This test is Ignored right now as Mini KDC has a known bug that
45 * doesn't allow us to run multiple nodes on the same host.
46 * https://issues.apache.org/jira/browse/HADOOP-9893
47 */
{code}
This description is a little confusing -- it sounds like you can't run multiple
MiniKDC nodes on one host, but you typically woldn't want to do that so I doubt
that is the issue. What exactly is the issue?
5)
{code}
String jaas = "Client {\n"
102 + " com.sun.security.auth.module.Krb5LoginModule required\n"
103 + " useKeyTab=true\n"
104 + " keyTab=\""+keytabFile.getAbsolutePath()+"\"\n"
105 + " storeKey=true\n"
106 + " useTicketCache=false\n"
107 + " doNotPrompt=true\n"
108 + " debug=true\n"
109 + " principal=\""+principal+"\";\n"
110 + "};\n"
111 + "Server {\n"
112 + " com.sun.security.auth.module.Krb5LoginModule required\n"
113 + " useKeyTab=true\n"
114 + " keyTab=\""+keytabFile.getAbsolutePath()+"\"\n"
115 + " storeKey=true\n"
116 + " doNotPrompt=true\n"
117 + " useTicketCache=false\n"
118 + " debug=true\n"
119 + " principal=\""+zkServerPrincipal+"\";\n"
120 + "};\n";
{code}
It would be nice if we could just create a jaas configuration and pass it to
the client, like we do in SOLR-6915. Again, nothing that needs to change now,
but having the jaas configuration management in one place (the
KerberosTestUtil) is ideal, because that code is known to be fragile, i.e.
different JVMs require different parameters, capitalization, etc. If we have
that sort of code around in different tests we won't be able to handle that.
6) {code}httpClient.addRequestInterceptor(bufferedEntityInterceptor);{code} I
think I mentioned this in a previous JIRA, but it would be nice to do some more
investigation to figure out if we can avoid this. The hadoop auth filter has
some code where you can use a cookie to avoid re-doing the
negotiate...obviously you'd only want to do that if ssl was enabled.
was (Author: gchanan):
Sorry for the delay, I took a look at this. Some notes below:
1) Great work [~ichattopadhyaya]! So glad to see this in Apache Solr.
2) The KerberosFilter should either check that kerberos is actually enabled
(via "type") or be a private nested class of the KerberosPlugin, to ensure it
is only used with Kerberos. That can be handled as a separate jira.
3) I'm a little concerned with the "NoContext" code in KerberosPlugin moving
forward (I understand this is more a generic auth question than kerberos
specific). For example, in the latest version of the filter we are using at
Cloudera, we play around with the ServletContext in order to pass information
around
(http://github.mtv.cloudera.com/CDH/lucene-solr/blob/1df8c1041fda00c82df08c03e2c07c6f346c5671/solr/core/src/java/org/apache/solr/servlet/SolrHadoopAuthenticationFilter.java#L122-L123).
Is there any way we can get the actual ServletContext in a plugin? Again,
this doesn't need to change right now.
4)
{code}/**
43 * Test 5 nodes Solr cluster with Kerberos plugin enabled.
44 * This test is Ignored right now as Mini KDC has a known bug that
45 * doesn't allow us to run multiple nodes on the same host.
46 * https://issues.apache.org/jira/browse/HADOOP-9893
47 */
{code}
This description is a little confusing -- it sounds like you can't run multiple
MiniKDC nodes on one host, but you typically woldn't want to do that so I doubt
that is the issue. What exactly is the issue?
5)
{code}
String jaas = "Client {\n"
102 + " com.sun.security.auth.module.Krb5LoginModule required\n"
103 + " useKeyTab=true\n"
104 + " keyTab=\""+keytabFile.getAbsolutePath()+"\"\n"
105 + " storeKey=true\n"
106 + " useTicketCache=false\n"
107 + " doNotPrompt=true\n"
108 + " debug=true\n"
109 + " principal=\""+principal+"\";\n"
110 + "};\n"
111 + "Server {\n"
112 + " com.sun.security.auth.module.Krb5LoginModule required\n"
113 + " useKeyTab=true\n"
114 + " keyTab=\""+keytabFile.getAbsolutePath()+"\"\n"
115 + " storeKey=true\n"
116 + " doNotPrompt=true\n"
117 + " useTicketCache=false\n"
118 + " debug=true\n"
119 + " principal=\""+zkServerPrincipal+"\";\n"
120 + "};\n";
{code}
It would be nice if we could just create a jaas configuration and pass it to
the client, like we do in SOLR-6915. Again, nothing that needs to change now,
but having the jaas configuration management in one place (the
KerberosTestUtil) is ideal, because that code is known to be fragile, i.e.
different JVMs require different parameters, capitalization, etc. If we have
that sort of code around in different tests we won't be able to handle that.
6) {code}httpClient.addRequestInterceptor(bufferedEntityInterceptor);{code} I
think I mentioned this in a previous JIRA, but it would be nice to do some more
investigation to figure out if we can avoid this. The hadoop auth filter has
some code where you can use a cookie to avoid re-doing the
negotiate...obviously you'd only want to do that if ssl was enabled.
> Kerberos authentication module
> ------------------------------
>
> Key: SOLR-7468
> URL: https://issues.apache.org/jira/browse/SOLR-7468
> Project: Solr
> Issue Type: New Feature
> Components: security
> Reporter: Ishan Chattopadhyaya
> Assignee: Anshum Gupta
> Fix For: 5.2
>
> Attachments: SOLR-7468-alt-test.patch, SOLR-7468-alt-test.patch,
> SOLR-7468-alt-test.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch,
> SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch,
> SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch,
> SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch,
> SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch,
> hoss_trunk_r1681791_TEST-org.apache.solr.cloud.TestSolrCloudWithKerberosAlt.xml,
> hoss_trunk_r1681791_tests-failures.txt
>
>
> SOLR-7274 introduces a pluggable authentication framework. This issue
> provides a Kerberos plugin implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
