[ 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