[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13934355#comment-13934355
]
David Webster commented on SOLR-4470:
-------------------------------------
Been a while since I have commented as we have been busy with a lot of things,
including making our own alteration to SOLR to add inter-node security.
However, been following this thread all along.
We could not use the actual patch code here because our developers had already
implemented production features requiring the latest GA release. We also had
to implement security using our SiteMinder based authentication, not BASIC
auth. We took a bit of a different tact than this approach and did 95% of the
security work outside the core SOLR code.
The only class we touched was the HttpClientUtil code, where we added the same
basic four lines or so of code this patch does. Everything else happens
outside of SOLR core code. We add an external jar of our own to the SOLR war
that implements a SiteMinder auth request to a Policy Server using a password
out of our CyberArk vault. We attach the SM token as a cookie on the request,
then on the receiving side, implemented a new JAAS LoginModule implemented as a
Tomcat Valve sitting in front of SOLR. That will assert the token on a new
session or if the token does not match the one in the cache. Does an LDAP role
lookup, too. Had to make a web.xml change adding the standard login config and
security role tags one would for BASIC auth. The info is cached and only makes
auth assertion requests on the server side when the token or session
expires/changes and the client side only when the server side passes back a
403.
Extensive load testing indicates a near negligible overhead on SOLR writes or
reads.
> 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: 5.0
>
> Attachments: SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch,
> SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch,
> SOLR-4470.patch, SOLR-4470_branch_4x_r1452629.patch,
> SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1454444.patch,
> SOLR-4470_trunk_r1568857.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.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
