[
https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112201#comment-13112201
]
Jan Høydahl commented on SOLR-1895:
-----------------------------------
@Erik:
I think we mean different things with "late binding". By "late binding", I do
not think of PostFilter in Lucene, but rather the technique of verifying for
each hit that the logged-in user has access to see it before showing it. This
fixes the issues of the search index being out of sync with the live ACLs in
the source systems during some time window after an ACL change. Combining early
and late binding provides best-in-class security. Most customers don't need it
but the most demanding do. See p14+ in
http://www.e2conf.com/archive/presentations/downloads/FO45_Bennett.pdf for more.
bq. A QParserPlugin can see all the parameters a SearchComponent can see
[createParser(String qstr, SolrParams localParams, SolrParams params,
SolrQueryRequest req)]
Ok, did not realize that. But I would not expect a qParser to mess with other
parts of the request than the query or filter that it is applied to, even if it
technically could.
{quote}
bq. ...else I think we'll start seeing a multitude of different ways to
integrate security which is not a competitive advantage for Solr
If we cannot elaborate those different ways at this point, then building a
"framework" is only asking for it to be changed later. In what scenarios would
a security filter want to modify the response?
{quote}
Isn't the reason we're seeing multiple ways of attempting to integrate security
with Solr, a lack of guidance? This component doesn't need to fix all possible
cases in first shot, but a v1.0 that works with MCF will surely be enough for
many other common token-based systems, and we'll see some of those creating
TokenServices of their own. I'll probably do a simple file-based one for demo
purposes.
bq. In what scenarios would a security filter want to modify the response?
Late binding is the most obvious example - removing hits that you are no longer
entitled to see, because of latency between source system (such as a crawler)
and the index. If e.g. all 10 hits on first page are suddenly no loger allowed,
we'll need to re-query until we fill the requested number of rows, and modify
hit counts in the response accordingly.
bq. All of these other abstractions mentioned here are overkill, IMO, to what
MCF needs...
MCF may not need more right now. But other connector frameworks will then have
a standard place to integrate doc-level security with Solr. Common code, like
how and where to pick up the authenticated userId or user from
mod_authz_annotate stays in the SearchComponent. So no matter which connectors
you use with Solr, the way of passing authenticated user to Solr does not
change.
> ManifoldCF SearchComponent plugin for enforcing ManifoldCF security at search
> time
> ----------------------------------------------------------------------------------
>
> Key: SOLR-1895
> URL: https://issues.apache.org/jira/browse/SOLR-1895
> Project: Solr
> Issue Type: New Feature
> Components: SearchComponents - other
> Reporter: Karl Wright
> Labels: document, security, solr
> Fix For: 3.5, 4.0
>
> Attachments: LCFSecurityFilter.java, LCFSecurityFilter.java,
> LCFSecurityFilter.java, LCFSecurityFilter.java,
> SOLR-1895-service-plugin.patch, SOLR-1895-service-plugin.patch,
> SOLR-1895.patch, SOLR-1895.patch, SOLR-1895.patch, SOLR-1895.patch,
> SOLR-1895.patch, SOLR-1895.patch
>
>
> I've written an LCF SearchComponent which filters returned results based on
> access tokens provided by LCF's authority service. The component requires
> you to configure the appropriate authority service URL base, e.g.:
> <!-- LCF document security enforcement component -->
> <searchComponent name="lcfSecurity" class="LCFSecurityFilter">
> <str
> name="AuthorityServiceBaseURL">http://localhost:8080/lcf-authority-service</str>
> </searchComponent>
> Also required are the following schema.xml additions:
> <!-- Security fields -->
> <field name="allow_token_document" type="string" indexed="true"
> stored="false" multiValued="true"/>
> <field name="deny_token_document" type="string" indexed="true"
> stored="false" multiValued="true"/>
> <field name="allow_token_share" type="string" indexed="true"
> stored="false" multiValued="true"/>
> <field name="deny_token_share" type="string" indexed="true" stored="false"
> multiValued="true"/>
> Finally, to tie it into the standard request handler, it seems to need to run
> last:
> <requestHandler name="standard" class="solr.SearchHandler" default="true">
> <arr name="last-components">
> <str>lcfSecurity</str>
> </arr>
> ...
> I have not set a package for this code. Nor have I been able to get it
> reviewed by someone as conversant with Solr as I would prefer. It is my
> hope, however, that this module will become part of the standard Solr 1.5
> suite of search components, since that would tie it in with LCF nicely.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
