As part of Cloudera Search, we have integrated with Apache Sentry for document level authorization. Currently we are using custom search component to implement filtering. Please refer to this blog post for details, http://blog.cloudera.com/blog/2014/07/new-in-cdh-5-1-document-level-security-for-cloudera-search/
I am currently working on a Sentry based plugin implementation which can be hooked in the Solr authorization framework. Currently Solr authorization framework doesn't implement document level security. I filed SOLR-9578 <https://issues.apache.org/jira/browse/SOLR-9578> to add the relevant doc level security support in Solr. The main drawback of custom search component based mechanism is that it requires a special solrconfig.xml file (which is using these custom search components). On the other hand, once Solr provides hooks to implement doc level security as part of authorization framework, then this restriction will go away. If you have any ideas (or concerns) with this feature, please feel free to comment on the jira. Thanks Hrishikesh On Wed, Oct 19, 2016 at 7:48 AM, Shawn Heisey <apa...@elyograg.org> wrote: > On 10/18/2016 3:00 PM, John Bickerstaff wrote: > > How (or is it even wise) to "segregate data" in Solr so that some data > > can be seen by some users and some data not be seen? > > IMHO, security like this isn't really Solr's job ... but with the right > data in the index, the system that DOES handle the security can include > a filter with each user's query to restrict them to only the data they > are allowed to see. There are many ways to put data in the index for > efficient use by a filter. The simplest would be a boolean field with a > name like isPublic or isPrivate, where true and false are mapped as > necessary to public and private. > > Naturally, the users must not be able to reach Solr directly ... they > must be restricted to the software that connects to Solr on their > behalf. Blocking end users from direct network access to Solr is a good > idea even if there are no other security needs. > > There are more comprehensive solutions available, as you will notice > from other replies, but the idea of simple filtering, controlled by your > application, should work. > > Thanks, > Shawn > >
