zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rakesh R (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ZOOKEEPER-1045) Support Quorum Peer mutual authentication via SASL
Date Wed, 02 Nov 2016 04:40:58 GMT

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

Mime
View raw message