[jira] [Comment Edited] (SOLR-7755) An API to edit the Basic Auth security params

["Ishan Chattopadhyaya (JIRA)" <ji...@apache.org>]

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

Ishan Chattopadhyaya edited comment on SOLR-7755 at 7/6/15 4:01 PM:
--------------------------------------------------------------------

bq. I don't think exposing ZK to users is a good/safe practice
Sure not, but this kind of an interface should only be exposed to an admin, not a regular "user".

bq. That is pretty simple , You start with a standard no-edit permission security.json. it will be a part of this ticket . Which gives the admin user the privilege to edit the security parameters
In that case, do you propose that the system assumed a default/preconfigured admin user principal?


bq. {noformat}
>>    Also, authc/authz plugins in an already started up Solr cluster can add watches to the /security.json in 
>> ZK to monitor changes made through such a command line tool
> NO. We want the the authc/authz plugins to just deal with security instead of screwing up/editing ZK nodes
{noformat}
I meant that a plugin can just add a watch to observe changed values and not actually changing anything in ZK. IoW, no plugin should be able to change ZK, but if the admin changes something from the commandline tool, these plugins can pick things up from the changes in security.json. 

bq. Isn't the same way it is done in all data stores? They give admin privileges to to the admin and he can do further edits
But in that case, most datastores (MySQL, Oracle comes to mind) have their own built-in user management. In case of Solr, most likely the user principals would already be configured using LDAP or kerberos or some external system (in the special case of a particular plugin, they can be in ZK too). Each plugin would support different operations. Instead of trying to cater to them all in a unified endpoint/framework, isn't it cleaner to ask the admin to edit /security.json (directly or using any commandline tool)? That way, the plugins wouldn't need to hook itself into this API endpoint trying to parse out things thrown at it, and instead just know how to the config section passed into it through the /security.json. Wdyt?


was (Author: ichattopadhyaya):
bq. I don't think exposing ZK to users is a good/safe practice
Sure not, but this kind of an interface should only be exposed to an admin, not a regular "user".

bq. That is pretty simple , You start with a standard no-edit permission security.json. it will be a part of this ticket . Which gives the admin user the privilege to edit the security parameters
In that case, do you propose that the system assumed a default/preconfigured admin user principal?

{noformat}
>>    Also, authc/authz plugins in an already started up Solr cluster can add watches to the /security.json in 
>> ZK to monitor changes made through such a command line tool
> NO. We want the the authc/authz plugins to just deal with security instead of screwing up/editing ZK nodes
{noformat}
I meant that a plugin can just add a watch to observe changed values and not actually changing anything in ZK. IoW, no plugin should be able to change ZK, but if the admin changes something from the commandline tool, these plugins can pick things up from the changes in security.json. 

bq. Isn't the same way it is done in all data stores? They give admin privileges to to the admin and he can do further edits
But in that case, most datastores (MySQL, Oracle comes to mind) have their own built-in user management. In case of Solr, most likely the user principals would already be configured using LDAP or kerberos or some external system (in the special case of a particular plugin, they can be in ZK too). Each plugin would support different operations. Instead of trying to cater to them all in a unified endpoint/framework, isn't it cleaner to ask the admin to edit /security.json (directly or using any commandline tool)? That way, the plugins wouldn't need to hook itself into this API endpoint trying to parse out things thrown at it, and instead just know how to the config section passed into it through the /security.json. Wdyt?

> An API to edit the Basic Auth security params
> ---------------------------------------------
>
>                 Key: SOLR-7755
>                 URL: https://issues.apache.org/jira/browse/SOLR-7755
>             Project: Solr
>          Issue Type: Sub-task
>          Components: security
>            Reporter: Noble Paul
>            Assignee: Noble Paul
>
> example
> {code}
> curl http://localhost:8983/solr/admin/authorization -H 'Content-type:application/json' -d '{
> "add-user" : {"name" : "tom", 
>              "role": ["admin","dev"]
>              },
> "create-permission" :{"name":"mycoll-update",
>                       "before" :"some-other-permission",
>                       "path":"/update/*"
>                       "role":["dev","admin"]
>                       }
> }'
> {code}
> Please note that the set of parameters required for a basic ZK based impl will be completely different from that of a Kerberos implementation. However the framework would remain the same. The end point will remain the same, though



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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org