[Solr Wiki] Update of "SolrSecurity" by ShawnHeisey

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Solr Wiki" for change notification.

The "SolrSecurity" page has been changed by ShawnHeisey:
https://wiki.apache.org/solr/SolrSecurity?action=diff&rev1=36&rev2=37

Comment:
Updated jetty paths for Solr 5.x with notes for older versions.

  = Solr Security =
  
- First and foremost, Solr does not concern itself with security either at the document level or the communication level.  It is strongly recommended that the application server containing Solr be firewalled such the only clients with access to Solr are your own.   A default/example installation of Solr allows any client with access to it to add, update, and delete documents (and of course search/read too), including access to the Solr configuration and schema files and the administrative user interface.  
+ First and foremost, Solr does not concern itself with security either at the document level or the communication level.  It is strongly recommended that the application server containing Solr be firewalled such the only clients with access to Solr are your own.   A default/example installation of Solr allows any client with access to it to add, update, and delete documents (and of course search/read too), including access to the Solr configuration and schema files and the administrative user interface.
  
- Besides limiting port access to the Solr server, standard Java web security can be added by tuning the container and the Solr web application configuration itself via web.xml.  For example, all /update URLs could require HTTP authentication. 
+ Besides limiting port access to the Solr server, standard Java web security can be added by tuning the container and the Solr web application configuration itself via web.xml.  For example, all /update URLs could require HTTP authentication.
  
  If there is a need to provide query access to a Solr server from the open internet, it is highly recommended to use a proxy, such as [[https://github.com/evolvingweb/ajax-solr/wiki/Solr-proxies|one of these]].
  
@@ -16, +16 @@

  
  Quick XSS tip:
  
- Problem: What if you want the browser to highlight text, but you also want to protect yourself from XSS and escape the HTML output?  
+ Problem: What if you want the browser to highlight text, but you also want to protect yourself from XSS and escape the HTML 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 will recognize the highlighted text.
  
  For example, with groovy/grails you could have the following in your controller:
@@ -41, +41 @@

  
  == Path Based Authentication ==
  
- Path based authentication configured at the servlet container level can be used to restrict access to urls (such as /admin and /update) to only clients specifying the correct credentials.   
+ Path based authentication configured at the servlet container level can be used to restrict access to urls (such as /admin and /update) to only clients specifying the correct credentials.
  
- Using path based authentication to limit certain clients to path based request handlers with "appends" and "invariants" is also a nice way to expose a subset of the documents and constraining or defaulting any request parameters.  
+ Using path based authentication to limit certain clients to path based request handlers with "appends" and "invariants" is also a nice way to expose a subset of the documents and constraining or defaulting any request parameters.
  
  Consider:
  
@@ -70, +70 @@

  
  === Common servlet container example ===
  
- Add this inside <web-app ..> in WEB-INF/web.xml inside solr.war (or for Jetty to /example/etc/webdefault.xml file)
+ Add this inside <web-app ..> in WEB-INF/web.xml inside solr.war.  If using the Jetty included in Solr, you can add this to server/etc/webdefault.xml (example/etc/webdefault.xml for Solr 4.x and earlier)
  {{{
    <security-constraint>
      <web-resource-collection>
@@ -98, +98 @@

  
  Edit jetty.xml
  
- In Jetty 6 Add / uncomment this section in /example/etc/jetty.xml
+ In Jetty 6 (Solr 3.x and older) add/uncomment this section in example/etc/jetty.xml
  {{{
      <Set name="UserRealms">
        <Array type="org.mortbay.jetty.security.UserRealm">
@@ -112, +112 @@

      </Set>
  }}}
  
- In Jetty 8 (which ships with Solr 4) you add this to /example/etc/jetty.xml
+ In Jetty 8 (which ships with Solr 4) you add this to server/etc/jetty.xml (example/etc/jetty.xml in Solr 4.x and older)
  {{{
  <Call name="addBean">
        <Arg>
@@ -125, +125 @@

      </Call>
  }}}
  
- /example/etc/realm.properties
+ server/etc/realm.properties (example/etc/realm.properties in Solr 4.x and older)
  {{{
  guest: guest, core1-role
  }}}
@@ -214, +214 @@

        protected void manipulateRequest( final SolrRequest request ) {
          if (request.getAuthCredentials() == null) {
            String path = request.getPath();
-           AuthCredentials credentials = AuthCredentials.createBasicAuthCredentials(<my default username>, <my default password>); 
+           AuthCredentials credentials = AuthCredentials.createBasicAuthCredentials(<my default username>, <my default password>);
            if (path.contains("/update")) {
              credentials = AuthCredentials.createBasicAuthCredentials(<my update username>, <my update password>);
            }
@@ -236, +236 @@

  
  This shows how to base64 encode the "<username>:<password>" with jquery and jquery-base64. How to easily include the credentials in actual requests issued by jquery is TBD
  {{{
- <html>                                                                  
-     <head>                                                            
+ <html>
+     <head>
          <script type="text/javascript" src="http://code.jquery.com/jquery-x.y.z.js"></script>
          <script type="text/javascript" src="https://raw.github.com/carlo/jquery-base64/master/jquery.base64.js"></script>
          <script type="text/javascript">
@@ -302, +302 @@

  The RegExpAuthorizationFilter verifies authorization by matching paths against patterns - but support regular expression patterns. The patterns and corresponding "allowed roles" are provided to RegExpAuthorizationFilter using init-params. You provide an init-param for every "rule" you want to set up. Each init-param has to have a value on the from "<order>|<comma-separated-roles>|<path-regular-expression>" where
   * ''order'' is the order of this "rule" relative to the other "rules". Unfortunately it is not enough just to make sure the "rules" are ordered correctly in the web.xml, because the init-params might not be provided to the filter in that order
   * ''comma-separated-roles'' is a comma separated list of "roles" allowed to access paths matching ''path-regular-expressoin'' of the same "rule"
-  * ''path-regular-expression'' is a regular expression (as understood by java.util.regex.Pattern) matched against the path of a particular request hitting the filter. 
+  * ''path-regular-expression'' is a regular expression (as understood by java.util.regex.Pattern) matched against the path of a particular request hitting the filter.
  RegExpAuthorizationFilter iterates "rules" in the given order, matches the request-path against its ''path-regular-expression''. If no match continues to next "rule", if match the next "rule" is never considered. If no "rules" match the request is allowed to proceed - it passed authorization so to speak. In case of a match the authenticated user will be matched against the roles in ''comma-separated-roles'' and only allowed access in case he is in one of the roles mentioned. In case he is not the filter will return a response with status-code 403 "Unauthorized".
  
  '''RegExpAuthorizationFilter is not a supported part of Solr, so use it at your own risk'''
@@ -313, +313 @@

  
  Here is an example showing how to force login for /update and /admin
  {{{
-       <web-app 
+       <web-app
-         id="/solr" 
+         id="/solr"
          document-directory="/path/to/where/it/gets/exploded"
          archive-path="/path/to/solr.war"
          character-encoding="utf-8">
-             
+ 
         <system-property solr.solr.home="/path/to/solr/data" />
-       
+ 
         <authenticator type="com.caucho.server.security.XmlAuthenticator">
            <init>
              <user>yourusername:yourpassword:user,admin</user>
@@ -329, +329 @@

          </authenticator>
         <security-constraint url-pattern='/update/*' role-name='user'/>
         <security-constraint url-pattern='/admin/*' role-name='user'/>
-        
+ 
       </web-app>
  }}}
  
@@ -348, +348 @@

  
  If you need permission based authentication -- where user A can update document 1 and 2, but not 3 -- you will need to augment the request with user information.  Either you can add parameters to the query string (?u=XXX&p=YYY) or use a custom dispatcher filter that augments the context:
  {{{
- public class CustomDispatchFilter extends SolrDispatchFilter 
+ public class CustomDispatchFilter extends SolrDispatchFilter
  {
    @Override
-   protected void execute( HttpServletRequest req, SolrRequestHandler handler, SolrQueryRequest sreq, SolrQueryResponse rsp) 
+   protected void execute( HttpServletRequest req, SolrRequestHandler handler, SolrQueryRequest sreq, SolrQueryResponse rsp)
    {
      // perhaps the whole request
      sreq.getContext().put( "HttpServletRequest", req );
@@ -364, +364 @@

  }
  
  
- public class AuthenticatingHandler extends RequestHandlerBase 
+ public class AuthenticatingHandler extends RequestHandlerBase
  {
    @Override
    public void handleRequestBody(SolrQueryRequest req, SolrQueryResponse rsp) throws Exception {
-     
+ 
      HttpServletRequest httpreq = (HttpServletRequest)
        req.getContext().get( "HttpServletRequest" );
-     
+ 
      if( httpreq.isUserInRole( "editor" ) ) {
        ...
      }