Current state of affairs
SSL support is added in version 4.2 (Solrcloud v4.7).
- Protection of Zookeeper content through ACLs is added in version 5.0
Authentication and Authorization plugin support is added in 5.2 (Solrcloud only)
Basic Auth & Kerberos plugins and rule-based Authorization plugin is added in 5.3
There is (as of 5.3) No role-based restrictions on the Admin UI, so being aware that anyone with access to Admin UI would be a ble to does anything with your system.
Need for Firewall
Even though you add SSL or authentication plugins, it's still strongly recommended that the application server containing SOLR is firewalled such the only clients with access to SOLR is your own. A default/example installation of SOLR allows any client with access to it to add, update, and delete documents (and of CO Urse search/read too), including access to the SOLR configuration and schema files and the administrative user interface.
If there is a need to provide query access to a SOLR server from the open Internet, it's highly recommended to use a ProX Y, such as one of these.
Cross-site Scripting (XSS)
SOLR has no known cross-site scripting vulnerabilities.
Quick XSS Tip:
Problem:what if want the browser to highlight text, but you also want to protect yourself from XSS and escape the HTM L output? Solution:one solution is to escape the HTML output and then reapply the EM tags. Now the rest of the snippet is safe and the browser would recognize the highlighted text.
For example, with Groovy/grails you could has the following in your controller:
Snippet == Snippet.replaceall ('<em> ' ' <em> ' = Snippet.replaceall ('</em> ', </em>)
Cross-site Request Forgery (CSRF)
Even if a SOLR instance is protected by good firewalls so and "bad guys" has no direct access, that's instance may are at R ISK to potential "cross-site Request forgery" based attacks if the following is all true:
- Some number of "good guys" has direct access to that SOLR instance from their web Browsers.
- A" bad guy "knows/guesses the Host:port/path of the SOLR instance (even though th EY can not access it directly)
- The bad guy can trick one of the good GU Y into clicking a maliciously crafted URLs, or loading a webpage that contains malicious javascript.
This is because SOLR's most basic behavior are to receive updates and deletes via HTTP. If you had a firewall or other security measure restricting SOLR ' s/update handler so it's only accepts connections from AP Proved hosts/clients, but is approved then you could inadvertently is tricked into loading a Web page that I Nitiates an HTTP Connection to SOLR on your behalf.
It's important to keep the when thinking about what it means to "secure" an instance of SOLR (if you had not ALR Eady).
A basic technique that can being used to mitigate the risk of a possible CSRF attack like this was to configure your Servlet C Ontainer so this access to paths which can modify the index (ie:/update,/update/csv, etc ...) is restricted either to SP Ecific client IPs, or using HTTP authentication.
Document level Security
Manifold CF (Connector Framework)
One-to-add document level security to your search is through Apache MANIFOLDCF. MANIFOLDCF "defines a security model for target repositories this permits them to enforce source-repository security polic IES ".
It works by adding security tokens from the source repositories as metadata on the indexed documents. Then in query time, a Search Component adds a filter to all queries, matching only documents the Logged-in user is Allowe D to see. MANIFOLDCF supports AD security out of the box.
Write Your Own RequestHandler or Searchcomponent
*stub-this is incomplete*
If MANIFOLDCF does not solve your need, first consider writing a MANIFOLDCF plugin. Or roll your own.
If you need permission based authentication – where user A can update document 1 and 2, but not 3 – you'll need to ment the request with the user information. Either can add parameters to the query string (? u=xxx&p=yyy) or use a custom dispatcher filter that augments the C Ontext:
Public classCustomdispatchfilter extends solrdispatchfilter{@Overrideprotected voidExecute (httpservletrequest req, Solrrequesthandler handler, Solrqueryrequest sreq, solrqueryresponse RSP) {//Perhaps the whole requestSreq.getcontext (). Put ("HttpServletRequest", req); //or maybe just the userSreq.getcontext (). Put ("User", Req.getremoteuser ()); Core.execute (Handler, sreq, RSP); }} Public classAuthenticatinghandler extends requesthandlerbase{@Override Public voidHandlerequestbody (solrqueryrequest req, solrqueryresponse RSP) throws Exception {HttpServletRequest httpreq =(HttpServletRequest) Req.getcontext ().Get("HttpServletRequest" ); if(Httpreq.isuserinrole ("Editor" ) ) { ... } String User= (String) req.getcontext ().Get("User" ); ... } ...}
Streaming consideration
If streaming is enabled, you need to make sure SOLR are as secure as it needs to be. When streaming is enabled, the parameters "Stream.url" would go to a remote site and download the content. Likewise, "Stream.file" would read a file on disk.
Streaming is disabled by default and was configured from Solrconfig.xml
<requestparsers enableremotestreaming="false" .../>
In Tomcat6, add SOLR access to the following methods:
Edit Tomcat6/catalina/localhost/solr.xml
<context docbase="/var/solr/solr.war"debug="0"Privileged="true"allowlinking="true"crosscontext="true"><environment name="Solr/home"Type="java.lang.String"Value="/VAR/SOLR" Override="true"/><valve classname="Org.apache.catalina.valves.RemoteAddrValve"allow="192.168.1.100,localhost,192.168.1.103,127.0.0.1"/><valve classname="Org.apache.catalina.valves.RemoteAddrValve"deny="192.168.1.105"/></context>
Refer to the Tomcat configuration documentation: Http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html#Remote_Address_Filter
To enable the above configuration to take effect, you will also need to re-enable the Tomcat security mechanism
Edit sudo vi/etc/default/tomcat6
Comment out the last sentence Tomcat6_security=no
Reference:
Http://www.cnblogs.com/ibook360/archive/2011/11/07/2239247.html
Http://wiki.apache.org/solr/SolrSecurity
Apache SOLR access Rights control