lucene-solr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Solr Wiki] Update of "SolrSecurity" by Per Steffensen
Date Wed, 06 Mar 2013 15:09:10 GMT
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 Per Steffensen:
http://wiki.apache.org/solr/SolrSecurity?action=diff&rev1=28&rev2=29

  }}}
  
  This is standardized for all servlet containers and will set up security with the following
properties
- * Authentication: You have to authenticate to access any path starting with "/core1/". Other
paths can be accessed without authenticating. Authentication will have to be performed against
a "realm" called "Test Realm". The "realm" will verify credentials
+  * Authentication: You have to authenticate to access any path starting with "/core1/".
Other paths can be accessed without authenticating. Authentication will have to be performed
against a "realm" called "Test Realm". The "realm" will verify credentials
- * Authorization: The configuration above also states that you will actually have to be part
of the "role" "core1-role" in order to be authorized for "/core1/" paths. The "realm" will
also, in case credentials where verified successfully, provide a set of "roles" that the authenticated
user is part of.
+  * Authorization: The configuration above also states that you will actually have to be
part of the "role" "core1-role" in order to be authorized for "/core1/" paths. The "realm"
will also, in case credentials where verified successfully, provide a set of "roles" that
the authenticated user is part of.
  
  Unfortunately it has not been standardized how to actually set up a "realm" in a servlet
container, so its different from servlet container to servlet container.
  
@@ -131, +131 @@

  === Security for inter-solr-node requests ===
  
  Without [[https://issues.apache.org/jira/browse/SOLR-4470|SOLR-4470]], in a cluster/cloud/distributed
installation with several solr-nodes communicating internally, in practice you would not be
able to add security constraint on most paths, because inter-solr-node communication (potentially)
involves requests to most paths, and solr-nodes where not able to provide credentials in those
internal solr-to-solr requests. [[https://issues.apache.org/jira/browse/SOLR-4470|SOLR-4470]]
introduces this ability. Basically there are two strategies for credentials to be used in
solr-to-solr requests
- * 1) Just forward credentials from the "super"-request which caused the inter-solr-node
"sub"-requests
+  * 1) Just forward credentials from the "super"-request which caused the inter-solr-node
"sub"-requests
- * 2) Use "internal credentials" provided to the solr-node by the administrator at startup
+  * 2) Use "internal credentials" provided to the solr-node by the administrator at startup
  
  Using 1) is the most correct way, because it prevent request from "the outside" to indirectly
trigger successful inter-solr-node sub-requests that the user sending the "outside request"
is not allowed to perform directly himself. Therefore 1) should be used whenever feasible.
But there are cases where inter-solr-node requests are not a direct reaction to requests coming
from "the outside" - e.g. requests around shard-synchronization. In such cases 2) will have
to be used - you have no other credentials to use, and you certainly (potentially) want to
be able to protect e.g. shard-synchronization paths. There are also border-cases like e.g.
when a request from "the outside" triggers inter-solr-node requests to be issued asynchronously
- e.g. when a request from "the outside" to the Collections API makes the Overseer send inter-solr-node
request to the CoreAdmin API. In such case 1) ought to be used, but that would require to
persist the credentials from the original request and reuse them when sub-request to CoreAdmin
API is eventually performed. The current implementation in [[https://issues.apache.org/jira/browse/SOLR-4470|SOLR-4470]]
just uses 2) in such cases.
  
@@ -201, +201 @@

  === Security in Solr on per-operation basis ===
  
  Due to limitations on "url-pattern"'s in web.xml and the structure of URLs in Solr, it is
hard to set up path based authentication on per-type-of-operation basis
- * url-pattern limitations: Wildcards are only allowed "in the end" (e.g. "/core1/*") or
as "extension patterns" (e.g. "*.jsp" - the . is required)
+  * url-pattern limitations: Wildcards are only allowed "in the end" (e.g. "/core1/*") or
as "extension patterns" (e.g. "*.jsp" - the . is required)
- * Solr URL-structure: Solr URLs are structured as <core-or-collection-name>/<operation>
(e.g. /core1/update)
+  * Solr URL-structure: Solr URLs are structured as <core-or-collection-name>/<operation>
(e.g. /core1/update)
  Those facts makes it easy to set up path based authentication on per-collection/core basis.
E.g. url-pattern "/core1/*" matchs all operations on core1. On the other hand, it makes it
hard to set up path based authentication on operation basis. Lets say you want a url-pattern
matching "updates" but across all cores/collections, you cannot just use url-pattern "/solr/*/update",
"*/update" or "*update" - its not allowed in url-patterns. Different servlet containers provide
different solutions to this problem, but [[https://issues.apache.org/jira/browse/SOLR-4470|SOLR-4470]]
also provides a solution as part of solr itself.
  
  The solution is provided in org.apache.solr.servlet.security.RegExpAuthorizationFilter.
This is a normal filter that can be used to handle the authorization part of security, still
leaving authentication to the servlet container (web.xml).
@@ -247, +247 @@

  </filter-mapping>
  }}}
  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
+  * ''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"
+  * ''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. 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. Of 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".
+  * ''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. Of 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".
  
  === Resin example ===
  

Mime
View raw message