[
https://issues.apache.org/jira/browse/ZOOKEEPER-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15473057#comment-15473057
]
Rakesh R edited comment on ZOOKEEPER-1045 at 9/8/16 7:22 AM:
-------------------------------------------------------------
bq. But authorization should probably happen before, maybe when a reconfig is
processed or maybe even before that - when a new server boots and tries to
connect to the leader. Does the leader check new server connections ? If that
server wasn't initially declared, would it be able to connect ?
Perhaps we should identify the exact place where it needs to do the
authorization. I can say, this jira is proposing authentication and
authorization at the beginning of FLE process. That means, when a learner tries
to connect to remote quorum server, first it will do the authn and authz, on
success it will proceed to FLE process, otw reject the connecting server.
Again, after FLE when a Follower/Observer tries to {{connectToLeader}} it does
authn and authz steps.
As per my above comment, when a new server tries to connect to leader, leader
will cross check with its quorum server principal list(built from zoo.cfg). So
here the leader should have the information about the newly connecting server.
Will the reconfig commit happens before this?
was (Author: rakeshr):
bq. But authorization should probably happen before, maybe when a reconfig is
processed or maybe even before that - when a new server boots and tries to
connect to the leader. Does the leader check new server connections ? If that
server wasn't initially declared, would it be able to connect ?
Perhaps we should identify the exact place where it needs to do the
authorization. I can say, this jira is proposing authentication and
authorization at the beginning of FLE process. That means, when a learner tries
to connect to remote quorum server, first it will do the authn and authz, on
success it will proceed to FLE process, otw reject the connecting server.
As per my above comment, when a new server tries to connect to leader, leader
will cross check with its quorum server principal list(built from zoo.cfg). So
here the leader should have the information about the newly connecting server.
Will the reconfig commit happens before this?
> Support Quorum Peer mutual authentication via SASL
> --------------------------------------------------
>
> Key: ZOOKEEPER-1045
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1045
> Project: ZooKeeper
> Issue Type: New Feature
> Components: server
> Reporter: Eugene Koontz
> Assignee: Rakesh R
> Priority: Critical
> Fix For: 3.4.10, 3.5.3
>
> Attachments: 0001-ZOOKEEPER-1045-br-3-4.patch,
> 1045_failing_phunt.tar.gz, HOST_RESOLVER-ZK-1045.patch,
> TEST-org.apache.zookeeper.server.quorum.auth.QuorumAuthUpgradeTest.txt,
> ZK-1045-test-case-failure-logs.zip, ZOOKEEPER-1045-00.patch,
> ZOOKEEPER-1045-Rolling Upgrade Design Proposal.pdf,
> ZOOKEEPER-1045-br-3-4.patch, ZOOKEEPER-1045-br-3-4.patch,
> ZOOKEEPER-1045-br-3-4.patch, ZOOKEEPER-1045-br-3-4.patch,
> ZOOKEEPER-1045-br-3-4.patch, ZOOKEEPER-1045-br-3-4.patch,
> ZOOKEEPER-1045TestValidationDesign.pdf
>
>
> ZOOKEEPER-938 addresses mutual authentication between clients and servers.
> This bug, on the other hand, is for authentication among quorum peers.
> Hopefully much of the work done on SASL integration with Zookeeper for
> ZOOKEEPER-938 can be used as a foundation for this enhancement.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
