[
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: [email protected]
For additional commands, e-mail: [email protected]
