Forgot to add, 3/ The external, application code selects the GROUPS that the user has permission to read (Solr will only serve up what is to be read?) then search on those groups.
Dennis Gearon Signature Warning ---------------- It is always a good idea to learn from your own mistakes. It is usually a better idea to learn from others’ mistakes, so you do not have to make them yourself. from 'http://blogs.techrepublic.com.com/security/?p=4501&tag=nl.e036' EARTH has a Right To Life, otherwise we all die. --- On Sat, 10/23/10, Dennis Gearon <gear...@sbcglobal.net> wrote: > From: Dennis Gearon <gear...@sbcglobal.net> > Subject: Re: Modelling Access Control > To: solr-user@lucene.apache.org > Date: Saturday, October 23, 2010, 11:49 AM > Two things will lessen the solr > admininstrative load : > > 1/ Follow examples of databases and *nix OSs. Give each > user their own group, or set up groups that don't have > regular users as OWNERS, but can have users assigned to the > group to give them particular permissions. I.E. Roles, like > publishers, reviewers, friends, etc. > > 2/ Put your ACL outside of Solr, using your > server-side/command line language's object oriented > properties. Force all searches to come from a single > location in code (not sure how to do that), and make the > piece of code check authentication and authorization. > > This is what my research shows how others do it, and how I > plan to do it. ANY insight others have on this, I really > want to hear. > > Dennis Gearon > > Signature Warning > ---------------- > It is always a good idea to learn from your own mistakes. > It is usually a better idea to learn from others’ > mistakes, so you do not have to make them yourself. from > 'http://blogs.techrepublic.com.com/security/?p=4501&tag=nl.e036' > > EARTH has a Right To Life, > otherwise we all die. > > > --- On Sat, 10/23/10, Paul Carey <paul.p.ca...@gmail.com> > wrote: > > > From: Paul Carey <paul.p.ca...@gmail.com> > > Subject: Modelling Access Control > > To: solr-user@lucene.apache.org > > Date: Saturday, October 23, 2010, 1:03 AM > > Hi > > > > My domain model is made of users that have access to > > projects which > > are composed of items. I'm hoping to use Solr and > would > > like to make > > sure that searches only return results for items that > users > > have > > access to. > > > > I've looked over some of the older posts on this > mailing > > list about > > access control and saw a suggestion along the lines > of > > acl:<user_id> AND (actual query). > > > > While this obviously works, there are a couple of > niggles. > > Every item > > must have a list of valid user ids (typically less > than 100 > > in my > > case). Every time a collaborator is added to or > removed > > from a > > project, I need to update every item in that project. > This > > will > > typically be fewer than 1000 items, so I guess is no > big > > deal. > > > > I wondered if the following might be a reasonable > > alternative, > > assuming the number of projects to which a user has > access > > is lower > > than a certain bound. > > (acl:<project_id> OR acl:<project_id> OR > ... ) > > AND (actual query) > > > > When the numbers are small - e.g. each user has access > to > > ~20 projects > > and each project has ~20 collaborators - is one > approach > > preferable > > over another? And when outliers exist - e.g. a project > with > > 2000 > > collaborators, or a user with access to 2000 projects > - is > > one > > approach more liable to fail than the other? > > > > Many thanks > > > > Paul > > >
