You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Gregory Chanan (JIRA)" <ji...@apache.org> on 2015/06/10 00:48:01 UTC
[jira] [Comment Edited] (SOLR-7468) Kerberos authentication module
[ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org