I also work with the FAST Enterprise Search engine and this is exactly
how their Security Access Module works. They actually use a modified
base-32 encoded value for indexing, but that is because they don't
have the luxury of untokenized/un-processed String fields like Solr.
Thanks,
Matt Weber
eSr Technologies
http://www.esr-technologies.com
On May 12, 2009, at 12:26 PM, Terence Gannon wrote:
Paul -- thanks for the reply, I appreciate it. That's a very
practical
approach, and is worth taking a closer look at. Actually, taking
your idea
one step further, perhaps three fields; 1) ownerUid (uid of the
document's
owner) 2) grantedUid (uid of users who have been granted access),
and 3)
deniedUid (uid of users specifically denied access to the
document). These
fields, coupled with some business rules around how they were
populated
should cover off all possibilities I think.
Access to the Solr instance would have to be tightly controlled, but
that's
something that should be done anyway. You sure wouldn't want end
users
preparing their own XML and throwing it at Solr -- it would be
pretty easy
to figure out how to get around the access/denied fields and get at
stuff
the owner didn't intend.
This approach mimics to some degree what is being done in the
operating
system, but it's still elegant and provides the level of control
required.
Anybody else have any thoughts in this regard? Has anybody
implemented
anything similar, and if so, how did it work? Thanks, and best
regards...
Terence
