[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13883927#comment-13883927
]
Per Steffensen commented on SOLR-4470:
--------------------------------------
bq. ...and this patch is HUGE
Yes it is, but a lot of it is on the testing part. Hopefully, I will have the
time to help out at some point, but my customer is not as willing as he has
been, allowing me to use time on getting patches all the way into Apache
code-base. He (we) has realized along the way that it is not worth the effort -
it is not going to get in anyway. I sincerely hope that he is wrong in the long
run.
bq. Again, appreciate the input, looks like the issue is at least alive.
At least it wakes up from time to time, when someone new comes around and
complains :-)
bq. We write all our own JAAS LoginModules today
We do that too. For our SolrCloud based solutions we have made a LoginModule
persisting its data in ZooKeeper. It is around anyway and has nice features
about pushing changes in password etc to the realms in the web-container.
bq. I can lock down the receiver side via configuration and standard Container
plugins, but it's the sender side that we can do nothing about without some
core code modification that would allow us to send whatever security artifacts
downstream we deem appropriate
In order not to make this issue too "wide", I deliberately made it about "basic
http auth" only. If you use SolrJ as the client the patch I provided allow for
easy injection of the username/password sent to the Server-side by the SolrJ
client. Basically the patch is about support in SolrJ clients to fetch (from
the outside - config or stdin or whatever) security artifacts to use and then
use them in outgoing requests. Since Solr-nodes use SolrJ for sending
inter-Solr-node request this will make the feature available for
inter-Solr-node requests, but at the same time the feature is also available
for "clients" using SolrJ. If you use other kinds of clients you will need to
deal with the credentials-sending from clients yourself.
The patch is also "prepared for" other kinds of security artifacts (cookeis,
RSA certificates or whatever), so that they can be built into the established
framework, but currently it only supports basic http auth out of the box - but
also for SolrJ clients.
bq. Spring Web and Grizzly2
With respect to going away from the using all the nice features provided by
web-containers and replace by other "frameworks" providing the same features,
do not get me wrong. In principle I have nothing against that, when we just do
not believe that we can do better ourselves. Use some framework (web-containers
or Spring stuff or whatever) to deal with that stuff. And as long as we do
that, and do not make it ourselves, I am not sure the argument about "Once Solr
is a "real" application that owns and fully controls the HTTP layer, security
will not be such a nightmare" holds. Either we do it ourselves and get "full
control" or we do it by using some "framework", and claiming the the
alternative framework (alternative to web-containers) provide more "control"
than web-containers do, is not necessarily true. But do not get me wrong, I
have nothing against using other frameworks than web-containers, I am just not
convinced that it is worth the effort. Web-containers in general do a great
job, and most of them have had years and years to mature.
[~zoomieia1980], if you really care about security in SolrCloud, you might also
want to take a peek at SOLR-4580. Depending on how much you expose ZooKeeper,
how afraid you are of admins etc accidentally messing up ZK data etc, this
might also be relevant for you.
> 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.7
>
> Attachments: SOLR-4470.patch, SOLR-4470.patch,
> SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1452629.patch,
> SOLR-4470_branch_4x_r1454444.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 was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
