There is another option: pairing multi-valued roles and fields. Multi-valued fields support in-order return: the values are returned in the same order you added them. This means that you can have two fields with matched pairs of values.
Secure data often a many-to-many relationship where any user can see some documents, and some documents are visible to more than one user. In this case, the above multi-valued array trick might help. You would have to repeat data for every role. ----- Original Message ----- | From: "Swati Swoboda" <sswob...@igloosoftware.com> | To: solr-user@lucene.apache.org | Sent: Monday, September 17, 2012 12:33:48 PM | Subject: RE: Selective field level security | | Hi Nalini, | | We had similar requirements and this is how we did it (using your | example): | | Record A: | Field1_All: <something> | Field1_Private: <something> | Field2_All: '' | Field2_Private: <something private> | Field3_All: '' | Field3_Private: <something very private> | | Fields_All: <something> | Fields_Private: <something> <something private> <something very | private> | | Basically, we're just using a lot of copy fields and dynamic fields. | Instead of storing a type, we just change the column name. So if | someone who had access to private fields, we would perform our | search in the private column fields: | | (fields_private:something) | | Or if you want a specific field: | | (field1_private:something) OR (field2_private:something) or | (field3_private:something) | | Likewise, if someone didn't have access to the private fields, we | would only search in the "all" fields. We also created a "super | field" so that we don't have to search each individual field -- we | use copyfields to copy all private fields into the super field and | just search that. | | I hope this helps. | | Swati | | -----Original Message----- | From: Nalini Kartha [mailto:nalinikar...@gmail.com] | Sent: Monday, September 17, 2012 2:45 PM | To: solr-user@lucene.apache.org | Subject: Selective field level security | | 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 |
