[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14494296#comment-14494296 ]
Anshum Gupta commented on SOLR-7275: ------------------------------------ bq. Do the initialization and other things of Authorization plugin in CoreContainer Sure, I'll move it. bq. why multiple json files? /security.json and /simplesecurity.json ? They are used for 2 different reasons, the /security.json is the one used for/by Solr's framework whereas /simplesecurity.json could also be called anything else tomorrow and is used by a specific implementation. Doesn't make any sense to merge the 2 and Solr be bothered about a specific plugin data. bq. Why should a component use SolrZkClient directly to read configuration? Is there a reason not to? The client would need information about zk and also might need to read information about it, I don't see a reason why we should create a new zkclient there. > 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 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org