am aware of this ticket and contribution. Luckily LCF establishes a
powerful multi-repository security model, even though it doesn't yet do the
final step of enforcing that model at the search end. LCF allows you
to define multiple authorities to operate against disparate repositories,
and use the appropriate authority to secure any given document. The
solr people are aware of this design, which addresses the issues raised by
SOLR-1834 very nicely. However, as I said before, time is a problem,
and the work still needs to be done.
suggest you read up on the actual security model of LCF, and perhaps
experiment with that and the SOLR-1834 contribution, to see if there is
common ground. One thing we've learned at MetaCarta is that
post-filtering for security purposes is expensive, and it is better
to modify the queries themselves to restrict the results, if
possible. I'm not sure which approach SOLR-1834 takes, although it
sounds like it might be the filtering approach. Still, it would be
better than nothing.
let me know what you find out.
Thank you for your reply.
I made some
research today and I found this :http://freesurf001.appspot.com/issues.apache.org/jira/browse/SOLR-1834http://demo.findwise.se:8880/SolrSecurity/
security model have to be able to filter result list with items coming from
various sources at the same time (livelink, documentum, file system, ...).
Big subject :)
Le 20/04/10 13:34, email@example.com
a écrit :
moment, in order to enforce the LCF security model within Lucene/Solr, you
will need to build this functionality into whatever client you are
using to display the Lucene search results. Specifically, you would
need to take the following steps:
Have your users access your search client through
Use the Apache module mod_auth_kerb, combined with LCF's
mod_authz_annotate, to cause authorization HTTP headers to be transmitted
to the client webapp.
Have your client webapp alter whatever queries it is doing, to add an
appropriate query clause for each of the access tokens transmitted in the
is how it is done at MetaCarta.)
Alternatively, you may find a way to do this completely with
a web application under a Java app server such as Tomcat. I have not
yet done the research to find out whether this is a feasible
alternative. Effectively, what you need something like mod_auth_kerb
to do is to authenticate your user against Active Directory, or whomever
the authenticator ought to be. JAAS may be helpful
are, of course, intentions to fill out the missing pieces more completely
and transparently via a Solr search plugin and/or filter. What has
been lacking is time. If you are in a position to do development in
this area, we're happy to have any assistance you might provide.
I don't see in LCF wiki how Solr and LCF works together
at query time in order to remove from the result list the items the user
is not allowed to access.
I just see these sentences :
" Once all these documents and their
access tokens are handed to the search engine, it is the search engine's
job to enforce security by excluding inappropriate documents from the
search results. For Lucene
infrastructure is expected to be built on top of Lucene's generic metadata
abilities, but has not been implemented at this time."
I am not
sure to understand. Does this mean that for the moment, it is not possible
for Solr to apply security by using an Authority Connector