How to implement row level access control in Lucene
Below I have written some fully functionally code that shows how you could implement row level access control in Lucene (2.3.2). Basically you have to index enough information to be able to search (in a single query) and find all documents that a given user has access to read.
In the below example there are two fields:
DATA: Which contains any data that you want your users to be able to search. NOTE: You can have as many data fields as you like.
ACL_FIELD: The field used to determine what users have access to this document. Note: You can have as many access control fields as you like.
All you have to do is built the access control query for each user and submit your user's query unchanged.
After you run this code, you will get a single hit, not the two that you would normally get if the access control filter wasn't in place.
1st - Provide per query locking around the bitset creation code. This would allow multiple bitset creation calls to occur at once, but the same access control query would block. Therefore we would only have to build it once, even if multiple user queries with the same access control hit the query filter at once.
2nd - Persist the bitsets. In the past I have used the same directory as the index, but you may want to use a database, or something else.
In the below example there are two fields:
DATA: Which contains any data that you want your users to be able to search. NOTE: You can have as many data fields as you like.
ACL_FIELD: The field used to determine what users have access to this document. Note: You can have as many access control fields as you like.
All you have to do is built the access control query for each user and submit your user's query unchanged.
public class TestIndexerSearcher {
public static void main(String[] args) throws Exception {
Directory directory = new RAMDirectory();
IndexWriter indexWriter = new IndexWriter(directory, new StandardAnalyzer());
indexWriter.addDocument(buildDocument("DATA:sametoken","ACL_FIELD:access"));
indexWriter.addDocument(buildDocument("DATA:sametoken","ACL_FIELD:noaccess"));
indexWriter.optimize();
indexWriter.close();
IndexSearcher indexSearcher = new IndexSearcher(directory);
QueryParser parser = new QueryParser("DATA", new StandardAnalyzer());
Query query = parser.parse("sametoken");
//This is all you have to add to your existing code.
Filter aclFilter = applyAccessControl(new TermQuery(
new Term("ACL_FIELD","access")));
Hits hits = indexSearcher.search(query, aclFilter);
System.out.println("Hits[" + hits.length() + "]");
for (int i = 0; i < hits.length(); i++) {
Document doc = hits.doc(i);
System.out.println("DATA [" + doc.get("DATA") +
"] ACL_FIELD [" + doc.get("ACL_FIELD") + "]");
}
indexSearcher.close();
}
private static Filter applyAccessControl(Query aclQuery) {
return new CachedQueryFilter(aclQuery.toString(),
new QueryWrapperFilter(aclQuery));
}
private static Document buildDocument(String... fieldInfo) {
Document document = new Document();
for (int i = 0; i < fieldInfo.length; i++) {
String[] split = fieldInfo[i].split(":");
String fieldName = split[0];
String fieldValue = split[1];
document.add(new Field(fieldName,fieldValue,
Field.Store.YES,Field.Index.TOKENIZED));
}
return document;
}
}
After you run this code, you will get a single hit, not the two that you would normally get if the access control filter wasn't in place.
public class CachedQueryFilter extends Filter {
private static final long serialVersionUID = 6797293376134753695L;
private Filter filter;
private String key;
private static transient Map<String, BitSetCache> filterCache =
new ConcurrentHashMap<String, BitSetCache>();
public CachedQueryFilter(String key, Filter filter) {
this.filter = filter;
this.key = key;
}
public BitSet bits(IndexReader reader) throws IOException {
BitSetCache cachedBitSet = (BitSetCache) filterCache.get(key);
if (cachedBitSet != null) {
BitSet bitSet = cachedBitSet.bitSet.get();
if (bitSet != null && cachedBitSet.indexReaderVersion == reader.getVersion()) {
return bitSet;
}
}
BitSet bits = filter.bits(reader);
BitSetCache bitSetCache = new BitSetCache();
bitSetCache.indexReaderVersion = reader.getVersion();
bitSetCache.bitSet = new SoftReference<BitSet>(bits);
filterCache.put(key, bitSetCache);
return bits;
}
private class BitSetCache {
long indexReaderVersion;
SoftReference<BitSet> bitSet;
}
}
There are two additional features that this query filter doesn't implements that you may want to consider.1st - Provide per query locking around the bitset creation code. This would allow multiple bitset creation calls to occur at once, but the same access control query would block. Therefore we would only have to build it once, even if multiple user queries with the same access control hit the query filter at once.
2nd - Persist the bitsets. In the past I have used the same directory as the index, but you may want to use a database, or something else.
Any ideas on how to support field level security? E.g. if I have 10 fields, I may need different access control on each field. A user with access_control A should only get fields where access_control is A, but not see fields that have access_control B. If a different user has access_control B, then he should see fields with access_control == A or B.
Actually I am working on a library for both column/field level security along with the row level security. Basically there are 2 places where you have to enhance Lucene to add the field level security. The first place is in the query generation, I have picked the rewrite method in the Searcher. This is done to modify the query for those fields that the user may not have access to. The other place is in the document retrieval off the Searcher. To remove fields that the user does not have access to. Once I have a working prototype I will post blog about it.
This is an excellent bit of example code, many thanks for sharing it :-) One thing I'm not sure of though, the ACL filter appears to have the same effect as simply wrapping the original query and the ACL TermQuery in a boolean query. What is the advantage of the Filter with the BitSet in the second class?
Thanks,
Ralph
You are exactly right, it does indeed have the same effect. The reason to wrap it with a BitSet instead of just wrapping it up in another query is performance. Once you reach a large enough index, wrapping the user query with a ACL query could incur an extra several seconds of query time. So in a system where the majority of the ACL queries are the same, a lot of processing time can be saved by reusing the results from one ACL query (i.e. the BitSet). The use of the BitSet in this case is simply an unscored cache result from the ACL query. Hope this answers your question.