[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr

["Dennis Gove (JIRA)" <ji...@apache.org>]

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

Dennis Gove commented on SOLR-7275:
-----------------------------------

I like this concept but I think the response can be expanded to add a bit more functionality. It would be nice if the pluggable security layer could respond in such a way as to not wholly reject a request but to instead restrict what is returned from a request. It could accomplish this by providing additional filters to apply to a request.

{code}
public class SolrAuthorizationResponse {
  boolean authorized;
  String additionalFilterQuery;

  ...
}
{code}

By adding additionalFilterQuery, this would give the security layer an opportunity to say, "yup, you're authorized but you can't see records matching this filter" or "yup, you're authorized but you can only see records also matching this filter". It provides a way to add fine-grained control of data access but keep that control completely outside of SOLR (as it would live in the pluggable security layer).

Additionally, it allows the security layer to add fine-grained control **without notifying the user they are being restricted** as this lives wholly in the SOLR <---> security layer communication. There are times when telling the user their request was rejected due to it returning records they're not privileged to see actually gives the user some information you may not want them to know - the fact that these restricted records even exist. Instead, by adding filters and just not returning records the user isn't privileged for, the user is non-the-wiser that they were restricted at all.

> 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
>
> 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