lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Høydahl (JIRA) <j...@apache.org>
Subject [jira] [Commented] (SOLR-1895) ManifoldCF SearchComponent plugin for enforcing ManifoldCF security at search time
Date Wed, 21 Sep 2011 07:20:08 GMT

    [ https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109315#comment-13109315
] 

Jan Høydahl commented on SOLR-1895:
-----------------------------------

{quote}
bq. I think the bigger question is do we want any security scaffolding in solr, or is this
something that should always be delegated elsewhere
In this case, it really boils down to generating a handful of wildcard queries, it looks like,
but in an MCF-specific way. I'm not sure this is, yet, a pressing need to generalize a security
framework within Solr, as it's just a Query generator.
{quote}

Both fq and SearchComponent would work for early binding, but when we want to extend the model
with an (optional) late binding, i.e. filtering search results, fq won't cut it. A SearchComponent
however can be extended not only to handle early+late binding but also any other strange requirements
there may be regarding security, such as authentication by IP address, peeking at other parameters,
modifying the request (or response) in some way etc. These would fit as plugins to the Security
SearchComponent just as AccessTokenServices (for early-binding) are in current design.

I'm +1 for starting to include some built-in framework support for security, else I think
we'll start seeing a multitude of different ways to integrate security which is not a competitive
advantage for Solr. A SC is itself only a plugin anyway so we don't enforce anything on people,
but I think it makes a huge difference that it's a plugin which ships with Solr rather than
each connector having its own not-up-to-date security mechanism floating around.

In Real Life™ a deployment may include a mix of MCF and non-MCF connectors; in fact we have
two customers in that situation already. The ideal would be to move everything to MCF but
that might not be possible due to a custom or more fine-grained security model. Such a special
case is also easier to handle with SC - I don't see how to add code to merge/unify two (possibly
3rd party) QParsers, except from creating a new umbrella one.

We'll keep the "core" layer generic and thin. AccessTokenSecurityComponent and AccessTokenService
(which should perhaps be an Interface instead) go in core, while ManifoldCFAccessTokenService
and others may live wherever most convenient. I, for one, would be interested in maintaining
some of these classes, and also adding a Velocity demo of it all.

That was my +1 for SearchComponent :)

@Ryan, that's true, we only need to be concerned with authenticated user, the Velocity demo
tab could simulate the rest.

> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message