[infinispan-dev] Row based security & Queries (Was: Design change in Infinispan Query)

[Sanne Grinovero]

On 27 February 2014 10:54, Dan Berindei <dan.berindei at gmail.com> wrote:
> Hi Sanne
>
> Reading your reply I realized I was wrong in my "evaluation", we could
> require the user to specify the secure cache(s) he wants to query when
> building the query and checking that he has read rights on all of them
> before executing the query, just like a DB would do. And if he doesn't
> specify any cache, throw an exception if there is any indexed cache that he
> doesn't have read access to. So we could implement the cache-level security
> we need now without any performance hit.

Right, but when querying indexes, we target an index not a cache. A
user could have access to one cache and not another, and if we go for
a shared query engine, the current implementation allows to share
indexes.
You could have a valid situation in which an entry X stored in a Cache
A, to which you have access to, but also stored in a Cache B, to which
you have no access to, is retrieved from CacheA (so no security
problem) but because of scoring affected by additional metadata which
entered the index via Cache B.
This wouldn't be a security violation sctrictly speaking but would be
highly confusing, as it's often quite complex to figure out why some
result is matching.

As you say we could block the query if the user has no access to one
of the related caches. It could still be puzzling as someone might be
prevented to retrieve data from a ache for which he has haccess, but
that's probably easier to explain and document that shared indexes
require same access permissions on each involved cache.

Cheers,
Sanne

>
> But thanks for the explanation, it sounds like row-level security isn't
> quite as far-fetched as I was imagining it ;)
>
> Cheers
> Dan
>
>
>
> On Wed, Feb 26, 2014 at 11:45 PM, Sanne Grinovero <sanne at infinispan.org>
> wrote:
>>
>> To clarify some points rised on the thread "Design change in
>> Infinispan Query", which I don't wish to derail further:
>>
>> The Query engine can actually apply per-entry user restriction access
>> in an efficient way which doesn't involve (necessarily) to check each
>> result; currently this needs specific user coding but:
>> # it's not too hard as Hibernate Search users do it regularly: we
>> provide various helpers and examples. Especially in the book :-)
>> # is not including a pre-canned strategy as -at least in case of our
>> Hibernate integration - the details of how people want it done are
>> often exotic.
>>
>> Essentially a typical solution would work with Filters: a filter is a
>> bitset which masks potential results from queries, so it's applied
>> upfront actual scoring and other more complex match operations.
>> These bitsets are very suited for filters, and are split on segments
>> so that pre-computed segments related to parts of an index which
>> didn't change can be reused even if the index as a whole is mutating
>> continually.
>> Such a Filter could even encode the response of some external
>> authorization service on a per-document base (slow but effective), or
>> it simply represents user group tokens which are applied as tags on
>> the indexed documents (more efficient as long as role definitions are
>> stable).
>>
>> That said, I'm not suggesting that this should be a priority, but I
>> expect that sometime in the future we could provide a pre-canned
>> strategy to work out of the box with our security extensions, at least
>> for the benefit of remote protocols. So let's keep this in mind while
>> making other design decisions.
>>
>> -- Sanne
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev