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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev