[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14234714#comment-14234714
]
David Webster commented on SOLR-4470:
-------------------------------------
Yes, we evaluated the entire patch set and realized all we needed to implement
something meeting our requirements was about four lines of new code at the
HTTPClient level, that calls out to another external auth module (an outside
agency), when needed, to refresh credentials. Not really "hardcoded" at all,
but within the narrow context of the client, I suppose you could call it that.
And yes, on the receiving end all security is offloaded to a JAAS module;
doable because these nodes are housed in Tomcat. If it's a new request coming
into the processing cloud or the token has expired, it gets a new credential
for the "outside agency". Rinse and repeat.
For your example, an outside client sending in a query (R1), that then has to
propagate a sub request to R2 to Server B. R1 will hit a "mediator". That
mediator will attempt to send the query to Server A. That will hit server A's
JAAS module which will reject it. That will kick in a call to the "external
agency" to check out a valid credential from the vault, sign it, and try again.
This time Server A accepts it. If it needs to send a sub query to Server B,
it uses our four lines of mod code to inject the credential, send it, and
Server B's JAAS module will assert it. If it passes it goes on down the line.
If not (expired or man-in-the-middle attack), it goes back to Server A, where
Server A again does the same check out procedure. And so on.
Four lines of code; everything else externalized in custom code modules that
are outside core SOLR. May be a fairly simple use case, but it works for us
and most importantly, passes IA and external security Audit muster.
> 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: Trunk
>
> 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.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.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
