[jira] [Comment Edited] (SOLR-7275) Pluggable authorization module in Solr
[
https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14542399#comment-14542399
]
Anshum Gupta edited comment on SOLR-7275 at 5/13/15 6:40 PM:
-
Patch with test. I think this is good to go now.
Any feedback would be appreciated.
was (Author: anshumg):
Patch with test. I think this is good to go 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-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] [Comment Edited] (SOLR-7275) Pluggable authorization module in Solr
[
https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14537644#comment-14537644
]
Anshum Gupta edited comment on SOLR-7275 at 5/11/15 7:12 AM:
-
The request context now provides Collection name in
# Regular /select etc. requests
# Collection API requests
# Core specific requests.
# Collection Alias requests
Working on adding a test. Will add it tonight or tomorrow and should be done
with this.
was (Author: anshumg):
The request context now provides Collection name in
# Regular /select etc. requests
# Collection API requests
# Core specific requests.
Working on adding a test. Will add it tonight or tomorrow and should be done
with 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 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] [Comment Edited] (SOLR-7275) Pluggable authorization module in Solr
[
https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14527530#comment-14527530
]
Anshum Gupta edited comment on SOLR-7275 at 5/4/15 11:13 PM:
-
Patch updated to trunk. Working on integrating the context object.
was (Author: anshumg):
Patch updated to trunk working on integrating the context.
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] [Comment Edited] (SOLR-7275) Pluggable authorization module in Solr
[
https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14497711#comment-14497711
]
Ishan Chattopadhyaya edited comment on SOLR-7275 at 4/16/15 8:18 AM:
-
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().getAuthorizationProps() or
zkcontroller.getSecurityProps().getAuthenticationProps()
{noformat}
was (Author: ichattopadhyaya):
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] [Comment Edited] (SOLR-7275) Pluggable authorization module in Solr
[
https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14497128#comment-14497128
]
Anshum Gupta edited comment on SOLR-7275 at 4/15/15 10:24 PM:
--
Patch for just the framework. It includes the following changes:
* All security config now goes into /security.json. Here's a sample:
{code}
{authorization:
{class:solr.SimpleSolrAuthorizationPlugin,
deny:[user1,user2]
}
}
{code}
Everything from the {{authorization}} section would be passed on to the
authorization plugin.
* After a discussion with Noble, it made more sense to restrict the access at
this point to what's required and if we feel the need to expose zkStateReader,
zkClient or the coreContainer itself to the plugin, we could do that at a later
time. For now, all configuration for the plugin should just go into the
authorization section.
* SimpleSolrAuthorizationPlugin is no longer in the direct scope of this issue,
but I created a new issue for that. I'll put up the updated patch, that doesn't
use the coreContainer or access zk directly right after posting this patch.
* I tried to have the SolrAuthorizationPlugin extend MapInitializedPlugin but
that was more invasive than required as it takes a MapString, String whereas
we need a MapString, Object here. I'll see if there's a way to do that
without being invasive or duplicating a lot of the code so it still just
extends PluginInfoInitialized.
Here are the steps to test this patch (you would need the patch from SOLR-7402
along with this patch to actually see this work, as this is just the framework):
1. Start zk.
2. Using zk CLI,
{noformat}set /security.json
{authorization:{class:solr.SimpleSolrAuthorizationPlugin,deny:[user1,user2]}}{noformat}
Change the userlist to whatever you want to use to test.
3. Start SolrCloud, make sure you use the zk server/ensemble you just setup.
e.g. {noformat}bin/solr start -z localhost:2181 -c{noformat}
To write your own plugin:
# Extend SolrAuthorizationPlugin, this requires implementing
## init(PluginInfo info) : This is called when the node comes up. It is called
once and creates the plugin object. This is where you can define your
connections to 3rd party security systems etc.
## authorize(SolrRequestContext context) and optionally overriding
# Follow the steps above (testing this patch) and specify the FQN of the
implementation class in the authorization{{class}}. e.g.
{code}
{authorization:{class:solr.MyCustomSolrAuthorizationPlugin,connect_string:hostname:port/somepath}}
{code}
Still todo:
* Work on the context object.
* Cleanup/shutdown hook.
* Reloading/watching for changes in the /security.json file or documenting how
to change it.
* Tests
was (Author: anshumg):
Patch for just the framework. It includes the following changes:
* All security config now goes into /security.json. Here's a sample:
{code}
{authorization:
{class:solr.SimpleSolrAuthorizationPlugin,
deny:[user1,user2]
}
}
{code}
Everything from the {{authorization}} section would be passed on to the
authorization plugin.
* After a discussion with Noble, it made more sense to restrict the access at
this point to what's required and if we feel the need to expose zkStateReader,
zkClient or the coreContainer itself to the plugin, we could do that at a later
time. For now, all configuration for the plugin should just go into the
authorization section.
* SimpleSolrAuthorizationPlugin is no longer in the direct scope of this issue,
but I created a new issue for that. I'll put up the updated patch, that doesn't
use the coreContainer or access zk directly right after posting this patch.
* I tried to have the SolrAuthorizationPlugin extend MapInitializedPlugin but
that was more invasive than required as it takes a MapString, String whereas
we need a MapString, Object here. I'll see if there's a way to do that
without being invasive or duplicating a lot of the code so it still just
extends PluginInfoInitialized.
Here are the steps to test this patch:
1. Start zk.
2. Using zk CLI,
{noformat}set /security.json
{authorization:{class:solr.SimpleSolrAuthorizationPlugin,deny:[user1,user2]}}{noformat}
Change the userlist to whatever you want to use to test.
3. Start SolrCloud, make sure you use the zk server/ensemble you just setup.
e.g. {noformat}bin/solr start -z localhost:2181 -c{noformat}
To write your own plugin:
# Extend SolrAuthorizationPlugin, this requires implementing
## init(PluginInfo info) : This is called when the node comes up. It is called
once and creates the plugin object. This is where you can define your
connections to 3rd party security systems etc.
## authorize(SolrRequestContext context) and optionally overriding
# Follow the steps above (testing this patch) and specify the FQN of the
implementation class in the authorization{{class}}. e.g.
{code}
[jira] [Comment Edited] (SOLR-7275) Pluggable authorization module in Solr
[
https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14493673#comment-14493673
]
Noble Paul edited comment on SOLR-7275 at 4/14/15 6:42 AM:
---
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?
was (Author: noble.paul):
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] [Comment Edited] (SOLR-7275) Pluggable authorization module in Solr
[
https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14493673#comment-14493673
]
Noble Paul edited comment on SOLR-7275 at 4/14/15 9:41 AM:
---
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 json files? {{/security.json}} and {{/simplesecurity.json}} ?
Let us standardize one on one json file. Why should a component use
SolrZkClient directly to read configuration?
was (Author: noble.paul):
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] [Comment Edited] (SOLR-7275) Pluggable authorization module in Solr
[
https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14494296#comment-14494296
]
Anshum Gupta edited comment on SOLR-7275 at 4/14/15 3:50 PM:
-
Thanks for looking at it Noble.
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.
was (Author: anshumg):
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] [Comment Edited] (SOLR-7275) Pluggable authorization module in Solr
[
https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14494484#comment-14494484
]
Ishan Chattopadhyaya edited comment on SOLR-7275 at 4/14/15 5:56 PM:
-
+1 to a single /security.json file.
I propose the following format for /security.json, 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().
{noformat}
{
authentication: {
pluginClass: org.blahblah,
pluginName: kerberos,
configs: {
prop1: val1,
prop2: val2
}
},
authorization: {
pluginClass: ...,
pluginName: ranger,
configs: {
prop1: val1,
prop2: val2
}
}
}
{noformat}
was (Author: ichattopadhyaya):
+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().
{noformat}
{
authentication: {
pluginClass: org.blahblah,
pluginName: kerberos,
configs: {
prop1: val1,
prop2: val2
}
},
authorization: {
pluginClass: ...,
pluginName: ranger,
configs: {
prop1: val1,
prop2: val2
}
}
}
{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 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] [Comment Edited] (SOLR-7275) Pluggable authorization module in Solr
[
https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14494484#comment-14494484
]
Ishan Chattopadhyaya edited comment on SOLR-7275 at 4/14/15 5:55 PM:
-
+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().
{noformat}
{
authentication: {
pluginClass: org.blahblah,
pluginName: kerberos,
configs: {
prop1: val1,
prop2: val2
}
},
authorization: {
pluginClass: ...,
pluginName: ranger,
configs: {
prop1: val1,
prop2: val2
}
}
}
{noformat}
was (Author: ichattopadhyaya):
+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] [Comment Edited] (SOLR-7275) Pluggable authorization module in Solr
[
https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14494837#comment-14494837
]
Anshum Gupta edited comment on SOLR-7275 at 4/14/15 8:44 PM:
-
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 the
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.
was (Author: anshumg):
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:
[jira] [Comment Edited] (SOLR-7275) Pluggable authorization module in Solr
[
https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14491297#comment-14491297
]
Anshum Gupta edited comment on SOLR-7275 at 4/12/15 1:58 AM:
-
[~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.
I have the first patch ready, but I'm just in the process of cleaning it up a
bit. I'll try and post it over the weekend.
was (Author: anshumg):
[~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
