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

Peter Sturge commented on SOLR-1895:
------------------------------------

That makes total sense to keep a proxy app separate. 

Why wouldn't users interact with Solr directly? There's a lot of client-side 
stuff available to do just that. I wouldn't have thought there are too many 
implementations out there that completely block Solr http read access, because 
this would break replication, distributed searching, spell checkers, custom 
handlers etc. Generally, web proxies and firewalls etc. do a good job on this 
side of things, which is one of the reasons doc-level security is such a tricky 
business - you have to let traffic through and restrict it in solr.war that you 
would normally not let anywhere near Solr.

You're right that /update, /admin etc. need to be 'locked-down', but this is 
quite strightforward, so as not to allow users access to write or change 
anything.



> LCF SearchComponent plugin for enforcing LCF 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
>             Fix For: 1.5
>
>         Attachments: LCFSecurityFilter.java, LCFSecurityFilter.java, 
> LCFSecurityFilter.java
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to