lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anshum Gupta (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
Date Wed, 29 Apr 2015 16:11:08 GMT

    [ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14519638#comment-14519638
] 

Anshum Gupta commented on SOLR-7275:
------------------------------------

>From http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html:

401:
The client MAY repeat the request with a suitable Authorization header field (section 14.8).
If the request already included Authorization credentials, then the 401 response indicates
that authorization has been refused for those credentials.

403:
The server understood the request, but is refusing to fulfill it. Authorization will not help
and the request SHOULD NOT be repeated. If the request method was not HEAD and the server
wishes to make public why the request has not been fulfilled, it SHOULD describe the reason
for the refusal in the entity.

As per what I undersand, I think 401 still makes more sense in this case.

> Pluggable authorization module in Solr
> --------------------------------------
>
>                 Key: SOLR-7275
>                 URL: https://issues.apache.org/jira/browse/SOLR-7275
>             Project: Solr
>          Issue Type: Sub-task
>            Reporter: Anshum Gupta
>            Assignee: Anshum Gupta
>         Attachments: SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch
>
>
> Solr needs an interface that makes it easy for different authorization systems to be
plugged into it. Here's what I plan on doing:
> Define an interface {{SolrAuthorizationPlugin}} with one single method {{isAuthorized}}.
This would take in a {{SolrRequestContext}} object and return an {{SolrAuthorizationResponse}}
object. The object as of now would only contain a single boolean value but in the future could
contain more information e.g. ACL for document filtering etc.
> The reason why we need a context object is so that the plugin doesn't need to understand
Solr's capabilities e.g. how to extract the name of the collection or other information from
the incoming request as there are multiple ways to specify the target collection for a request.
Similarly request type can be specified by {{qt}} or {{/handler_name}}.
> Flow:
> Request -> SolrDispatchFilter -> isAuthorized(context) -> Process/Return.
> {code}
> public interface SolrAuthorizationPlugin {
>   public SolrAuthorizationResponse isAuthorized(SolrRequestContext context);
> }
> {code}
> {code}
> public  class SolrRequestContext {
>   UserInfo; // Will contain user context from the authentication layer.
>   HTTPRequest request;
>   Enum OperationType; // Correlated with user roles.
>   String[] CollectionsAccessed;
>   String[] FieldsAccessed;
>   String Resource;
> }
> {code}
> {code}
> public class SolrAuthorizationResponse {
>   boolean authorized;
>   public boolean isAuthorized();
> }
> {code}
> User Roles: 
> * Admin
> * Collection Level:
>   * Query
>   * Update
>   * Admin
> Using this framework, an implementation could be written for specific security systems
e.g. Apache Ranger or Sentry. It would keep all the security system specific code out of Solr.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message