[ https://issues.apache.org/jira/browse/ZOOKEEPER-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15627693#comment-15627693 ]
Rakesh R commented on ZOOKEEPER-1045: ------------------------------------- Thanks a lot [~ekoontz] for the reviews. I will incorporate your code improvement suggestions in the next patch. Thanks a lot [~hanm], [~apurtell] for the comments. I agree to both of you. The shared principal format {{<principal>@<realm>}} won't work well with the current patch. Its my mistake and I will modify the shared principal section saying that the supported format is "<principal>/hostname@<realm>". Presently ZooKeeper supports the server principal name in the format {{<principal>/<hostname>@<realm>}}, [zk branch-3.4 code reference|https://github.com/apache/zookeeper/blob/branch-3.4/src/java/main/org/apache/zookeeper/server/ZooKeeperSaslServer.java#L55] and [GSSName.html#NT_HOSTBASED_SERVICE|https://docs.oracle.com/javase/7/docs/api/org/ietf/jgss/GSSName.html#NT_HOSTBASED_SERVICE]. From your comments IIUC, the current patch works well if admin configures Kerberos principal in the format "<principal>/hostname@<realm>". For the shared principal, it needs to configure like => <principal>/127.0.0.1@<realm> or <principal>/localhost@<realm>. Also, the current patch will support authorization if admin configured Kerberos principal name in the format <principal>/FQDN@<realm>. bq. shared Kerberos credential is an extreme, as shared Kerberos credential effectively would disable authorization [~hanm], Presently am doing the authorization of the connecting hosts at the QuorumServer side. It does by comparing the FQDN(host details) from the QuorumLearner's principal and the zoo.cfg server details of QuorumServer. This is done after the authentication and in the SaslQuorumServerCallbackHandler. If we need to support authz irrespective of the Kerberos principal configured, I have another idea for the authz logic. Say, A and B is forming quorum. Since the connecting peer sends 'QuorumAuthPacket' to the peer server (A -> B), now I'm planning to keep A's FQDN in his 'QuorumAuthPacket' and B can read this and cross check against zoo.cfg. This will be done outside the CallbackHandler and before the authentication. Also, this new authz logic wouldn't have any dependency with the Kerberos and this is a separate logic common for Digest/Kerberos. In general, I would say this new authz is a kind of {{"hostname white listing"}} using the {{zoo.cfg}} server details. Auth Packet format:- {code} class QuorumAuthPacket { long magic; int status; buffer token; ustring hostname; } {code} Principal name:- <principal>/hostname@<realm> Server details:- {code} server.1=FQDN1:port:port server.2=FQDN2:port:port server.3=FQDN3:port:port {code} If everyone agrees to this, I will quickly start prototyping this and upload a patch. Welcome comments. Thanks! > 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: quorum, security > 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, QuorumPeer Mutual > Authentication Via Sasl Feature Doc - 2016-Sep-25.pdf, > TEST-org.apache.zookeeper.server.quorum.auth.QuorumAuthUpgradeTest.txt, > ZK-1045-test-case-failure-logs.zip, ZOOKEEPER-1045 Test Plan.pdf, > 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-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, > org.apache.zookeeper.server.quorum.auth.QuorumAuthUpgradeTest.testRollingUpgrade.log > > > 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. > Review board: https://reviews.apache.org/r/47354/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)