lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan McKinley (JIRA)" <>
Subject [jira] [Commented] (SOLR-1895) ManifoldCF SearchComponent plugin for enforcing ManifoldCF security at search time
Date Wed, 21 Sep 2011 02:23:09 GMT


Ryan McKinley commented on SOLR-1895:

bq. Can you give me an example of multiple filter queries being used?

Assume the user query was:
 &q=hello&fq=type:big&fq={!dismax}hello world
and the handler had appends configured as:
<lst name="appends">
  <str name="fq">{!mcf_security}</str>

the handler would behave as if the input were actually:
 &q=hello&fq=type:big&fq={!dismax}hello world&{!mcf_security}

The only hole i can point to is that i'm not sure what happens if it is specified in both
places.  I'm also not 100% sure on the shard case

I'm confident a QParser would work, but i don't see any real advantage to it over a SearchComponent.
 The purpose of a QueryParser is to *parse* the query... but this does not require any parsing.


I think the bigger question is do we want *any* security scaffolding in solr, or is this something
that should always be delegated elsewhere.  If there is strong resistance to including a general
security model, we should make that clear and not waste more time sorting out the details.

The core of this path is an allow/deny matrix to lucene Query; this is applicable to many
security strategies not just manifold.  My hope with introducing the AccessTokenService is
to separate the user-to-token mapping from how the lucene 

> ManifoldCF SearchComponent plugin for enforcing ManifoldCF security at search time
> ----------------------------------------------------------------------------------
>                 Key: SOLR-1895
>                 URL:
>             Project: Solr
>          Issue Type: New Feature
>          Components: SearchComponents - other
>            Reporter: Karl Wright
>              Labels: document, security, solr
>             Fix For: 3.5, 4.0
>         Attachments:,,,, 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"
>    <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:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message