What Ken describes is called 'role-based' security. Users have roles, and security items talk about roles, not users.
http://en.wikipedia.org/wiki/Role-based_access_control On Tue, Jul 6, 2010 at 3:15 PM, Peter Sturge <peter.stu...@gmail.com> wrote: > Yes, you don't want to hard code permissions into your index - it will give > you headaches. > > You might want to have a look at SOLR 1872: > https://issues.apache.org/jira/browse/SOLR-1872 . > This patch provides doc level security through an external ACL mechanism (in > this case, an XML file) controlling a filter query, > This way, you don't need to change the schema - you can even use existing > indexes, and you can change access control without affecting your stored > data. > > HTH, > Peter > > > On Tue, Jul 6, 2010 at 5:16 PM, Ken Krugler > <kkrugler_li...@transpac.com>wrote: > >> >> On Jul 6, 2010, at 8:27am, osocurious2 wrote: >> >> >>> Someone else was recently asking a similar question (or maybe it was you >>> but >>> worded differently :) ). >>> >>> Putting user level security at a document level seems like a recipe for >>> pain. Solr/Lucene don't do frequent update well...and being highly >>> optimized >>> for query, I don't blame them. Is there any way to create a series of >>> roles >>> that you can apply to your documents? If the security level of the >>> document >>> isn't changing, just the user access to them, give the docs a role in the >>> index, put your user/usergroup stuff in a DB or some other system and >>> resolve your user into valid roles, then FilterQuery on role. >>> >> >> You're right, baking in too fine-grained a level of security information is >> a bad idea. >> >> As one example that worked pretty well for code search with Krugle, we set >> access control on a per project level using LDAP groups - ie each project >> had some number of groups that were granted access rights. Each file in the >> project would inherit the same list of groups. >> >> Then, when a user logs in they get authenticated via LDAP, and we have the >> set of groups they belong to being returned by the LDAP server. This then >> becomes a fairly well-bounded list of "terms" for an OR query against the >> "acl-groups" field in each file/project document. Just don't forget to set >> the boost to 0 for that portion of the query :) >> >> -- Ken >> >> -------------------------------------------- >> Ken Krugler >> +1 530-210-6378 >> http://bixolabs.com >> e l a s t i c w e b m i n i n g >> >> >> >> >> > -- Lance Norskog goks...@gmail.com
