[jira] Issue Comment Edited: (SOLR-1872) Document-level Access Control in Solr
[
https://issues.apache.org/jira/browse/SOLR-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12855698#action_12855698
]
Peter Sturge edited comment on SOLR-1872 at 4/11/10 6:18 AM:
-
This update adds in optional auditing of searches by users and failed access
attempts, plus a few minor tweaks.
To configure auditing, here is a sample searchComponent section from
solrconfg.xml:
{code}
zxb79j3g76A79N8N2AbR0K852976qr1klt86xv436j2
acl.xml
true
10
1
audit.log
5
15
{code}
was (Author: midiman):
This update adds in optional auditing of searches by users and failed
access attempts, plus a few minor tweaks.
To configure auditing, here is a sample searchComponent section from
solrconfg.xml:
{{
zxb79j3g76A79N8N2AbR0K852976qr1klt86xv436j2
acl.xml
true
10
1
audit.log
5
15
}}
> 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
> Attachments: 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
[jira] Issue Comment Edited: (SOLR-1872) Document-level Access Control in Solr
[
https://issues.apache.org/jira/browse/SOLR-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12855698#action_12855698
]
Peter Sturge edited comment on SOLR-1872 at 4/11/10 6:16 AM:
-
This update adds in optional auditing of searches by users and failed access
attempts, plus a few minor tweaks.
To configure auditing, here is a sample searchComponent section from
solrconfg.xml:
{{
zxb79j3g76A79N8N2AbR0K852976qr1klt86xv436j2
acl.xml
true
10
1
audit.log
5
15
}}
was (Author: midiman):
This update adds in optional auditing of searches by users and failed
access attempts, plus a few minor tweaks.
To configure auditing, here is a sample searchComponent section from
solrconfg.xml:
{{
zxb79j3g76A79N8N2AbR0K852976qr1klt86xv436j2
acl.xml
true
10
1
audit.log
5
15
}}
> 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
> Attachments: 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
