[
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)
