lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lance Norskog <goks...@gmail.com>
Subject Re: HTTP Authentication for shards
Date Thu, 08 Apr 2010 21:27:18 GMT
Getting authentications/authorizations is a tricky security problem.
Part of the cloud project (I think) is a configuration delivery tool,
which will make this a lot easier.

On Thu, Apr 8, 2010 at 2:11 AM, Peter Sturge
<peter.sturge@googlemail.com> wrote:
> Hi Lance,
>
> Thanks for your message.
> I'm guessing you mean modify the Solrj auth mechanism on the server side.
>
> In order to use the standard 'shards' parameter in client requests, the
> problem occurs before
> CommonHttpSolrServer, because the SearchHandler indeed passes an HttpClient
> object to CommonHttpSolrServer
> to use for shards, but it doesn't populate it with any credentials (it
> doesn't have any to provide).
>
> The idea behind the proposed solution is to provide a way to propogate
> credentials to the underlying CommonsHttpSolrServer, as well as
> define a way of getting those credentials to the (proxy) server.
>
> Perhaps, it would be better if the credentials come from Solr-side
> configuration (an xml file), relieving remote clients from sending
> credentials
> (or have both options available, and let config decide).
> This is perhaps a more secure way of holding/providing credentials, but the
> client is then reliant on that configuration being present
> on any and all servers it connects to. This would also mean that *any*
> client could access all shards with a single login
> (or no login if the container doesn't use authentication). Hmm...could be
> thought of as a security hole or indeed SSO, depending on your persepective
> :-).
>
> Thanks,
> Peter
>
>
> On Thu, Apr 8, 2010 at 3:38 AM, Lance Norskog <goksron@gmail.com> wrote:
>
>> Distributed Search, down at the bottom, uses SolrJ. This problem
>> should be in SolrJ in the CommonsHttpSolrServer. The Apache Commons
>> HTTP stuff handles authentication:
>>
>> http://hc.apache.org/httpclient-3.x/authentication.html
>>
>> You can create the HttpClient and ConnectionManager yourself when
>> using SolrJ, and it's easy to prototype all of the authentication
>> stuff with a simple SolrJ program.
>>
>> On Fri, Apr 2, 2010 at 4:15 AM, Peter Sturge
>> <peter.sturge@googlemail.com> wrote:
>> > Hi,
>> >
>> > I've come across an interesting problem with regards distributed
>> searching,
>> > and thought I'd share it here and see if anyone else has come across it
>> > and/or comment on the proposed solution:
>> >
>> > *Requirement:*
>> > A requirement of my particular Solr environment is that queries are
>> subject
>> > to http authentication (I currently use Jetty basic realm auth, but any
>> http
>> > auth is affected).
>> > i.e. If you don't have a username/password, you can't look at anything.
>> > For most use cases, I'm guessing that queries aren't generally subject to
>> > authentication, hence this post...
>> >
>> > *Problem:*
>> > Querying a single server is easy, because my client app creates/manages
>> its
>> > own HttpClient object.
>> > When it comes to querying across shards, the default SearchHandler uses a
>> > 'plain-vanilla' http client for its CommonsHttpSolrServer instance that
>> > makes the request to each shard (in HttpCommComponent.submit()).
>> > There is no provision to pass it any credentials.
>> >
>> > Perhaps document-level security might be a better way to handle access
>> > control for searching in general, but that's a different can of worms...
>> :-)
>> >
>> > *Proposed Solution:*
>> > A proposed solution for overall Solr access for searching across
>> > http-authenticated shards is this:
>> >
>> > 1. Define parameter(s) syntax for shard credentials.
>> >
>> > 2. Modify (or subclass) SearchHandler, in particular the
>> > HttpCommComponent.submit() method, to optionally look for shard-specific
>> > credentials in its ModifiableSolrParams params.
>> > If it finds credentials, it creates/reuses an HttpClient object with
>> these
>> > and passes this to the SolrServer instance for the search request.
>> > Because the credentials parameter would be totally optional, it should be
>> > fine to patch SearchHandler 'in-line' without subclassing, so that
>> > patches/updates will work without having to modify solrconfig.xml.
>> > (feel free to disagree with me on this!)
>> >
>> > 3. This also requires a modification to SearchHandler.handleRequestBody()
>> to
>> > extract the credentials parameter(s) and pass these on to the submit()
>> > request (similar to what it does now for SHARDS_QT).
>> >
>> > 4. Clients would populate their sharded query request with the defined
>> > parameter(s) for each shard (I'm using SolrJ so there's app logic to do
>> > this, but should be ok for other client types).
>> >
>> > I admit I'm not an expert on SearchHandler inner workings, so if there
>> are
>> > other code paths that would be affected by this, or any other potential
>> > issues, any advice/insight is greatly appreciated!
>> > If anyone thinks this is a barmy idea, or has come up with a better
>> > solution, please say!
>> >
>> > Many thanks,
>> > Peter
>> >
>>
>>
>>
>> --
>> Lance Norskog
>> goksron@gmail.com
>>
>



-- 
Lance Norskog
goksron@gmail.com

Mime
View raw message