Hi,
Solr doesn't have any built-in mechanism for document/field level security
- basically it's delegated to the container to provide security, but this
of course won't apply to specific documents and/or fields.
There are are a lot of ways to skin this cat, some bits of which have been
covered by your message.
What can be the trickiest thing about this isn't so much adding indexed
fields etc., but rather how you plan to determine who the 'searching user'
actually is.
This task can seem not too bad at first, then all sorts of worms start
streaming out of the can (e.g. how to avoid spoofing/identity theft).
Once you're app is confident it has a bona-fide user, you then need a way
to map the user to a set of fields/docs/permissions etc. that he/she
can/can't look at.
There are plenty of approaches - mainly driven by:
* where your original data lives (outside of Solr? does it still exist?
etc)
* is there an external ACL mechanism that you can use (e.g. file system
permissions)
* how do you manage users? (e.g. internal emplyoyees? public website
account holders? anyone?)
Two Jiras of note might help you in your quest:
SOLR-1872 (a good approach if you don't have access to the original
data at search-time)
SOLR-1895 (uses ManifoldCF - good if you have access to original data
and use its permissions - e.g. file system ACL)
HTH,
Peter
On Mon, Sep 17, 2012 at 7:44 PM, Nalini Kartha <nalinikar...@gmail.com>wrote:
> Hi,
>
> We're trying to push some security related info into the index which will
> control which users can search certain fields and we're wondering what the
> best way to accomplish this is.
>
> Some records that are being indexed and searched can have certain fields
> marked as private. When a field is marked as private, some querying users
> should not see/search on it whereas some super users can.
>
> Here's the solutions we're considering -
>
> - Index a separate boolean value into a new _INTERNAL field to indicate
> if the corresponding field value is marked private or not and include a
> filter in the query when the searching user is not a super user.
>
> So for eg., consider that a record can contain 3 fields - field[123] where
> field1 and field2 can be marked as private but field3 cannot.
>
> Record A has only field1 marked as private, record B has both field1 and
> field2 marked as private.
>
> When we index these records here's what we'd end up with in the index -
>
> Record A -
> field1:<something>, field1_INTERNAL:1, field2:<something>,
> field2_INTERNAL:0, field3:<something>
> Record B -
> field1:<something>, field1_INTERNAL:1, field2:<something>,
> field2_INTERNAL:1, field3:<something>
>
> If the searching user is NOT a super user then the query (let's say it's
> 'hidden security') needs to look like this-
>
> ((field3:hidden) OR (field1:hidden AND field1_INTERNAL:0) OR (field2:hidden
> AND field2_INTERNAL:0)) AND ((field3:security) OR (field1:security AND
> field1_INTERNAL:0) OR (field2:security AND field2_INTERNAL:0))
>
> Manipulating the query this way seems painful and error prone so we're
> wondering if Solr provides anything out of the box that would help with
> this?
>
>
> - Index the private values themselves into a separate _INTERNAL field
> and then determine which fields to query depending on the visibility of
> the
> searching user.
>
> So using the example from above, here's what the indexed records would look
> like -
>
> Record A - field1_INTERNAL:<something>, field2:<something>,
> field3:<something>
> Record B - field1_INTERNAL:<something>, field2_INTERNAL:<something>,
> field3:<something>
>
> If the searching user is NOT a super user then the query just needs to be
> against the regular fields whereas if the searching user IS a super user,
> the query needs to be against BOTH the regular and INTERNAL fields.
>
> The issue with this solution is that since the number of docs that include
> the INTERNAL fields is going to be much fewer we're wondering if relevancy
> would be messed up when we're querying both regular and internal fields for
> super users?
>
> Thoughts?
>
> Thanks,
> Nalini
>
