[ 
https://issues.apache.org/jira/browse/SOLR-7692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14644404#comment-14644404
 ] 

Ishan Chattopadhyaya commented on SOLR-7692:
--------------------------------------------

1. In Sha256AuthenticationProvider, line 106
{noformat}
NoSuchAlgorithmException e) {
      BasicAuthPlugin.log.error(e.getMessage(), e);
      return null;//should not happen
    }
{noformat}
Shouldn't this be an exception thrown?

2. In the sha256() method, I think we should reuse a digest instance, since 
there are significant overheads to creating a new digest algorithm instance.
Reference: https://books.google.co.in/books?id=42etT_9-_9MC&pg=PT254&lpg=PT254

3. For SolrJ support, I've added SOLR-7839.

4. For internode communication, I think (please correct me if I'm wrong) the 
ThreadLocal approach won't work for cases when the internode request is made 
from a threadpool, from where the headers of the original request thread's 
ThreadLocal won't be accessible. I think we need something like SOLR-6625, 
where the request object can store the user principal / headers etc. and pass 
it along to the request interceptor as a context.

5. As per our discussion offline, the internode request which are originated 
from a Solr node (not a subrequest of a main user request) cannot be secured 
this way. Either each node uses its own principal/credentials to send internode 
requests in such cases, or there's another secure mechanism of internode 
requests internal to Solr (e.g. asymmetric cryptographic mechanism, e.g. PKI), 
irrespective of the authc plugins used for user requests.

> Implement BasicAuth based impl for the new Authentication/Authorization APIs
> ----------------------------------------------------------------------------
>
>                 Key: SOLR-7692
>                 URL: https://issues.apache.org/jira/browse/SOLR-7692
>             Project: Solr
>          Issue Type: New Feature
>            Reporter: Noble Paul
>            Assignee: Noble Paul
>         Attachments: SOLR-7692.patch, SOLR-7692.patch, SOLR-7692.patch, 
> SOLR-7692.patch, SOLR-7692.patch, SOLR-7692.patch, SOLR-7692.patch, 
> SOLR-7692.patch, SOLR-7692.patch, SOLR-7692.patch, SOLR-7692.patch, 
> SOLR-7692.patch, SOLR-7692.patch, SOLR-7692.patch, SOLR-7692.patch, 
> SOLR-7757.patch, SOLR-7757.patch, SOLR-7757.patch
>
>
> This involves various components
> h2. Authentication
> A basic auth based authentication filter. This should retrieve the user 
> credentials from ZK.  The user name and sha1 hash of password should be 
> stored in ZK
> sample authentication json 
> {code:javascript}
> {
>   "authentication":{
>     "class": "solr.BasicAuthPlugin",
>     "users" :{
>       "john" :"09fljnklnoiuy98 buygujkjnlk",
>       "david":"f678njfgfjnklno iuy9865ty",
>       "pete": "87ykjnklndfhjh8 98uyiy98",
>        }
>   }
> }
> {code}
> h2. authorization plugin
> This would store the roles of various users and their privileges in ZK
> sample authorization.json
> {code:javascript}
> {
>   "authorization": {
>     "class": "solr.ZKAuthorization",
>    "roles" :{
>   "admin" : ["john"]
>   "guest" : ["john", "david","pete"]
>    }
>     "permissions": {
>        "collection-edit": {
>          "role": "admin" 
>        },
>        "coreadmin":{
>          "role":"admin"
>        },
>        "config-edit": {
>          //all collections
>          "role": "admin",
>          "method":"POST"
>        },
>        "schema-edit": {
>          "roles": "admin",
>          "method":"POST"
>        },
>        "update": {
>          //all collections
>          "role": "dev"
>        },
>       "mycoll_update": {
>         "collection": "mycoll",
>         "path":["/update/*"],
>         "role": ["somebody"]
>       }
>     }
>   }
> }
> {code} 
> We will also need to provide APIs to create users and assign them roles



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to