I guess it comes down to - any solution is ultimately going to place access control on a search and not on data, so there isn't much to be gained by binding the access control to the data. Whatever attributes exist at index time to build an acl will still be there at query time, so by making the acl search-bound, the acl is decoupled from the data, allowing it to be used in any use case scenario.
Here's a typical sampling of use cases where the decoupling of acl from data is required:
One customer has a 'shop-search' requirement where, logged-in users' access to various shops changes daily, sometimes 4 or 5 times a day. There are several hundred such shops and 10s of millions of documents, and the indexing part doesn't have ownership of any of the 'source' documents.
Another example is a customer who has multiple sites and multiple AD domains. They have one domain for the UK, but a completely separate domain for Gibraltar. When data is replicated to remote servers accessed by Gibraltar staff, these users have no SID information in the other domain.
An 'interesting' example of this at the extreme is 34rkl4ys Bank, where, due to departmental history, they have no fewer than 85 AD domains! This of course is a nightmare in itself, but trying to tie access information to data at storage time is virtually impossible in this environment.
The thing I'm trying to understand is that the decoupled approach works equally well for the requirements where you do have acl information at index time. I guess I'm not understanding the advantages to making schema changes and binding acl to data, when there's really no need. I particularly like your idea of using LCF as the facilitator of storing/retrieving such decoupled data (as opposed to just an xml file). It sounds like there's even a user interface for 'non-technical' staff to make acl configuration changes. That's really cool, and ultimately an elegant solution that will fit present and future needs.
I'm more than happy to hear your customer's requirements, so no problem there. It does seem to me that they are a bit different than what I've seen. I think there is plenty of room for different flavors of solution, so please by all means go ahead and propose your take on it!
Sent: Wednesday, April 28, 2010 8:07 PM
From: ext Peter Sturge [firstname.lastname@example.org]
email@example.com; firstname.lastname@example.org; email@example.com
Subject: Re: FW: Solr and LCF security at query time
I wasn't trying to to put pay to your design proposal, really the opposite - to highlight requirements that have found to be necessary for customers/users, and to hopefully get the best functionality for the product. If you feel I've put you out on any of the issues raised, then I apologize for that, it was certainly not my intention.