[
https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862191#action_12862191
]
Peter Sturge commented on SOLR-1895:
------------------------------------
>>>>>>
The presumption is that the Solr webapp is not the final user interface, and is
indeed not accessible to the user at all.
<<<<<<
Given that search requests are http-based, how would this be done, in say, an
intranet environment? I agree that a user interface wouldn't expose any means
to change the http parameters, but if http is available to the UI, it'll also
be available to a web browser's search bar at the same station (unless some
tunnelling, proxy or similar is used).
Totally agree on the server lock down - hopefully, everyone does this already
as a matter of course!
There are a couple of ways to address the impersonator problem. Probably the
most robust way is to use SSL authentication from client to container, then
have the Solr app integrate with the container (like we talked about for the
authentication piece) and use its session certificate to ensure that any
requests coming from the remote station match those of the originally
authenticated user.
A somewhat easier method is to use the hash and session id mechanism used in
SOLR-1872. This provides pgp protection for stopping impersonation (even
gaining any access from a browser), but wouldn't be suitable outside of an
intranet environment (for exposed internet access, it would really need to be
SSL - for sensitive data, though, you wouldn't expect it to be exposed across a
DMZ anyway).
> 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]
