[
https://issues.apache.org/jira/browse/SOLR-7207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14353045#comment-14353045
]
Jan Høydahl commented on SOLR-7207:
-----------------------------------
Fort Knox security™ :)
Perhaps a more user friendly and well-known form of HTTP API security is [API
keys| https://en.wikipedia.org/wiki/Application_programming_interface_key]. If
enforced, all requests would need to contain a key e.g.
http://localhost:8983/update?commit=true&apikey=baa57bd6995e5e92b52dbf62cfca65330f9aafeb
The key processing could be pluggable through an {{ApiKeySecurityFactory}}
with a simple impl shipping as default. More advanced impls could do
authentication, fine-grained authorization such as path-based, IP-based, and
such factories could delegate to components outside of Solr too.
We don't need to choose either PKI based or ApiKey based, both could be
supported if required, but to my taste PKI feels a bit too heavy-weight for
this purpose.
> Securing operations 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
