[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13883656#comment-13883656
]
David Webster commented on SOLR-4470:
-------------------------------------
Again, appreciate the input, looks like the issue is at least alive. We are
meeting Friday on this issue to plot our strategy. I am getting familiar with
the specifics of the issue, and am coming to realize the type of HTTP container
is largely irrelevant, so long as it is spec-compliant servlet container (as
Tomcat and Jetty are).
I do not particularly agree with the need for a container, however. We are
gradually moving away from pre-packaged "containers" ourselves, instead moving
towards framework tools like Spring Web and Grizzly2. We write all our own
JAAS LoginModules today and have a deep bench when it comes to managing service
side security, be those servlet (RESTful/HTTP), JMS, or anything else. There
are pluses and minuses in whether or not to use standard containers or roll
your own Servlet implementation. Another discussion for another day....
We have had the same issue present in Solr in our RESTful service
implementations in making them secure. We have a maturing RESTful/HTTP
security standard, and that requires our REST client code to do very specific
things when making down stream requests to secure services that expect a very
specific secured request. For instance, I can add a valve to Tomcat to have it
check for a user's SiteMinder cookie and then validate it with a call to a
Policy server. I could also implement a "secret key" (kerberos type thing). I
can implement that capability on the service side via a JAAS LoginModule, and
Tomcat Valve configuration without digging into Tomcat core code. But on the
client side I have to write actual core code to place the SiteMinder
token/Secret key encryption, etc.. in a cookie or header, etc, and send it
downstream.
I imagine the same must be true in the SolrCloud. 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.
My main fear is performance within the cloud during the sharding processes.
> 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]
