[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15618615#comment-15618615 ] Thomas Quinot commented on SOLR-7275: - SOLR-9702 created. > 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 > Fix For: 5.2 > > Attachments: SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, > SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, > SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, > SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15618593#comment-15618593 ] Thomas Quinot commented on SOLR-7275: - Thanks for your feedback Paul. I will open a separate issue for followup discussion. > 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 > Fix For: 5.2 > > Attachments: SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, > SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, > SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, > SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15617446#comment-15617446 ] Noble Paul commented on SOLR-7275: -- This issue did not eliminate any feature. The configuration you mentioned was not a feature of solr and it was not even documented. You please verify if it actually works and open a separate discussion > 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 > Fix For: 5.2 > > Attachments: SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, > SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, > SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, > SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15617430#comment-15617430 ] Thomas Quinot commented on SOLR-7275: - Back in the time of Solr 4, it was possible to control access using the Java security service, loading LoginService modules provided by Jetty. For example Infosys /myapp/auth/webauth.properties allowed user authentication against a list of UNIX crypt(3) hashes. Is this officially gone? If so this seems to be a significant regression. If this is still supported, could the org.ecliporg.eclipse.jetty.plus.jaas.JAASLoginService class be added to the Jetty instance packaged with Solr? JAAS provides a lot of flexibility without requiring Solr to reinvent the wheel (for example allowing authentication against an LDAP server). > 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 > Fix For: 5.2 > > Attachments: SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, > SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, > SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, > SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14545766#comment-14545766 ] ASF subversion and git services commented on SOLR-7275: --- Commit 1679604 from [~anshumg] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1679604 ] SOLR-7275: Setting requestType for context object in case of a /get request(merge from trunk) > 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 > Fix For: 5.2 > > Attachments: SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, > SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, > SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, > SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14544993#comment-14544993 ] ASF subversion and git services commented on SOLR-7275: --- Commit 1679497 from [~anshumg] in branch 'dev/trunk' [ https://svn.apache.org/r1679497 ] SOLR-7275: Setting requestType for context object in case of a /get request > 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 > Fix For: 5.2 > > Attachments: SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, > SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, > SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, > SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14543290#comment-14543290 ] Anshum Gupta commented on SOLR-7275: Damn! Thanks for fixing this. Just discovered I ran the test using Java8. > 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-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, > SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, > SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14543279#comment-14543279 ] ASF subversion and git services commented on SOLR-7275: --- Commit 1679319 from [~noble.paul] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1679319 ] SOLR-7275: compile error > 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-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, > SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, > SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14543269#comment-14543269 ] ASF subversion and git services commented on SOLR-7275: --- Commit 1679317 from [~anshumg] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1679317 ] SOLR-7275: Authorization framework for Solr. It defines an interface and a mechanism to create, load and use an Authorization plugin.(merge from trunk) > 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-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, > SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, > SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14543266#comment-14543266 ] ASF subversion and git services commented on SOLR-7275: --- Commit 1679316 from [~anshumg] in branch 'dev/trunk' [ https://svn.apache.org/r1679316 ] SOLR-7275: Authorization framework for Solr. It defines an interface and a mechanism to create, load and use an Authorization plugin. > 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-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, > SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, > SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14543224#comment-14543224 ] Anshum Gupta commented on SOLR-7275: Thanks for the feedback Noble. Right, as of now, a node restart would be required for security.json to be re-read. I'll create another issue for that and as I understand, you don't have an objection to committing this, right? :-) > 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-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, > SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, > SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14542521#comment-14542521 ] Noble Paul commented on SOLR-7275: -- We need to tackle the modification of security.json pretty soon. But that can be dealt separately The security.json needs to be watched and the plugin needs to be notified of the change. That should not prevent us from committing this > 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-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, > SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, > SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch, 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14527592#comment-14527592 ] Anshum Gupta commented on SOLR-7275: Right now, this also lacks a mechanism to Reload / Reinit without restarting the node. Perhaps it'd be a good idea to have an API to do that. > 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-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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14525503#comment-14525503 ] Don Bosco Durai commented on SOLR-7275: --- [~anshumg] thanks. When you are doing the change, can you give set method to the member attribute or make it public? With the current code, I need to extend the class to return the value. public class SolrAuthorizationResponse { boolean authorized; public boolean isAuthorized() { return authorized; } } > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14525504#comment-14525504 ] Don Bosco Durai commented on SOLR-7275: --- [~anshumg] thanks. When you are doing the change, can you give set method to the member attribute or make it public? With the current code, I need to extend the class to return the value. public class SolrAuthorizationResponse { boolean authorized; public boolean isAuthorized() { return authorized; } } > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14523859#comment-14523859 ] Anshum Gupta commented on SOLR-7275: Thanks for that input Don and Ishan, I read up a bit more and it certainly now makes more sense to use 403 for authorization and 401 for authentication. I'm changing things a bit to have the SolrAuthrorizationReponse contain an int HttpStatus code and Solr would just return that back if it's not an SC_OK or SC_ACCEPTED. That would allow the authorization plugin to act independently and decide what to return. I'll just put up the patch with that update in a bit. > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14523851#comment-14523851 ] Don Bosco Durai commented on SOLR-7275: --- Yes, for authorization, we should return 403 (post authentication). 401 is more appropriate for authentication flow > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14519667#comment-14519667 ] Ishan Chattopadhyaya commented on SOLR-7275: >From the same source, I can see this for 401: bq. The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. So, that means a 401 response must also contain a WWW-Authenticate header with a challenge, which seems inappropriate in this situation. Hence, I still feel 403 is more appropriate. > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14519516#comment-14519516 ] Ishan Chattopadhyaya commented on SOLR-7275: {quote} {noformat} + if (!authResponse.isAuthorized()) { +sendError((HttpServletResponse) response, 401, "Unauthorized request"); {noformat} {quote} Usually, a 401 means that the request needs to be repeated with appropriate authentication/authorization headers. 403 means that the authentication/authorization headers that are needed were provided, but still the server refused to fulfill the request. I think 403 (Forbidden) is more appropriate here. > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14518737#comment-14518737 ] Anshum Gupta commented on SOLR-7275: Moving the refactoring code to it's own issue and linking it from here. > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14498202#comment-14498202 ] Anshum Gupta commented on SOLR-7275: I was trying to use the MapInitializedPlugin but that involves changing _MapPluginLoader.init(..)_ which forces me to change _DOMUtil.toMapExcept_. which is used at a lot of places. I'll create a new GenericMapInitializedPlugin and use that instead. Thanks for bringing this up. > 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 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
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14497791#comment-14497791 ] Noble Paul commented on SOLR-7275: -- Use the {{MapInitializedPlugin}} instead of {{PluginInfoInitialized}} . PluginInfo is created with xml in mind. For a component that is exclusively loaded from JSON , it does not make sense to use {{PluginInfo}} > 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 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
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14497711#comment-14497711 ] Ishan Chattopadhyaya commented on SOLR-7275: Quick thought: {quote} {noformat} + //Initialize the Authorization module + if(cores.getZkController().getZkClient().exists(SOLR_SECURITY_CONF_PATH, true)) { +byte[] data = cores.getZkController().getZkClient() +.getData(SOLR_SECURITY_CONF_PATH, null, new Stat(), true); +Map securityConf = (Map) ZkStateReader.fromJSON(data) ; +Map authorizationConf = (Map) securityConf.get("authorization"); +log.info("Initializing authorization plugin: " + authorizationConf.get("class")); +authorizationPlugin = cores.getResourceLoader().newInstance((String) authorizationConf.get("class"), +SolrAuthorizationPlugin.class); {noformat} {quote} Maybe we should move this to the ZkStateReader, so that we can do something like this here: {noformat} zkcontroller.getSecurityProps().getAuthorization() or zkcontroller.getSecurityProps().getAuthentication() {noformat} > 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 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
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14495981#comment-14495981 ] Noble Paul commented on SOLR-7275: -- bq. Allowing the plugin to make that choice might be a better way to move. Notifying the plugin of conf changes is not same as reloading the plugin. When a data change callback is received , the plugin can decide what to do with the the callbck. How the API is designed is upto you. Solr components watching ZK nodes is a big red flag. We should not do it > 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
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14494837#comment-14494837 ] Anshum Gupta commented on SOLR-7275: I'm just trying to keep custom plugin config for security separate from other configuration. About merging authc and authz configs, that was on my mind and I plan to do it when I'm integrating the changes here with SOLR-7274. Let's consider an example of a user wanting to use some proprietary non-json format data in a custom security plugin, to store access rules. There wouldn't be a way to do that. I am all for exploring more options if there are any as long as they don't stop users from doing their own thing. I can have a straight mechanism to just read the {authorization} part of {/security.json} and pass that map to the plugin during init instead of the plugin reading from a file directly, but then instead of the security plugin deciding if it wants to keep a watch on the file, Solr would always keep a watch (when authz is enabled). In cases where access rules don't reside in zk and are in a 3rd party system, we don't want to keep a watch. Allowing toe plugin to make that choice might be a better way to move. I'm about to separate out the implementation of default/OTB plugin from this JIRA and I guess things would be clearer for everyone to understand after that happens. > 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
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14494484#comment-14494484 ] Ishan Chattopadhyaya commented on SOLR-7275: +1 to a single /security.json file. I propose the following, to fold in both SOLR-7274 and SOLR-7275 (this issue) zk configs. This would need support for nested objects in ZkStateReader. The "configs" could be passed in into the plugins' init() and hence it will no longer be necessary to pass in a ZkClient/ZkController into the plugin's init(). {quote} { "authentication": { "pluginClass": "org.blahblah", "pluginName": "kerberos", "configs": { "prop1": "val1", "prop2": "val2" } }, "authorization": { "pluginClass": "...", "pluginName": "ranger", "configs": { "prop1": "val1", "prop2": "val2" } } } {quote} > 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
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14494429#comment-14494429 ] Noble Paul commented on SOLR-7275: -- bq. 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. I fail to see why it is not possible, If Solr already supports configuration of almost a dozen plugins with standardized formats , what is so special about an authorization plugin? This is akin to having {{solrconfig_myplugin.xml}} for every custom plugin I write bq.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. There should be no need for the client to read stuff from ZK. Take the analogy of our current set of plugins. Do they ever try to read solrconfig.xml/ or configoverlay.json? > 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
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ 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
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14494298#comment-14494298 ] Anshum Gupta commented on SOLR-7275: That was my thought at this point. I'd want to propagate ACL/principal information when we get to say, Document level security but as I'm not handling that right now, let's just move ahead and build that in when we get to it. > 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
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ 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
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14493947#comment-14493947 ] Shalin Shekhar Mangar commented on SOLR-7275: - Thanks Anshum. I have a comment and a few questions: # Since this issue is about creating a pluggable authorization module, please create a different linked issue for a default/basic implementation. We should not be discussing/reviewing any specific implementation here. # We need to define the contract between this new plugin type and Solr better. For example: ## When is it created? ## When is it shutdown? ## How is it configured? How is the configuration changed? ## Is it per-collection or for the whole cluster? ## Can we have multiple such plugins? ## How are configuration changes propagated to different nodes? Is the plugin re-initialized or re-created? > 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
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14493877#comment-14493877 ] Noble Paul commented on SOLR-7275: -- It depends. If you are going to authenticate to the other nodes as the node itself then the original principal does not even matter. If you replacing to authenticate as the original user then all of it should be sent across > 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
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14493856#comment-14493856 ] Ishan Chattopadhyaya commented on SOLR-7275: bq. but yes, the intention is to use this object to return ACLs etc. from the authorization layer. [~noble.paul] Even basides avoiding the re-authorization, don't you think ACLs/user principal etc. should to be propagated to other nodes during an internode request? > 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
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14493848#comment-14493848 ] Noble Paul commented on SOLR-7275: -- Authorization is usually a low cost operation. I would say, lets us not optimize for it now. > 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
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14493754#comment-14493754 ] Ishan Chattopadhyaya commented on SOLR-7275: bq. The authorization plugin doesn't really do anything about inter-shard communication (and doesn't propagate the user principal), If a pre-authorized request is forwarded to another node, it shouldn't need to go via the authorization process again (e.g. a SolrDispatchFilter forwarded request, aka SDF.remoteQuery()). Towards that, don't you think the authorization plugin framework should have a way to let internode requests propagate some authorization info from the original user request? > 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
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14493673#comment-14493673 ] Noble Paul commented on SOLR-7275: -- A few comments * Do the initialization and other things of Authorization plugin in CoreContainer * This just does not feel right. CoreContainer SHOULD NOT be stored in PluginInfo. PluginInfo is supposed to be an immutable data structure that contains just data {noformat} coreContainer = (CoreContainer) info.initArgs.get("cc"); {noformat} why multiple son files? {{/security.json}} and {{ "/simplesecurity.json"}} ? Let us standardize one on one json file. Why should a component use SolrZkClient directly to read configuration? > 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
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14491297#comment-14491297 ] Anshum Gupta commented on SOLR-7275: [~dpgove] that's the intention behind returning a Response object instead of a plain boolean. As I'm not adding any of that in this phase, I didn't add those variables but yes, the intention is to use this object to return ACLs etc. from the authorization layer. > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14491008#comment-14491008 ] Jan Høydahl commented on SOLR-7275: --- bq. 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" It does not feel clean to mix document level security filtering with authorization. The authz filter should either grant or deny a certain user access to perform a certain operation on a certain resource. There are existing means of filtering docs based on user, which will live perfectly fine in parallel with any new authz solution. Let's keep things simple. > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14490745#comment-14490745 ] Noble Paul commented on SOLR-7275: -- Yes. That is totally possible > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14389408#comment-14389408 ] Anshum Gupta commented on SOLR-7275: Jan, I am working on what I've described above as I think it's a straight framework that would allow for easy pluggability of multiple authorization implementations and would keep the implementation details for the security layer (Sentry/Ranger/...) outside of Solr for the most part. > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr
[ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14375627#comment-14375627 ] Jan Høydahl commented on SOLR-7275: --- Linking up SOLR-7236, which is an attempt to gather planning of security interfaces for Solr in an umbrella issue. This topic deserves broad high-level discussions before starting a custom implementation. > 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 AuthResponse isAuthorized(); > } > {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