+1 On Tue, May 23, 2017 at 10:59 AM, Piper, Nick <[email protected]> wrote:
> Thanks Larry, that's a useful commentary. Indeed - there is a Solr Ranger > plugin, and we plan to use it; but hoped Knox may be a stepping stone that > we can use until then. We'll likely leave our Knox as-is, and move on to > figuring out how to get Knox to tell Solr the authenticated user, and then > hopefully Solr Ranger can do the authorisation aspect. > > Regards, > > Nick > > *--* > > *Nick Piper* | Open Source SME | Defence > ------------------------------ > *From:* larry mccay [[email protected]] > *Sent:* 23 May 2017 3:32 PM > *To:* [email protected] > *Subject:* Re: Configuring SOLRAPI service to restrict 'collection' to > certain user groups > > Hi Nick - > > Using the typical layered approach to security, we only provide service > level authorization capabilities at the gateway. > The finer grained access controls are generally done much close to the > resource itself. > I'm not sure whether there is a Ranger integration for Solr or not but > that would be good place to look. > > Alternatively, you could consider building a custom authorization provider > to plugin. > It would need to include a URL matcher string and service and maybe just a > comma separated list of group names. > Like Java EE authorization semantics. > > The existing AclsAuthz provider should be able to be used as an example > for getting to the groups and to the current service name. > As well as loading the URL matcher strings into a mapping of matchers to > group lists. > > Note however that I generally avoid this level of access checks at the > gateway because there are often other paths to the same resource. > Most notably from CLIs on a gateway node or from mapreduce jobs inside the > cluster. > > Hope that is helpful. > > --larry > > > On Tue, May 23, 2017 at 10:00 AM, Piper, Nick <[email protected]> wrote: > >> Hi Knox community, >> >> We'd like to use Knox (0.11 currently) to expose the Solr API outside our >> main Hadoop cluster. We currently have it configured so that Knox verifies >> basic authentication credentials, and then allows the HTTP request to be >> proxied through to Solr. >> >> I see we can restrict this, on a per-service basis, to particular groups, >> as per: >> >> <param> >> <name>SOLRAPI.acl</name> >> <value>*;usergroup1;*</value> >> </param> >> >> Is there a way to configure Knox such that it only allows access to the >> correct 'collection' for a particular 'user group'? Knox can discover the >> 'user group' via an LDAP query, I believe. The 'collection name' is just >> part of the URL. >> >> https://github.com/apache/knox/blob/5dac768d2ed2ad051724b998 >> db5a7a1f39a599b0/gateway-service-definitions/src/main/r >> esources/services/solr/5.5.0/rewrite.xml#L20 >> >> <rule dir="IN" name="SOLRAPI/solr/inbound/query" >> pattern="*://*:*/**/solr/{collection=**}/{query=**}?{**}"> >> <rewrite template="{$serviceUrl[SOLRAPI >> ]}/{collection=**}/{query=**}?{**}"/> >> </rule> >> >> I thought about some ways to do this, but none seem successful: >> >> * A different 'topology' for each user group. This doesn’t work because >> the service doesn't include the collection name, so I can't vary the >> collection name on a per-topology basis: >> >> <service> >> <role>SOLRAPI</role> >> <url>http://solr-server:8000/solr</url> >> </service> >> >> * Looking for a 'url filtering' feature in Knox >> * Creating more 'services', one per user-group, so then I can use >> SOLRAPIGROUP1.acl, SOLRAPIGROUP2.acl, etc. This doesn't work as the service >> definition doesn't include the collection name. However; if I'm creating >> new services, then maybe I can customise the rewrite.xml so that more of >> the URL comes from the service/url configuration. This might be my best >> option? >> >> Many thanks for pointers, >> >> Nick >> >> -- >> Nick Piper | Open Source SME | Defence >> CGI IT UK Limited. A CGI Group Inc. Company >> Registered Office 250 Brook Drive, Green Park, Reading RG2 6UA, United >> Kingdom. Registered in England & Wales - Number 947968 >> >> >> >> >
