lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <karl.wri...@nokia.com>
Subject RE: FW: Solr and LCF security at query time
Date Tue, 20 Apr 2010 15:08:50 GMT
SOLR-1872 looks exactly like what I was envisioning, from the search query perspective, although
instead of the acl xml file you specify LCF stipulates you would dynamically query the lcf-authority-service
servlet for the access tokens themselves.  That would get you support for AD, Documentum,
LiveLink, Meridio, and Memex for free. It seems likely that this component could be modified
to work with LCF with minor effort.

The missing component still seems to be AD authentication, which needs a solution.

Karl

________________________________
From: ext Peter Sturge [mailto:peter.sturge@googlemail.com]
Sent: Tuesday, April 20, 2010 10:44 AM
To: dev@lucene.apache.org
Subject: Re: FW: Solr and LCF security at query time

If you want to do this completely within Solr, have a look at:
SOLR-1834 and SOLR-1872. These use a SearchComponent plugin for Solr.

Thanks,
Peter



On Tue, Apr 20, 2010 at 1:25 PM, <karl.wright@nokia.com<mailto:karl.wright@nokia.com>>
wrote:
FYI

________________________________
From: Wright Karl (Nokia-S/Cambridge)
Sent: Tuesday, April 20, 2010 8:16 AM
To: 'dominique.bejean@eolya.fr<mailto:dominique.bejean@eolya.fr>'
Cc: 'solr-dev@apache.org<mailto:solr-dev@apache.org>'; 'connectors-dev@incubator.apache.org<mailto:connectors-dev@incubator.apache.org>';
'connectors-user@incubator.apache.org<mailto:connectors-user@incubator.apache.org>'
Subject: RE: Solr and LCF security at query time

Dominique,

Yes, I 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.

I 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.

Please let me know what you find out.

Thanks,
Karl

________________________________
From: ext Dominique Bejean [mailto:dominique.bejean@eolya.fr<mailto:dominique.bejean@eolya.fr>]
Sent: Tuesday, April 20, 2010 8:03 AM
To: Wright Karl (Nokia-S/Cambridge)
Cc: connectors-user@incubator.apache.org<mailto:connectors-user@incubator.apache.org>;
connectors-dev@incubator.apache.org<mailto:connectors-dev@incubator.apache.org>
Subject: Re: Solr and LCF security at query time

Karl,

Thank you for your reply.

I made some research today and I found this :
http://freesurf001.appspot.com/issues.apache.org/jira/browse/SOLR-1834
http://demo.findwise.se:8880/SolrSecurity/

Sorl 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 :)

Dominique


Le 20/04/10 13:34, karl.wright@nokia.com<mailto:karl.wright@nokia.com> a écrit :
Hi Dominique,

At the 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:

(1) Have your users access your search client through Apache.
(2) 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.
(3) 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 headers.

(This 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 here.

There 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.

Thanks,
Karl
________________________________
From: ext Dominique Bejean [mailto:dominique.bejean@eolya.fr]
Sent: Tuesday, April 20, 2010 5:06 AM
To: connectors-user@incubator.apache.org<mailto:connectors-user@incubator.apache.org>
Subject: Solr and LCF security at query time

Hi,

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.

In http://cwiki.apache.org/CONNECTORS/lucene-connectors-framework-concepts.html, 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, this 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 ?

Dominique


Mime
View raw message