lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karl Wright (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-1895) ManifoldCF SearchComponent plugin for enforcing ManifoldCF security at search time
Date Wed, 21 Sep 2011 06:03:15 GMT

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

Karl Wright commented on SOLR-1895:
-----------------------------------

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

I agree - there should be a unified framework to the degree feasible.  This would allow common
testing and reasonable maintenance across Lucene and Solr versions for the future.

For ManifoldCF, there's also an unrelated release-engineering question, specifically for the
ManifoldCF-specific portion of the proposal, which is why we'd think introducing a code dependency
on something like Solr/Lucene would be a good idea, especially since we'd be building a jar
specifically for deployment within Solr.  We do this reluctantly for a couple of other connectors
but it's a complete one-of each time and requires a great deal of work by end users.  This
inconvenience greatly impacts the level of deployment of the affected connectors.  Since Solr
is Apache licensed we could make this easier in Solr's case, but probably not without redistributing
a specific version of Solr and Lucene, and providing build targets which fire up an already
configured Solr/Lucene instance.  We would need this also for testing, if the plugin code
lived in ManifoldCF.  It is also the case that the current ManifoldCF search component needed
significant rework even to build between version 3.x and version 4.x, because many of the
classes that were necessary changed their packages.  Thus we'd need to redistribute more than
one Solr/Lucene instance, and release perhaps twice as frequently to keep up.

Given all that, does everyone still think it is desirable for ManifoldCF to build Solr components
itself?  The alternative would be a Solr contrib module, which I'd be very happy with.  To
me, it is the obvious choice if you want a straightforward overall user experience.  The underlying
http-based protocol that the component will need to use is well-defined, quite complete, and
is unlikely to 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message