[
https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14494317#comment-14494317
]
Anshum Gupta commented on SOLR-7275:
------------------------------------
Thanks for looking at this Shalin.
bq. please create a different linked issue for a default/basic implementation.
Sure, that makes sense. I'll split it and create a new sub-issue.
bq. We need to define the contract between this new plugin type and Solr better.
I did try to answer most of those questions in the write up above but I'm happy
to explain that again.
* This framework is a cluster level configuration (and hence the need to
specify and set up the implementation before starting a node).
* It gets created in the init for SDF.
* The configuration goes into /security.json (implementation to use) and plugin
details go into plugin-specific file/mechanism e.g. you could write your own
plugin that has hard-coded list for IPs or usernames or combination etc.
* You can only have 1 such plugin used by a cluster at any given point (there's
no check for that and the node would end up using the implementation defined in
/security.json when it comes up.
* As this happens at CoreContainer level, I didn't add anything to change the
implementation type for plugin but I'm working on configuration changes. The
change would need to be handled by the plugin writer e.g. in case of the OTB
plugin, which depends on access rules stored in zk, it needs to watch that file
for changes and update the blacklist accordingly. For cases involving 3rd party
security mechanisms e.g. Apache Ranger/Sentry, the config changes would be
handled by those plugins. When a request comes in after the access rules are
updated, the plugin should be able to use the new rules from Ranger, without
any need to update anything in Solr.
* I'm moving this to be initialized and kept in the corecontainer, and also
adding a shutdown hook for the plugins. The hook would get invoked during the
corecontainer shutdown.
> 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
