[jira] [Resolved] (SOLR-1872) Document-level Access Control in Solr
[
https://issues.apache.org/jira/browse/SOLR-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl resolved SOLR-1872.
---
Resolution: Won't Fix
Resolving old issue as won't fix. A lot of infrastructure in Solr has changed
since, and it is actually quite easy to bolt on doc-level security using a
custom QueryParser (preferred?) or SearchComponent, coupled with whatever
schema fields you store your ACLs in. Given the wildly different
implementations this kind of plugin is better left with the Application than in
Solr, see e.g. ManifoldCF's Solr plugins for doc-level security which reaches
out to the MCF's Authority service.
> Document-level Access Control in Solr
> -
>
> Key: SOLR-1872
> URL: https://issues.apache.org/jira/browse/SOLR-1872
> Project: Solr
> Issue Type: New Feature
> Components: SearchComponents - other
>Affects Versions: 1.4
> Environment: Solr 1.4
>Reporter: Peter Sturge
>Priority: Minor
> Labels: access, control
> Attachments: ASF.LICENSE.NOT.GRANTED--SolrACLSecurity.java,
> ASF.LICENSE.NOT.GRANTED--SolrACLSecurity.java, SolrACLSecurity.rar
>
>
> This issue relates to providing document-level access control for Solr index
> data.
> A related JIRA issue is: SOLR-1834. I thought it would be best if I created a
> separate JIRA issue, rather than tack on to SOLR-1834, as the approach here
> is somewhat different, and I didn't want to confuse things or step on Anders'
> good work.
> There have been lots of discussions about document-level access in Solr using
> LCF, custom comoponents and the like. Access Control is one of those subjects
> that quickly spreads to lots of 'ratholes' to dive into. Even if not everyone
> agrees with the approaches taken here, it does, at the very least, highlight
> some of the salient issues surrounding access control in Solr, and will
> hopefully initiate a healthy discussion on the range of related requirements,
> with the aim of finding the optimum balance of requirements.
> The approach taken here is document and schema agnostic - i.e. the access
> control is independant of what is or will be in the index, and no schema
> changes are required. This version doesn't include LDAP/AD integration, but
> could be added relatively easily (see Ander's very good work on this in
> SOLR-1834). Note that, at the moment, this version doesn't deal with /update,
> /replication etc., it's currently a /select thing at the moment (but it could
> be used for these).
> This approach uses a SearchComponent subclass called SolrACLSecurity. Its
> configuration is read in from solrconfig.xml in the usual way, and the
> allow/deny configuration is split out into a config file called acl.xml.
> acl.xml defines a number of users and groups (and 1 global for 'everyone'),
> and assigns 0 or more {{}} and/or {{}} elements.
> When the SearchComponent is initialized, user objects are created and cached,
> including an 'allow' list and a 'deny' list.
> When a request comes in, these lists are used to build filter queries
> ('allows' are OR'ed and 'denies' are NAND'ed), and then added to the query
> request.
> Because the allow and deny elements are simply subsearch queries (e.g.
> {{somefield:secret}}, this mechanism will work on any
> stored data that can be queried, including already existing data.
> Authentication
> One of the sticky problems with access control is how to determine who's
> asking for data. There are many approaches, and to stay in the generic vein
> the current mechanism uses http parameters for this.
> For an initial search, a client includes a {{username=somename}} parameter
> and a {{hash=pwdhash}} hash of its password. If the request sends the correct
> parameters, the search is granted and a uuid parameter is returned in the
> response header. This uuid can then be used in subsequent requests from the
> client. If the request is wrong, the SearchComponent fails and will increment
> the user's failed login count (if a valid user was specified). If this count
> exceeds the configured lockoutThreshold, no further requests are granted
> until the lockoutTime has elapsed.
> This mechanism protects against some types of attacks (e.g. CLRF, dictionary
> etc.), but it really needs container HTTPS as well (as would most other auth
> implementations). Incorporating SSL certificates for authentication and
> making the authentication mechanism pluggable would be a nice improvement
> (i.e. separate authentication from access control).
> Another issue is how internal searchers perform autowarming etc. The solution
> here is to use a local key called 'SolrACLSecurityKey'. This key is local and
> [should be] unique to that server. firstSearcher, newSearcher et al then
> include this key in their parameters so
[jira] [Resolved] (SOLR-1872) Document-level Access Control in Solr
[
https://issues.apache.org/jira/browse/SOLR-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson resolved SOLR-1872.
--
Resolution: Won't Fix
2013 Old JIRA cleanup
Document-level Access Control in Solr
-
Key: SOLR-1872
URL: https://issues.apache.org/jira/browse/SOLR-1872
Project: Solr
Issue Type: New Feature
Components: SearchComponents - other
Affects Versions: 1.4
Environment: Solr 1.4
Reporter: Peter Sturge
Priority: Minor
Labels: access, control
Attachments: ASF.LICENSE.NOT.GRANTED--SolrACLSecurity.java,
ASF.LICENSE.NOT.GRANTED--SolrACLSecurity.java, SolrACLSecurity.rar
This issue relates to providing document-level access control for Solr index
data.
A related JIRA issue is: SOLR-1834. I thought it would be best if I created a
separate JIRA issue, rather than tack on to SOLR-1834, as the approach here
is somewhat different, and I didn't want to confuse things or step on Anders'
good work.
There have been lots of discussions about document-level access in Solr using
LCF, custom comoponents and the like. Access Control is one of those subjects
that quickly spreads to lots of 'ratholes' to dive into. Even if not everyone
agrees with the approaches taken here, it does, at the very least, highlight
some of the salient issues surrounding access control in Solr, and will
hopefully initiate a healthy discussion on the range of related requirements,
with the aim of finding the optimum balance of requirements.
The approach taken here is document and schema agnostic - i.e. the access
control is independant of what is or will be in the index, and no schema
changes are required. This version doesn't include LDAP/AD integration, but
could be added relatively easily (see Ander's very good work on this in
SOLR-1834). Note that, at the moment, this version doesn't deal with /update,
/replication etc., it's currently a /select thing at the moment (but it could
be used for these).
This approach uses a SearchComponent subclass called SolrACLSecurity. Its
configuration is read in from solrconfig.xml in the usual way, and the
allow/deny configuration is split out into a config file called acl.xml.
acl.xml defines a number of users and groups (and 1 global for 'everyone'),
and assigns 0 or more {{acl-allow}} and/or {{acl-deny}} elements.
When the SearchComponent is initialized, user objects are created and cached,
including an 'allow' list and a 'deny' list.
When a request comes in, these lists are used to build filter queries
('allows' are OR'ed and 'denies' are NAND'ed), and then added to the query
request.
Because the allow and deny elements are simply subsearch queries (e.g.
{{acl-allowsomefield:secret/acl-allow}}, this mechanism will work on any
stored data that can be queried, including already existing data.
Authentication
One of the sticky problems with access control is how to determine who's
asking for data. There are many approaches, and to stay in the generic vein
the current mechanism uses http parameters for this.
For an initial search, a client includes a {{username=somename}} parameter
and a {{hash=pwdhash}} hash of its password. If the request sends the correct
parameters, the search is granted and a uuid parameter is returned in the
response header. This uuid can then be used in subsequent requests from the
client. If the request is wrong, the SearchComponent fails and will increment
the user's failed login count (if a valid user was specified). If this count
exceeds the configured lockoutThreshold, no further requests are granted
until the lockoutTime has elapsed.
This mechanism protects against some types of attacks (e.g. CLRF, dictionary
etc.), but it really needs container HTTPS as well (as would most other auth
implementations). Incorporating SSL certificates for authentication and
making the authentication mechanism pluggable would be a nice improvement
(i.e. separate authentication from access control).
Another issue is how internal searchers perform autowarming etc. The solution
here is to use a local key called 'SolrACLSecurityKey'. This key is local and
[should be] unique to that server. firstSearcher, newSearcher et al then
include this key in their parameters so they can perform autowarming without
constraint. Again, there are likely many ways to achieve this, this approach
is but one.
The attached rar holds the source and associated configuration. This has been
tested on the 1.4 release codebase (search in the attached solrconfig.xml for
SolrACLSecurity to find the relevant sections in this file).
I hope this proves helpful for people who are looking for this sort of
functionality in Solr, and more generally to address how such a mechanism
