Actual question in last paragraph – lead-in is a Use Case setup.

A recurring challenge for me has become implementing comprehensive information access security, when creating Lucene based search/navigation add-ons to 3rd party enterprise systems.

Here is a typical use case. Imagine a CRM system, which has Contacts, Leads, Opportunities and Accounts. (Salesforce, SugarCRM, etc.)

There is a GROUP of users, who are allowed to see all records, associated with the “EMEA Territory”. There are also 2 ROLEs – “Sales Manager” and “Sales Executive”, such that “Sales Manager” can see the field “Cell Number” in all records, while “Sales Excutive” can only see this field for records, owned by the user with this role.

Now – we use Lucene to index EVERYTHING – every scrap of data (read every string representation of information) in all records.

While we are dealing with straight-up user/group record security, we can easily get away with adding two attributes to each Lucene item – we call them the “Allowed List” and “Denied List”. At indexing time we examine each object we index, collect all USER_IDs and GROUP_IDs that explicitly and fully describe the “allowed” and “denied” ACLs for the object and we add them to our index.

Throwing-in Role-Based, field-level access control, however, changes the game. Clearly we do not have the facilities to record the ACLs for each Lucene item/attribute combination (tuple).

The best approach then seems to be to filter the Query results, just before they are delivered to the query client and REMOVE hits, AND attributes, which are not allowed for the current user.

Question: Where do we tie-in? Optimally we will introduce a call-back in the Lucene code, such that we can use an arbitrary external “SecurityFilter” class, which will simply return a TRUE/FALSE, or maybe even a security status (so that a rejection can be evaluated for reason), for EACH query hit.