You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Jan Høydahl (JIRA)" <ji...@apache.org> on 2015/12/14 11:36:46 UTC

[jira] [Resolved] (SOLR-7207) PKI based security implementation for security in Solr

     [ https://issues.apache.org/jira/browse/SOLR-7207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Høydahl resolved SOLR-7207.
-------------------------------
    Resolution: Won't Fix

Closing as won't fix, as we ended up implementing Auth and Authz plugins instead. And inter-node communication already uses PKI.

> PKI based security implementation for security in Solr
> ------------------------------------------------------
>
>                 Key: SOLR-7207
>                 URL: https://issues.apache.org/jira/browse/SOLR-7207
>             Project: Solr
>          Issue Type: New Feature
>            Reporter: Noble Paul
>
> Historically, Solr has always stayed away from securing any operations and we even allow GET operation on an HTTP end point to manipulate almost anything inside a Solr cluster
> We can categorize the operations such as
> * Loading executable (runtime jars) SOLR-7126
> * conf files SOLR-6736
> * schema API
> * config API
> * collections API
> * /update/* operation to any collection
> SOLR-7126 has solved this problem using PKI where the public keys can be uploaded to {{/keys/exe}} and all jars loaded are verified using one of the public keys. 
> A similar scheme can be used for other operations as well. We can add keys to other  directories and use them to verify other operations. The only catch is , that we will need to send all the payload via POST
> The advantage of this scheme is that Solr does not need to manage any credentials or take care of storing anything secretly. It just needs a few public keys to be stored in ZK and security will kick in automatically. External solutions can build on top of these and provide authentication etc



--
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