10:45 p.m.
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
11:54 a.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
12:59 p.m.
On 27 February 2014 10:54, Dan Berindei <dan.berindei(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
3719
days inactive
3720
days old
infinispan-dev@lists.jboss.org
2 comments
2 participants
participants (2)
-
Dan Berindei -
Sanne Grinovero