I can accomplish my goal using a jaas config file, which is fine for test
code, but I would prefer to avoid writing credentials to disk in real code.
Map<String, Object> customInstanceSpecProps = new HashMap<>();
customInstanceSpecProps.put("authProvider.1",
"org.apache.zookeeper.server.auth.SASLAuthenticationProvider");
customInstanceSpecProps.put("requireClientAuthScheme", "sasl");
File saslConfFile = new File(dataParent, "jaas.conf");
FileWriter fwriter = new FileWriter(saslConfFile);
fwriter.write( "Server {\n" +
"
org.apache.zookeeper.server.auth.DigestLoginModule required\n" +
" user_super=\"test\";\n" +
"};\n" +
"Client {\n" +
"
org.apache.zookeeper.server.auth.DigestLoginModule required\n" +
" username=\"super\"\n" +
" password=\"test\";\n" +
"};\n");
fwriter.close();
System.setProperty("java.security.auth.login.config",
saslConfFile.getAbsolutePath());
// Create the test cluster
List<InstanceSpec> instanceSpecs = new ArrayList<>();
for (int i = 0 ; i < 3 ; i++) {
instanceSpecs.add(new InstanceSpec(null, -1, -1, -1, false, i,
-1, -1, customInstanceSpecProps));
}
TestingCluster zkCluster = new TestingCluster(instanceSpecs);
zkCluster.start();
client = CuratorFrameworkFactory.builder()
.connectString(zkCluster.getConnectString())
.retryPolicy(new
ExponentialBackoffRetry(100, 3))
.build();
List<ACL> acls = new ArrayList<>();
acls.add(new ACL(ZooDefs.Perms.ALL, new Id("sasl", "super")));
client.create().creatingParentsIfNeeded().withACL(acls).forPath("/test/mynode");
This all works well, and the nodes are accessible to my clients.
I've tried removing the Client section from the jaas.conf file, using the
client build authorization instead:
client = CuratorFrameworkFactory.builder()
.connectString(zkCluster.getConnectString())
.retryPolicy(new
ExponentialBackoffRetry(100, 3))
.authorization("digest",
"super:test".getBytes())
.build();
If I specify "sasl" scheme here, then authentication fails when creating
the node.
If I specify "digest", then the creation is permitted, but a subsequent
client with the same auth config fails with "NoAuth".
So, I'm a lot closer than I was yesterday, but I'm still missing something.
Any help is appreciated.
Thanks,
Phil
On Tue, Oct 10, 2017 at 9:46 PM, Philip Zampino <[email protected]> wrote:
> I've searched the Curator codebase, and didn't find any examples. I guess
> I'll educate myself about securing ZK in-general, and try to figure it out.
>
> On Tue, Oct 10, 2017 at 7:17 PM, Cameron McKenzie <[email protected]>
> wrote:
>
>> I haven't tried it, and I don't think it's done anywhere specifically in
>> the Curator codebase, but given that the TestingCluster and associated
>> classes are just wrappers around the underlying Zookeeper server, I can't
>> see why it couldn't be done.
>>
>> On Wed, Oct 11, 2017 at 8:02 AM, Philip Zampino <[email protected]>
>> wrote:
>>
>>> I'm wondering if it's possible to configure any kind of security (i.e.,
>>> authentication) to a (curator-test) TestingCluster.
>>>
>>> If so, is it documented anywhere?
>>>
>>> Thanks,
>>> Phil
>>>
>>
>>
>
