[
https://issues.apache.org/jira/browse/SOLR-7230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14358161#comment-14358161
]
Noble Paul edited comment on SOLR-7230 at 3/12/15 6:37 AM:
-----------------------------------------------------------
This will define a new pluggable component for Solr. It could be initialized
at the corecontainer level.
component would be initialized at the node startup and destroyed at
corecontainer shutdown
The scope of this ticket is how/where to configure that plugin (in cloud as
well as standalone mode) and the interface that the component must implement .
The component will be consulted at each external API call coming in to a Solr
node.
User management/ACLs are not in the scope of this API. That should be the
responsibility of the plugin . Solr will just consult the component and ask it
whether the request must go through or not. if no, what should be the
Exception/error message . The component would also be allowed to manipulate the
request and inject parameters so that it can control the data (fields or docs )
that is retrieved by the request
Let's keep this as simple as that and Shiro or kerberos or PKI or whatever can
be done by the component. This way we are not tying down the semantics of the
security to any one kind of solution.
was (Author: noble.paul):
This will define a new pluggable component for Solr. It could be initialized
at the corecontainer level.
component would be initialized at the node startup and destroyed at
corecontainer shutdown
The scope of this ticket is how/where to configure that plugin (in cloud as
well as standalone mode) and the interface that the component must implement .
The component will be consulted at each external API call coming in to a Solr
node.
User management/ACLs are not in the scope of this API. That should be the
responsibility of the plugin . Solr will just consult the component and ask it
whether the request must go through or not. if no, what should be the
Exception/error message . The component would also be allowed to manipulate the
request and inject parameters so that it can control the data (fields or docs )
that is retrieved from the request
Let's keep this as simple as that and Shiro or kerberos or PKI or whatever can
be done by the component. This way we are not tying down the semantics of the
security to any one kind of solution.
> An API to plugin security into Solr
> -----------------------------------
>
> Key: SOLR-7230
> URL: https://issues.apache.org/jira/browse/SOLR-7230
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
>
> The objective is to define a API that a plugin can implement to protect
> various operations performed on Solr. It may have various implementations .
> Some built in and some external.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
