[
https://issues.apache.org/jira/browse/SOLR-9200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15382000#comment-15382000
]
Ishan Chattopadhyaya commented on SOLR-9200:
--------------------------------------------
Apologies for delay in the review; I have caught on a viral infection and have
still not fully recovered. Here are some comments from before I fell sick.
# Can we eliminate the NoContext and replace with AttributeOnlyServletContext?
# I think it makes sense to write a test for internode communication to ensure
that delegation tokens based authentication is working end to end. The
TestSolrCloudWithDelegationTokens seems to use a 2 node mini solr cloud
cluster, but it wasn't apparent to me if there are any calls made to the
cluster from the test that require internode communication (maybe there is and
I've missed it).
# How can we ensure that no HttpSolrClients are created from elsewhere in Solr
while delegation tokens based kerberos authentication is enabled (so that DTs
are always passed on)? Do you think we should ban the creation of HSCs, and
provide for a factory method?
# I see there are various places in Solr codebase where HSCs are created, e.g.
SnitchContext, LeaderInitiatedRecoveryThread,
OverseerAutoReplicaFailoverThread, OverseerCollectionMessageHandler,
RecoveryStrategy, SyncStrategy, IndexFetcher, CdcrRequestHandler,
CdcrUpdateLogSynchronizer, SolrConfigHandler, ManagedSchema,
SolrCmdDistributor. These are for internode communication, but these clients do
not get the delegation tokens passed on while making the request. Shouldn't
they be using delegation tokens too, to make it consistent?
# Minor: Unused imports in AuthenticationPlugin
# Minor: Unnecessary change to SolrZkClient
# TestSolrCloudWithDelegationTokens:
{code}
System.setProperty(KerberosPlugin.DELEGATION_TOKEN_PARAM, "true");
{code}
line has been repeated in the test
# {code} solr.kerberos.delegation.token.signer.secret.provider.zookeper.path
String (chrooted path) + /token Zookeeper location where secret
provider information is stored
solr.kerberos.delegation.token.secret.manager.znode.working.path String
(chrooted path) + /zkdtsm Zookeeper location where token information is
stored {code}
Does it make more sense if we move all znodes related to security under a
nested znode like /security/*, i.e. modify the defaults here to
/security/zkdtsm and /security/token? It might be easier for sysadmins to know
what purpose these znodes are present for.
# I liked the idea of Solr protecting these znodes right away through ZK ACLs;
it would prevent against vulnerabilities for setups where the sysadmin has
forgotten to turn it on for the right znodes. However, should we make that
behaviour configurable and make it possible for the sysadmin to not ACL protect
those znodes, and allow him to do so manually? The usecase I have in mind, and
I'm not sure if this is a real world usecase or not, is where a sysadmin is
dealing with a failed ZK setup, and is cloning all the znodes into a fresh ZK
cluster: I imagine that such a clone would not work for those two znodes if
Solr has ACL protected them.
> Add Delegation Token Support to Solr
> ------------------------------------
>
> Key: SOLR-9200
> URL: https://issues.apache.org/jira/browse/SOLR-9200
> Project: Solr
> Issue Type: New Feature
> Components: security
> Reporter: Gregory Chanan
> Assignee: Gregory Chanan
> Attachments: SOLR-9200.patch, SOLR-9200.patch
>
>
> SOLR-7468 added support for kerberos authentication via the hadoop
> authentication filter. Hadoop also has support for an authentication filter
> that supports delegation tokens, which allow authenticated users the ability
> to grab/renew/delete a token that can be used to bypass the normal
> authentication path for a time. This is useful in a variety of use cases:
> 1) distributed clients (e.g. MapReduce) where each client may not have access
> to the user's kerberos credentials. Instead, the job runner can grab a
> delegation token and use that during task execution.
> 2) If the load on the kerberos server is too high, delegation tokens can
> avoid hitting the kerberos server after the first request
> 3) If requests/permissions need to be delegated to another user: the more
> privileged user can request a delegation token that can be passed to the less
> privileged user.
> Note to self:
> In
> https://issues.apache.org/jira/browse/SOLR-7468?focusedCommentId=14579636&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14579636
> I made the following comment which I need to investigate further, since I
> don't know if anything changed in this area:
> {quote}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?{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
