[
https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109292#comment-13109292
]
Karl Wright edited comment on SOLR-1895 at 9/21/11 6:06 AM:
------------------------------------------------------------
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. I don't
understand why we'd believe that 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 always 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 Lucene/Solr 3.x and version 4.x, because many of the classes
that were used changed their packages. Thus we'd likely need to redistribute
more than one Solr/Lucene instance at a time, and release perhaps twice as
frequently as we currently do just to keep up with the Solr/Lucene release
schedule.
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. The required dependencies (commons-httpclient) are already
redistributed by Solr, so that shouldn't be a problem either.
was (Author: kwri...@metacarta.com):
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
