[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13667673#comment-13667673
]
Per Steffensen edited comment on SOLR-4470 at 5/27/13 10:05 AM:
----------------------------------------------------------------
bq. Could make an implementation which reads a system-basic-auth.properties
from ZK (given your ZK is encrypted). That would be useful once the other issue
about securing ZK is solved.
Guess you are talking about SOLR-4580. It is not about encryption (neither
storage- nor transport-level). It is about authentication and authorization at
application/API-level. But you are right, it is an option to build on top of
this issue and allow for those internal credentials to live in ZK - just make
sure the security issues doing that is dealt with.
bq. Q: Would it make sense to make CurrentInternalRequestFactory or
InterSolrNodeAuthCredentialsFactory pluggable through solr.xml? Currently you
need to patch and build Solr to change it, right?
Yes you need to patch and rebuild. But that is because it did not include as
much code in the patch as I wanted to, and as I did for SOLR-4580. In the patch
for SOLR-4580 I've included code so that you, through JVM params, can specify
the name of a class which will be used as credentials/ACL-provider. The same
should have been done in the patch for this SOLR-4470. I ought to have included
code so that you, through JVM params, can point out the classes you want to be
used as credentials-providers. Basically JVM params that is able to control
which implementations of InterSolrNodeAuthCredentialsFactory.SubRequestFactory
and InterSolrNodeAuthCredentialsFactory.InternalRequestFactory is to be used
default for InterSolrNodeAuthCredentialsFactory.CurrentSubRequestFactory and
InterSolrNodeAuthCredentialsFactory.CurrentInternalRequestFactory.
JVM params is the simplest way to control which implementations to be used
behind the interfaces. That is, in my opinion, what should have been included
here. Going from control through JVM params and adding support for control
through solr.xml or something else should be another issue, but it is certainly
a good and valid idea.
{quote}
bq. Solr is not enforcing security - the webcontainer or something else is.
A comment right in the patch explains this is not the case - it says the web
container authorizes any role and then new Solr code is responsible for dealing
with role authorization. This is Solr code that can introduce security bugs.
This is the slippery slope, this is the fuzzy line, this is the creep.
{quote}
Well you did not point out the exact comment as I asked you to, so I will have
to guess a little. The code going into the real non-test part of Solr does not
do anything to enforce security. It only enables a Solr admin to configure
Solr-nodes in a way so that their inter-communication will still work if the
Solr admin chooses to set up e.g. container-managed security.
I order to claim that my solution solves the problem I want to test that it
does. Test strategy: Set up container-managed security and verify that all
inter-Solr-node communitation works if you use my solution. So the test-code
sets up container-managed security, and in there there is a comment about just
letting the container manage authentication and handle authorization in a
filter. But this is all a simulation of what the Solr admin decided to do to
set up security. This is test only!
{quote}
bq. Personally I do not understand why a serious project would stay out of
security
It's simply the current stance of the project
{quote}
Well I havnt been on the meetings or whatever where this stance was
established, but I would imagine that this stance is about Solr not going down
the path of enforcing or controlling or ... security. I couldnt imagine that
this stance is about that we will not want a SolrClould cluster to work if an
Solr admin chooses to activate third party security in a very common way.
was (Author: steff1193):
bq. Could make an implementation which reads a system-basic-auth.properties
from ZK (given your ZK is encrypted). That would be useful once the other issue
about securing ZK is solved.
Guess you are talking about SOLR-4580. It is not about encryption (neither
storage- nor transport-level). It is about authentication and authorization at
application/API-level. But you are right, it is an option to build on top of
this issue and allow for those internal credentials to live in ZK - just make
sure the security issues doing that is dealt with.
bq. Q: Would it make sense to make CurrentInternalRequestFactory or
InterSolrNodeAuthCredentialsFactory pluggable through solr.xml? Currently you
need to patch and build Solr to change it, right?
Yes you need to patch and rebuild. But that is because it did not include as
much code in the patch as I wanted to, and as I did for SOLR-4580. In the patch
for SOLR-4580 I've included code so that you, through JVM params, can specify
the name of a class which will be used as credentials/ACL-provider. The same
should have been done in the patch for this SOLR-4470. I ought to have included
code so that you through JVM params can point out the classes you want to be
used as credentials-providers. Basically JVM params that is able to control
which implementations of InterSolrNodeAuthCredentialsFactory.SubRequestFactory
and InterSolrNodeAuthCredentialsFactory.InternalRequestFactory is to be used
default for InterSolrNodeAuthCredentialsFactory.CurrentSubRequestFactory and
InterSolrNodeAuthCredentialsFactory.CurrentInternalRequestFactory.
JVM params is the simplest way to control which implementations to be used
behind the interfaces. That is, in my opinion, what should have been included
here. Going from control through JVM params and adding support for control
through solr.xml or something else should be another issue, but it is certainly
a good and valid idea.
{quote}
bq. Solr is not enforcing security - the webcontainer or something else is.
A comment right in the patch explains this is not the case - it says the web
container authorizes any role and then new Solr code is responsible for dealing
with role authorization. This is Solr code that can introduce security bugs.
This is the slippery slope, this is the fuzzy line, this is the creep.
{quote}
Well you did not point out the exact comment as I asked you to, so I will have
to guess a little. The code going into the real non-test part of Solr does not
do anything to enforce security. It only enables a Solr admin to configure
Solr-nodes in a way so that their inter-communication will still work if the
Solr admin chooses to set up e.g. container-managed security.
I order to claim that my solution solves the problem I want to test that it
does. Test strategy: Set up container-managed security and verify that all
inter-Solr-node communitation works if you use my solution. So the test-code
sets up container-managed security, and in there there is a comment about just
letting the container manage authentication and handle authorization in a
filter. But this is all a simulation of what the Solr admin decided to do to
set up security. This is test only!
{quote}
bq. Personally I do not understand why a serious project would stay out of
security
It's simply the current stance of the project
{quote}
Well I havnt been on the meetings or whatever where this stance was
established, but I would imagine that this stance is about Solr not going down
the patch of enforcing or controlling or ... security. I couldnt imagine that
this stance is about that we will not want a SolrClould cluster to work if an
Solr admin chooses to activate third party security in a very common way.
> Support for basic http auth in internal solr requests
> -----------------------------------------------------
>
> Key: SOLR-4470
> URL: https://issues.apache.org/jira/browse/SOLR-4470
> Project: Solr
> Issue Type: New Feature
> Components: clients - java, multicore, replication (java), SolrCloud
> Affects Versions: 4.0
> Reporter: Per Steffensen
> Assignee: Jan Høydahl
> Labels: authentication, https, solrclient, solrcloud, ssl
> Fix For: 4.4
>
> Attachments: SOLR-4470_branch_4x_r1452629.patch,
> SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1454444.patch,
> SOLR-4470.patch
>
>
> We want to protect any HTTP-resource (url). We want to require credentials no
> matter what kind of HTTP-request you make to a Solr-node.
> It can faily easy be acheived as described on
> http://wiki.apache.org/solr/SolrSecurity. This problem is that Solr-nodes
> also make "internal" request to other Solr-nodes, and for it to work
> credentials need to be provided here also.
> Ideally we would like to "forward" credentials from a particular request to
> all the "internal" sub-requests it triggers. E.g. for search and update
> request.
> But there are also "internal" requests
> * that only indirectly/asynchronously triggered from "outside" requests (e.g.
> shard creation/deletion/etc based on calls to the "Collection API")
> * that do not in any way have relation to an "outside" "super"-request (e.g.
> replica synching stuff)
> We would like to aim at a solution where "original" credentials are
> "forwarded" when a request directly/synchronously trigger a subrequest, and
> fallback to a configured "internal credentials" for the
> asynchronous/non-rooted requests.
> In our solution we would aim at only supporting basic http auth, but we would
> like to make a "framework" around it, so that not to much refactoring is
> needed if you later want to make support for other kinds of auth (e.g. digest)
> We will work at a solution but create this JIRA issue early in order to get
> input/comments from the community as early as possible.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
