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.stu...@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 <goks...@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.stu...@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 >> goks...@gmail.com >> > -- Lance Norskog goks...@gmail.com
