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

[Dan Berindei]

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.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20140227/0bbc466e/attachment-0001.html