Re: Zookeeper and curator SASL authentication
great! :)
On Wed, Jan 15, 2020 at 6:38 PM Arpit Jain wrote:
> I managed to create ACL with authenticated client principal using below
> lines of code in client:
>
> curator
> .create().creatingParentContainersIfNeeded().withACL(ZooDefs.Ids.
> CREATOR_ALL_ACL).forPath("/mynode");
>
>
> ZooDefs.Ids.CREATOR_ALL_ACL gives permissions to the client which is
> authenticated.
>
> To test this, I logged in using zkCli.sh on ZK server and ran getAcl
> /mynode and able to browse the znodes and can see that node has all (CDRWA)
> permission for authenticated uses. If I log in with a unauthenticated
> principal, I am not able to see the znodes tree even though I manage to
> connect to ZK server.
>
> On Wed, Jan 15, 2020 at 12:19 PM Enrico Olivelli - Diennea <
> enrico.olive...@diennea.com> wrote:
>
>> Yes, they are system properties
>>
>> You can take this guide (about Kafka) as example
>>
>> https://docs.confluent.io/current/kafka/authentication_sasl/authentication_sasl_gssapi.html
>>
>>
>>
>> Il giorno 15/01/20, 13:17 "Arpit Jain" ha
>> scritto:
>>
>> I have not passed those parameters. Is this something I need to set in
>> Zookeeper (zoo.cfg) ?
>>
>> On Wed, Jan 15, 2020 at 12:12 PM Enrico Olivelli - Diennea <
>> enrico.olive...@diennea.com> wrote:
>>
>> > Usually with SASL auth you are using:
>> > kerberos.removeHostFromPrincipal=true
>> > kerberos.removeRealmFromPrincipal=true
>> >
>> > is this the case for you ?
>> >
>> > Enrico
>> >
>> > Il giorno 15/01/20, 13:01 "Arpit Jain" ha
>> > scritto:
>> >
>> > I have asked in Curator mailing list as well but not much help.
>> I am
>> > able
>> > to set ACL with sasl scheme by using zkCli.sh client in
>> Zookeeper
>> > server.
>> > The idea is to use Curator to set the ACLs so that only my
>> client
>> > application can access its Znodes.
>> >
>> >
>> > On Wed, Jan 15, 2020 at 9:21 AM Szalay-Bekő Máté <
>> > szalay.beko.m...@gmail.com>
>> > wrote:
>> >
>> > > I am not sure what is wrong with the code... I am not
>> familiar with
>> > > Curator. I can try to google / reproduce this and see what is
>> wrong,
>> > but it
>> > > will take a while for me. So first I would ask the others,
>> maybe
>> > there is
>> > > someone who knows both ZooKeeper SASL and Curator and can
>> help you
>> > more in
>> > > this mailing list. If noone replies, then I will try to setup
>> a dummy
>> > > project with Curator to test this.
>> > >
>> > > Did you also ask around the Curator mailing list maybe? Would
>> it
>> > help if I
>> > > send you code about setting the ACLs using plain ZooKeeper
>> (and no
>> > Curator)?
>> > >
>> > > On Tue, Jan 14, 2020 at 2:48 PM Arpit Jain <
>> jain.arp...@gmail.com>
>> > wrote:
>> > >
>> > >> Thanks for the clarification.
>> > >> I am able to authenticate client with Zookeeper. However,
>> when I
>> > started
>> > >> to set ACLs with the same client, I get error messages. This
>> is how
>> > I am
>> > >> creating curator client for setting ACLs
>> > >>
>> > >> CuratorFrameworkFactory.Builder builder =
>> > >>
>> > >> CuratorFrameworkFactory.builder().connectString(
>> > >> coordinatorHosts).retryPolicy(retryPolicy)
>> > >>
>> > >> .connectionTimeoutMs(coordinatorConnectionTimeout
>> > >> ).sessionTimeoutMs(coordinatorSessionTimeout);
>> > >>
>> > >> final CuratorFramework curatorFramework =
>> > >>
>> > >> builder.authorization("sasl", "zkclient/
>> > z...@example.com"
>> > >> .getBytes()).aclProvider(new ACLProvider() {
>> > >>
>> > >> @Override
>> > >>
>> > >> public List getDefaultAcl() {
>> > >>
>> > >> return ZooDefs.Ids.CREATOR_ALL_ACL;
>> > >>
>> > >> }
>> > >>
>> > >>
>> > >> @Override
>> > >>
>> > >> public List getAclForPath(String path) {
>> > >>
>> > >> return ZooDefs.Ids.CREATOR_ALL_ACL;
>> > >>
>> > >> }
>> > >>
>> > >> }).build();
>> > >>
>> > >>
>> > >> I see below logs in Zookeeper node:
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >> *2020-01-14 13:27:53,174 [myid:1] - INFO
>> > >> [NIOWorkerThread-3:SaslServerCallbackHandler@120] -
>> Successfully
>> > >> authenticated client: authenticationID=zkclient/
>> z...@example.com
>> > >> ; authorizationID=zkclient/
>> z...@example.com
>> > >> .2020-01-14 13:27:53,175
Re: Zookeeper and curator SASL authentication
I managed to create ACL with authenticated client principal using below
lines of code in client:
curator
.create().creatingParentContainersIfNeeded().withACL(ZooDefs.Ids.
CREATOR_ALL_ACL).forPath("/mynode");
ZooDefs.Ids.CREATOR_ALL_ACL gives permissions to the client which is
authenticated.
To test this, I logged in using zkCli.sh on ZK server and ran getAcl
/mynode and able to browse the znodes and can see that node has all (CDRWA)
permission for authenticated uses. If I log in with a unauthenticated
principal, I am not able to see the znodes tree even though I manage to
connect to ZK server.
On Wed, Jan 15, 2020 at 12:19 PM Enrico Olivelli - Diennea <
enrico.olive...@diennea.com> wrote:
> Yes, they are system properties
>
> You can take this guide (about Kafka) as example
>
> https://docs.confluent.io/current/kafka/authentication_sasl/authentication_sasl_gssapi.html
>
>
>
> Il giorno 15/01/20, 13:17 "Arpit Jain" ha
> scritto:
>
> I have not passed those parameters. Is this something I need to set in
> Zookeeper (zoo.cfg) ?
>
> On Wed, Jan 15, 2020 at 12:12 PM Enrico Olivelli - Diennea <
> enrico.olive...@diennea.com> wrote:
>
> > Usually with SASL auth you are using:
> > kerberos.removeHostFromPrincipal=true
> > kerberos.removeRealmFromPrincipal=true
> >
> > is this the case for you ?
> >
> > Enrico
> >
> > Il giorno 15/01/20, 13:01 "Arpit Jain" ha
> > scritto:
> >
> > I have asked in Curator mailing list as well but not much help.
> I am
> > able
> > to set ACL with sasl scheme by using zkCli.sh client in Zookeeper
> > server.
> > The idea is to use Curator to set the ACLs so that only my client
> > application can access its Znodes.
> >
> >
> > On Wed, Jan 15, 2020 at 9:21 AM Szalay-Bekő Máté <
> > szalay.beko.m...@gmail.com>
> > wrote:
> >
> > > I am not sure what is wrong with the code... I am not familiar
> with
> > > Curator. I can try to google / reproduce this and see what is
> wrong,
> > but it
> > > will take a while for me. So first I would ask the others,
> maybe
> > there is
> > > someone who knows both ZooKeeper SASL and Curator and can help
> you
> > more in
> > > this mailing list. If noone replies, then I will try to setup
> a dummy
> > > project with Curator to test this.
> > >
> > > Did you also ask around the Curator mailing list maybe? Would
> it
> > help if I
> > > send you code about setting the ACLs using plain ZooKeeper
> (and no
> > Curator)?
> > >
> > > On Tue, Jan 14, 2020 at 2:48 PM Arpit Jain <
> jain.arp...@gmail.com>
> > wrote:
> > >
> > >> Thanks for the clarification.
> > >> I am able to authenticate client with Zookeeper. However,
> when I
> > started
> > >> to set ACLs with the same client, I get error messages. This
> is how
> > I am
> > >> creating curator client for setting ACLs
> > >>
> > >> CuratorFrameworkFactory.Builder builder =
> > >>
> > >> CuratorFrameworkFactory.builder().connectString(
> > >> coordinatorHosts).retryPolicy(retryPolicy)
> > >>
> > >> .connectionTimeoutMs(coordinatorConnectionTimeout
> > >> ).sessionTimeoutMs(coordinatorSessionTimeout);
> > >>
> > >> final CuratorFramework curatorFramework =
> > >>
> > >> builder.authorization("sasl", "zkclient/
> > z...@example.com"
> > >> .getBytes()).aclProvider(new ACLProvider() {
> > >>
> > >> @Override
> > >>
> > >> public List getDefaultAcl() {
> > >>
> > >> return ZooDefs.Ids.CREATOR_ALL_ACL;
> > >>
> > >> }
> > >>
> > >>
> > >> @Override
> > >>
> > >> public List getAclForPath(String path) {
> > >>
> > >> return ZooDefs.Ids.CREATOR_ALL_ACL;
> > >>
> > >> }
> > >>
> > >> }).build();
> > >>
> > >>
> > >> I see below logs in Zookeeper node:
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> *2020-01-14 13:27:53,174 [myid:1] - INFO
> > >> [NIOWorkerThread-3:SaslServerCallbackHandler@120] -
> Successfully
> > >> authenticated client: authenticationID=zkclient/
> z...@example.com
> > >> ; authorizationID=zkclient/
> z...@example.com
> > >> .2020-01-14 13:27:53,175 [myid:1] - INFO
> > >> [NIOWorkerThread-3:SaslServerCallbackHandler@136] - Setting
> > authorizedID:
> > >> zkclient/z...@example.com 2020-01-14
> 13:27:53,175
> > >> [myid:1] - INFO
Re: Zookeeper and curator SASL authentication
Yes, they are system properties
You can take this guide (about Kafka) as example
https://docs.confluent.io/current/kafka/authentication_sasl/authentication_sasl_gssapi.html
Il giorno 15/01/20, 13:17 "Arpit Jain" ha scritto:
I have not passed those parameters. Is this something I need to set in
Zookeeper (zoo.cfg) ?
On Wed, Jan 15, 2020 at 12:12 PM Enrico Olivelli - Diennea <
enrico.olive...@diennea.com> wrote:
> Usually with SASL auth you are using:
> kerberos.removeHostFromPrincipal=true
> kerberos.removeRealmFromPrincipal=true
>
> is this the case for you ?
>
> Enrico
>
> Il giorno 15/01/20, 13:01 "Arpit Jain" ha
> scritto:
>
> I have asked in Curator mailing list as well but not much help. I am
> able
> to set ACL with sasl scheme by using zkCli.sh client in Zookeeper
> server.
> The idea is to use Curator to set the ACLs so that only my client
> application can access its Znodes.
>
>
> On Wed, Jan 15, 2020 at 9:21 AM Szalay-Bekő Máté <
> szalay.beko.m...@gmail.com>
> wrote:
>
> > I am not sure what is wrong with the code... I am not familiar with
> > Curator. I can try to google / reproduce this and see what is wrong,
> but it
> > will take a while for me. So first I would ask the others, maybe
> there is
> > someone who knows both ZooKeeper SASL and Curator and can help you
> more in
> > this mailing list. If noone replies, then I will try to setup a
dummy
> > project with Curator to test this.
> >
> > Did you also ask around the Curator mailing list maybe? Would it
> help if I
> > send you code about setting the ACLs using plain ZooKeeper (and no
> Curator)?
> >
> > On Tue, Jan 14, 2020 at 2:48 PM Arpit Jain
> wrote:
> >
> >> Thanks for the clarification.
> >> I am able to authenticate client with Zookeeper. However, when I
> started
> >> to set ACLs with the same client, I get error messages. This is how
> I am
> >> creating curator client for setting ACLs
> >>
> >> CuratorFrameworkFactory.Builder builder =
> >>
> >> CuratorFrameworkFactory.builder().connectString(
> >> coordinatorHosts).retryPolicy(retryPolicy)
> >>
> >> .connectionTimeoutMs(coordinatorConnectionTimeout
> >> ).sessionTimeoutMs(coordinatorSessionTimeout);
> >>
> >> final CuratorFramework curatorFramework =
> >>
> >> builder.authorization("sasl", "zkclient/
> z...@example.com"
> >> .getBytes()).aclProvider(new ACLProvider() {
> >>
> >> @Override
> >>
> >> public List getDefaultAcl() {
> >>
> >> return ZooDefs.Ids.CREATOR_ALL_ACL;
> >>
> >> }
> >>
> >>
> >> @Override
> >>
> >> public List getAclForPath(String path) {
> >>
> >> return ZooDefs.Ids.CREATOR_ALL_ACL;
> >>
> >> }
> >>
> >> }).build();
> >>
> >>
> >> I see below logs in Zookeeper node:
> >>
> >>
> >>
> >>
> >>
> >> *2020-01-14 13:27:53,174 [myid:1] - INFO
> >> [NIOWorkerThread-3:SaslServerCallbackHandler@120] - Successfully
> >> authenticated client: authenticationID=zkclient/z...@example.com
> >> ; authorizationID=zkclient/z...@example.com
> >> .2020-01-14 13:27:53,175 [myid:1] - INFO
> >> [NIOWorkerThread-3:SaslServerCallbackHandler@136] - Setting
> authorizedID:
> >> zkclient/z...@example.com 2020-01-14 13:27:53,175
> >> [myid:1] - INFO [NIOWorkerThread-3:ZooKeeperServer@1170] - adding
> SASL
> >> authorization for authorizationID: zkclient/z...@example.com
> >> 2020-01-14 13:27:53,182 [myid:1] - INFO
> >> [NIOWorkerThread-7:ZooKeeperServer@1095] - got auth packet
> >> /172.30.0.6:36658 2020-01-14 13:27:53,183
> [myid:1]
> >> - WARN [NIOWorkerThread-7:ZooKeeperServer@1123] - Authentication
> failed
> >> for scheme: sasl*
> >>
> >> Is this not the correct way to do it ?
> >>
> >>
> >>
> >> On Tue, Jan 14, 2020 at 11:52 AM Szalay-Bekő Máté <
> >> szalay.beko.m...@gmail.com> wrote:
> >>
> >>> The system property name is a bit misleading... this parameter is
> >>> actually specifies the username used in the ZooKeeper server
> principal.
> >>> (in your case the server principal is: zookeeper/z...@example.com)
> >>> AFAIK the ZooKeeper client
Re: Zookeeper and curator SASL authentication
I have asked in Curator mailing list as well but not much help. I am able
to set ACL with sasl scheme by using zkCli.sh client in Zookeeper server.
The idea is to use Curator to set the ACLs so that only my client
application can access its Znodes.
On Wed, Jan 15, 2020 at 9:21 AM Szalay-Bekő Máté
wrote:
> I am not sure what is wrong with the code... I am not familiar with
> Curator. I can try to google / reproduce this and see what is wrong, but it
> will take a while for me. So first I would ask the others, maybe there is
> someone who knows both ZooKeeper SASL and Curator and can help you more in
> this mailing list. If noone replies, then I will try to setup a dummy
> project with Curator to test this.
>
> Did you also ask around the Curator mailing list maybe? Would it help if I
> send you code about setting the ACLs using plain ZooKeeper (and no Curator)?
>
> On Tue, Jan 14, 2020 at 2:48 PM Arpit Jain wrote:
>
>> Thanks for the clarification.
>> I am able to authenticate client with Zookeeper. However, when I started
>> to set ACLs with the same client, I get error messages. This is how I am
>> creating curator client for setting ACLs
>>
>> CuratorFrameworkFactory.Builder builder =
>>
>> CuratorFrameworkFactory.builder().connectString(
>> coordinatorHosts).retryPolicy(retryPolicy)
>>
>> .connectionTimeoutMs(coordinatorConnectionTimeout
>> ).sessionTimeoutMs(coordinatorSessionTimeout);
>>
>> final CuratorFramework curatorFramework =
>>
>> builder.authorization("sasl", "zkclient/z...@example.com"
>> .getBytes()).aclProvider(new ACLProvider() {
>>
>> @Override
>>
>> public List getDefaultAcl() {
>>
>> return ZooDefs.Ids.CREATOR_ALL_ACL;
>>
>> }
>>
>>
>> @Override
>>
>> public List getAclForPath(String path) {
>>
>> return ZooDefs.Ids.CREATOR_ALL_ACL;
>>
>> }
>>
>> }).build();
>>
>>
>> I see below logs in Zookeeper node:
>>
>>
>>
>>
>>
>> *2020-01-14 13:27:53,174 [myid:1] - INFO
>> [NIOWorkerThread-3:SaslServerCallbackHandler@120] - Successfully
>> authenticated client: authenticationID=zkclient/z...@example.com
>> ; authorizationID=zkclient/z...@example.com
>> .2020-01-14 13:27:53,175 [myid:1] - INFO
>> [NIOWorkerThread-3:SaslServerCallbackHandler@136] - Setting authorizedID:
>> zkclient/z...@example.com 2020-01-14 13:27:53,175
>> [myid:1] - INFO [NIOWorkerThread-3:ZooKeeperServer@1170] - adding SASL
>> authorization for authorizationID: zkclient/z...@example.com
>> 2020-01-14 13:27:53,182 [myid:1] - INFO
>> [NIOWorkerThread-7:ZooKeeperServer@1095] - got auth packet
>> /172.30.0.6:36658 2020-01-14 13:27:53,183 [myid:1]
>> - WARN [NIOWorkerThread-7:ZooKeeperServer@1123] - Authentication failed
>> for scheme: sasl*
>>
>> Is this not the correct way to do it ?
>>
>>
>>
>> On Tue, Jan 14, 2020 at 11:52 AM Szalay-Bekő Máté <
>> szalay.beko.m...@gmail.com> wrote:
>>
>>> The system property name is a bit misleading... this parameter is
>>> actually specifies the username used in the ZooKeeper server principal.
>>> (in your case the server principal is: zookeeper/z...@example.com)
>>> AFAIK the ZooKeeper client (after authenticated as zkclient/
>>> z...@example.com in Kerberos based on the jaas.conf file) needs to know
>>> the ZooKeeper server principal in order to ask for a specific token from
>>> kerberos which can be read by the ZooKeeper server.
>>>
>>> In 3.5.5 (or 3.5.6) you can use the zookeeper.sasl.client.username
>>> parameter (plus some other parameters) to configure how the server
>>> principal will be determined by the client.
>>> See:
>>> https://github.com/apache/zookeeper/blob/c11b7e26bc554b8523dc929761dd28808913f091/zookeeper-server/src/main/java/org/apache/zookeeper/SaslServerPrincipal.java#L48
>>>
>>> In future releases (3.5.7, 3.6, ...) you can also use
>>> the zookeeper.server.principal parameter (a much better name I think) to
>>> use a fix server principal name in the client.
>>> See:
>>> https://github.com/apache/zookeeper/blob/1c5d135d74f16275876c024401dc2de92909b20a/zookeeper-server/src/main/java/org/apache/zookeeper/SaslServerPrincipal.java#L50
>>>
>>> On Mon, Jan 13, 2020 at 6:03 PM Arpit Jain
>>> wrote:
>>>
Does this user name have to be "Zookeeper"
(-Dzookeeper.sasl.client.username=zookeeper) always ?
And the client principal name is different than this username..Correct
me if I am wrong ?
On Mon, Jan 13, 2020 at 4:58 PM Arpit Jain
wrote:
> Thanks you so much !
> It worked finally. I had to change
> -Dzookeeper.sasl.client.username=zookeeper parameter.
>
> On Mon, Jan 13, 2020 at 4:40 PM Szalay-Bekő Máté <
> szalay.beko.m...@gmail.com> wrote:
>
>> You are using 3.5.5 or 3.5.6, right?
>> I think you need to specify:
>> -Dzookeeper.sasl.client.username=zookeeper
>> can you give it a try? If it doesn't
Re: Zookeeper and curator SASL authentication
I am not sure what is wrong with the code... I am not familiar with
Curator. I can try to google / reproduce this and see what is wrong, but it
will take a while for me. So first I would ask the others, maybe there is
someone who knows both ZooKeeper SASL and Curator and can help you more in
this mailing list. If noone replies, then I will try to setup a dummy
project with Curator to test this.
Did you also ask around the Curator mailing list maybe? Would it help if I
send you code about setting the ACLs using plain ZooKeeper (and no Curator)?
On Tue, Jan 14, 2020 at 2:48 PM Arpit Jain wrote:
> Thanks for the clarification.
> I am able to authenticate client with Zookeeper. However, when I started
> to set ACLs with the same client, I get error messages. This is how I am
> creating curator client for setting ACLs
>
> CuratorFrameworkFactory.Builder builder =
>
> CuratorFrameworkFactory.builder().connectString(
> coordinatorHosts).retryPolicy(retryPolicy)
>
> .connectionTimeoutMs(coordinatorConnectionTimeout
> ).sessionTimeoutMs(coordinatorSessionTimeout);
>
> final CuratorFramework curatorFramework =
>
> builder.authorization("sasl", "zkclient/z...@example.com"
> .getBytes()).aclProvider(new ACLProvider() {
>
> @Override
>
> public List getDefaultAcl() {
>
> return ZooDefs.Ids.CREATOR_ALL_ACL;
>
> }
>
>
> @Override
>
> public List getAclForPath(String path) {
>
> return ZooDefs.Ids.CREATOR_ALL_ACL;
>
> }
>
> }).build();
>
>
> I see below logs in Zookeeper node:
>
>
>
>
>
> *2020-01-14 13:27:53,174 [myid:1] - INFO
> [NIOWorkerThread-3:SaslServerCallbackHandler@120] - Successfully
> authenticated client: authenticationID=zkclient/z...@example.com
> ; authorizationID=zkclient/z...@example.com
> .2020-01-14 13:27:53,175 [myid:1] - INFO
> [NIOWorkerThread-3:SaslServerCallbackHandler@136] - Setting authorizedID:
> zkclient/z...@example.com 2020-01-14 13:27:53,175
> [myid:1] - INFO [NIOWorkerThread-3:ZooKeeperServer@1170] - adding SASL
> authorization for authorizationID: zkclient/z...@example.com
> 2020-01-14 13:27:53,182 [myid:1] - INFO
> [NIOWorkerThread-7:ZooKeeperServer@1095] - got auth packet
> /172.30.0.6:36658 2020-01-14 13:27:53,183 [myid:1]
> - WARN [NIOWorkerThread-7:ZooKeeperServer@1123] - Authentication failed
> for scheme: sasl*
>
> Is this not the correct way to do it ?
>
>
>
> On Tue, Jan 14, 2020 at 11:52 AM Szalay-Bekő Máté <
> szalay.beko.m...@gmail.com> wrote:
>
>> The system property name is a bit misleading... this parameter is
>> actually specifies the username used in the ZooKeeper server principal.
>> (in your case the server principal is: zookeeper/z...@example.com)
>> AFAIK the ZooKeeper client (after authenticated as zkclient/
>> z...@example.com in Kerberos based on the jaas.conf file) needs to know
>> the ZooKeeper server principal in order to ask for a specific token from
>> kerberos which can be read by the ZooKeeper server.
>>
>> In 3.5.5 (or 3.5.6) you can use the zookeeper.sasl.client.username
>> parameter (plus some other parameters) to configure how the server
>> principal will be determined by the client.
>> See:
>> https://github.com/apache/zookeeper/blob/c11b7e26bc554b8523dc929761dd28808913f091/zookeeper-server/src/main/java/org/apache/zookeeper/SaslServerPrincipal.java#L48
>>
>> In future releases (3.5.7, 3.6, ...) you can also use
>> the zookeeper.server.principal parameter (a much better name I think) to
>> use a fix server principal name in the client.
>> See:
>> https://github.com/apache/zookeeper/blob/1c5d135d74f16275876c024401dc2de92909b20a/zookeeper-server/src/main/java/org/apache/zookeeper/SaslServerPrincipal.java#L50
>>
>> On Mon, Jan 13, 2020 at 6:03 PM Arpit Jain wrote:
>>
>>> Does this user name have to be "Zookeeper"
>>> (-Dzookeeper.sasl.client.username=zookeeper) always ?
>>> And the client principal name is different than this username..Correct
>>> me if I am wrong ?
>>>
>>> On Mon, Jan 13, 2020 at 4:58 PM Arpit Jain
>>> wrote:
>>>
Thanks you so much !
It worked finally. I had to change
-Dzookeeper.sasl.client.username=zookeeper parameter.
On Mon, Jan 13, 2020 at 4:40 PM Szalay-Bekő Máté <
szalay.beko.m...@gmail.com> wrote:
> You are using 3.5.5 or 3.5.6, right?
> I think you need to specify: -Dzookeeper.sasl.client.username=zookeeper
> can you give it a try? If it doesn't work then I can take a deeper
> look (also we can enable some debug logging)
>
> On Mon, Jan 13, 2020 at 5:31 PM Arpit Jain
> wrote:
>
>> Hi
>>
>> I have Kerberos, Zookeeper and my application (using curator) running
>> in 3 docker containers with ZK SASL authentication enabled. The ZK can
>> login to Kerberos and starts successfully.
>>
>> The ZK server principal is zookeeper/z...@example.com
Re: Zookeeper and curator SASL authentication
Thanks for the clarification.
I am able to authenticate client with Zookeeper. However, when I started to
set ACLs with the same client, I get error messages. This is how I am
creating curator client for setting ACLs
CuratorFrameworkFactory.Builder builder =
CuratorFrameworkFactory.builder().connectString(coordinatorHosts
).retryPolicy(retryPolicy)
.connectionTimeoutMs(coordinatorConnectionTimeout
).sessionTimeoutMs(coordinatorSessionTimeout);
final CuratorFramework curatorFramework =
builder.authorization("sasl", "zkclient/z...@example.com"
.getBytes()).aclProvider(new ACLProvider() {
@Override
public List getDefaultAcl() {
return ZooDefs.Ids.CREATOR_ALL_ACL;
}
@Override
public List getAclForPath(String path) {
return ZooDefs.Ids.CREATOR_ALL_ACL;
}
}).build();
I see below logs in Zookeeper node:
*2020-01-14 13:27:53,174 [myid:1] - INFO
[NIOWorkerThread-3:SaslServerCallbackHandler@120] - Successfully
authenticated client: authenticationID=zkclient/z...@example.com
; authorizationID=zkclient/z...@example.com
.2020-01-14 13:27:53,175 [myid:1] - INFO
[NIOWorkerThread-3:SaslServerCallbackHandler@136] - Setting authorizedID:
zkclient/z...@example.com 2020-01-14 13:27:53,175
[myid:1] - INFO [NIOWorkerThread-3:ZooKeeperServer@1170] - adding SASL
authorization for authorizationID: zkclient/z...@example.com
2020-01-14 13:27:53,182 [myid:1] - INFO
[NIOWorkerThread-7:ZooKeeperServer@1095] - got auth packet
/172.30.0.6:36658 2020-01-14 13:27:53,183 [myid:1]
- WARN [NIOWorkerThread-7:ZooKeeperServer@1123] - Authentication failed
for scheme: sasl*
Is this not the correct way to do it ?
On Tue, Jan 14, 2020 at 11:52 AM Szalay-Bekő Máté <
szalay.beko.m...@gmail.com> wrote:
> The system property name is a bit misleading... this parameter is actually
> specifies the username used in the ZooKeeper server principal. (in your
> case the server principal is: zookeeper/z...@example.com)
> AFAIK the ZooKeeper client (after authenticated as zkclient/
> z...@example.com in Kerberos based on the jaas.conf file) needs to know
> the ZooKeeper server principal in order to ask for a specific token from
> kerberos which can be read by the ZooKeeper server.
>
> In 3.5.5 (or 3.5.6) you can use the zookeeper.sasl.client.username
> parameter (plus some other parameters) to configure how the server
> principal will be determined by the client.
> See:
> https://github.com/apache/zookeeper/blob/c11b7e26bc554b8523dc929761dd28808913f091/zookeeper-server/src/main/java/org/apache/zookeeper/SaslServerPrincipal.java#L48
>
> In future releases (3.5.7, 3.6, ...) you can also use
> the zookeeper.server.principal parameter (a much better name I think) to
> use a fix server principal name in the client.
> See:
> https://github.com/apache/zookeeper/blob/1c5d135d74f16275876c024401dc2de92909b20a/zookeeper-server/src/main/java/org/apache/zookeeper/SaslServerPrincipal.java#L50
>
> On Mon, Jan 13, 2020 at 6:03 PM Arpit Jain wrote:
>
>> Does this user name have to be "Zookeeper"
>> (-Dzookeeper.sasl.client.username=zookeeper) always ?
>> And the client principal name is different than this username..Correct me
>> if I am wrong ?
>>
>> On Mon, Jan 13, 2020 at 4:58 PM Arpit Jain wrote:
>>
>>> Thanks you so much !
>>> It worked finally. I had to change
>>> -Dzookeeper.sasl.client.username=zookeeper parameter.
>>>
>>> On Mon, Jan 13, 2020 at 4:40 PM Szalay-Bekő Máté <
>>> szalay.beko.m...@gmail.com> wrote:
>>>
You are using 3.5.5 or 3.5.6, right?
I think you need to specify: -Dzookeeper.sasl.client.username=zookeeper
can you give it a try? If it doesn't work then I can take a deeper look
(also we can enable some debug logging)
On Mon, Jan 13, 2020 at 5:31 PM Arpit Jain
wrote:
> Hi
>
> I have Kerberos, Zookeeper and my application (using curator) running
> in 3 docker containers with ZK SASL authentication enabled. The ZK can
> login to Kerberos and starts successfully.
>
> The ZK server principal is zookeeper/z...@example.com
> The client principal is : zkclient/z...@example.com
>
> While starting my application, I am seeing failure while obtaining
> TGS.
> See the log at Kerberos side:
>
>
>
> *Jan 13 15:22:19 kdc krb5kdc[20](info): AS_REQ (2 etypes {18 17})
> 172.30.0.6 : NEEDED_PREAUTH: zkclient/z...@example.com
> for krbtgt/example@example.com
> , Additional pre-authentication requiredJan 13
> 15:22:19 kdc krb5kdc[20](info): AS_REQ (2 etypes {18 17}) 172.30.0.6
> : ISSUE: authtime 1578928939, etypes {rep=18 tkt=18
> ses=18}, zkclient/z...@example.com for
> krbtgt/example@example.com Jan 13 15:22:19
> kdc
> krb5kdc[20](info): TGS_REQ (4 etypes {18 17 16
Re: Zookeeper and curator SASL authentication
The system property name is a bit misleading... this parameter is actually
specifies the username used in the ZooKeeper server principal. (in your
case the server principal is: zookeeper/z...@example.com)
AFAIK the ZooKeeper client (after authenticated as zkclient/z...@example.com
in Kerberos based on the jaas.conf file) needs to know the ZooKeeper server
principal in order to ask for a specific token from kerberos which can be
read by the ZooKeeper server.
In 3.5.5 (or 3.5.6) you can use the zookeeper.sasl.client.username
parameter (plus some other parameters) to configure how the server
principal will be determined by the client.
See:
https://github.com/apache/zookeeper/blob/c11b7e26bc554b8523dc929761dd28808913f091/zookeeper-server/src/main/java/org/apache/zookeeper/SaslServerPrincipal.java#L48
In future releases (3.5.7, 3.6, ...) you can also use
the zookeeper.server.principal parameter (a much better name I think) to
use a fix server principal name in the client.
See:
https://github.com/apache/zookeeper/blob/1c5d135d74f16275876c024401dc2de92909b20a/zookeeper-server/src/main/java/org/apache/zookeeper/SaslServerPrincipal.java#L50
On Mon, Jan 13, 2020 at 6:03 PM Arpit Jain wrote:
> Does this user name have to be "Zookeeper"
> (-Dzookeeper.sasl.client.username=zookeeper) always ?
> And the client principal name is different than this username..Correct me
> if I am wrong ?
>
> On Mon, Jan 13, 2020 at 4:58 PM Arpit Jain wrote:
>
>> Thanks you so much !
>> It worked finally. I had to change
>> -Dzookeeper.sasl.client.username=zookeeper parameter.
>>
>> On Mon, Jan 13, 2020 at 4:40 PM Szalay-Bekő Máté <
>> szalay.beko.m...@gmail.com> wrote:
>>
>>> You are using 3.5.5 or 3.5.6, right?
>>> I think you need to specify: -Dzookeeper.sasl.client.username=zookeeper
>>> can you give it a try? If it doesn't work then I can take a deeper look
>>> (also we can enable some debug logging)
>>>
>>> On Mon, Jan 13, 2020 at 5:31 PM Arpit Jain
>>> wrote:
>>>
Hi
I have Kerberos, Zookeeper and my application (using curator) running
in 3 docker containers with ZK SASL authentication enabled. The ZK can
login to Kerberos and starts successfully.
The ZK server principal is zookeeper/z...@example.com
The client principal is : zkclient/z...@example.com
While starting my application, I am seeing failure while obtaining TGS.
See the log at Kerberos side:
*Jan 13 15:22:19 kdc krb5kdc[20](info): AS_REQ (2 etypes {18 17})
172.30.0.6 : NEEDED_PREAUTH: zkclient/z...@example.com
for krbtgt/example@example.com
, Additional pre-authentication requiredJan 13
15:22:19 kdc krb5kdc[20](info): AS_REQ (2 etypes {18 17}) 172.30.0.6
: ISSUE: authtime 1578928939, etypes {rep=18 tkt=18
ses=18}, zkclient/z...@example.com for
krbtgt/example@example.com Jan 13 15:22:19 kdc
krb5kdc[20](info): TGS_REQ (4 etypes {18 17 16 23}) 172.30.0.6
: ISSUE: authtime 1578928939, etypes {rep=18 tkt=18
ses=18}, zkclient/z...@example.com for
zkclient/z...@example.com *
However, if I use the zkCli.sh to login to Zookeeper, it successfully
logs in. See the log on Kerberos side. See the difference in the last line
while requesting TGS.
*Jan 13 15:26:14 kdc krb5kdc[20](info): AS_REQ (2 etypes {18 17})
172.30.0.3 : NEEDED_PREAUTH: zkclient/z...@example.com
for krbtgt/example@example.com
, Additional pre-authentication requiredJan 13
15:26:14 kdc krb5kdc[20](info): AS_REQ (2 etypes {18 17}) 172.30.0.3
: ISSUE: authtime 1578929174, etypes {rep=18 tkt=18
ses=18}, zkclient/z...@example.com for
krbtgt/example@example.com Jan 13 15:26:14 kdc
krb5kdc[20](info): TGS_REQ (4 etypes {18 17 16 23}) 172.30.0.3
: ISSUE: authtime 1578929174, etypes {rep=18 tkt=18
ses=18}, zkclient/z...@example.com for
zookeeper/z...@example.com *
The client section in JAAS config file is same in both the cases but
the server it is looking for is different in both the cases.
Could someone suggest why there is a difference ?
Thanks
On Mon, Jan 13, 2020 at 4:17 PM Szalay-Bekő Máté <
szalay.beko.m...@gmail.com> wrote:
> Also please note, that the
> 'Configuration.getConfiguration().refresh()' will reload only the
> jaas.config.
> If you also need to reload the kerberos client config, then you can
> add the "refreshKrb5Config=true" line to your jaas.conf file. This will
> trigger to reload the krb.cfg file as well if needed.
>
> I am just working on a PR where I had to use both of these:
> https://github.com/apache/zookeeper/pull/1204/files#diff-0c01d3c68a71c68701d778cc556c8e0a
>
> Cheers,
> Mate
>
> On Thu, Jan 9, 2020 at 10:02 PM Damien
Re: Zookeeper and curator SASL authentication
You are using 3.5.5 or 3.5.6, right?
I think you need to specify: -Dzookeeper.sasl.client.username=zookeeper
can you give it a try? If it doesn't work then I can take a deeper look
(also we can enable some debug logging)
On Mon, Jan 13, 2020 at 5:31 PM Arpit Jain wrote:
> Hi
>
> I have Kerberos, Zookeeper and my application (using curator) running in 3
> docker containers with ZK SASL authentication enabled. The ZK can login to
> Kerberos and starts successfully.
>
> The ZK server principal is zookeeper/z...@example.com
> The client principal is : zkclient/z...@example.com
>
> While starting my application, I am seeing failure while obtaining TGS.
> See the log at Kerberos side:
>
>
>
> *Jan 13 15:22:19 kdc krb5kdc[20](info): AS_REQ (2 etypes {18 17})
> 172.30.0.6 : NEEDED_PREAUTH: zkclient/z...@example.com
> for krbtgt/example@example.com
> , Additional pre-authentication requiredJan 13
> 15:22:19 kdc krb5kdc[20](info): AS_REQ (2 etypes {18 17}) 172.30.0.6
> : ISSUE: authtime 1578928939, etypes {rep=18 tkt=18
> ses=18}, zkclient/z...@example.com for
> krbtgt/example@example.com Jan 13 15:22:19 kdc
> krb5kdc[20](info): TGS_REQ (4 etypes {18 17 16 23}) 172.30.0.6
> : ISSUE: authtime 1578928939, etypes {rep=18 tkt=18
> ses=18}, zkclient/z...@example.com for
> zkclient/z...@example.com *
>
> However, if I use the zkCli.sh to login to Zookeeper, it successfully logs
> in. See the log on Kerberos side. See the difference in the last line while
> requesting TGS.
>
>
>
> *Jan 13 15:26:14 kdc krb5kdc[20](info): AS_REQ (2 etypes {18 17})
> 172.30.0.3 : NEEDED_PREAUTH: zkclient/z...@example.com
> for krbtgt/example@example.com
> , Additional pre-authentication requiredJan 13
> 15:26:14 kdc krb5kdc[20](info): AS_REQ (2 etypes {18 17}) 172.30.0.3
> : ISSUE: authtime 1578929174, etypes {rep=18 tkt=18
> ses=18}, zkclient/z...@example.com for
> krbtgt/example@example.com Jan 13 15:26:14 kdc
> krb5kdc[20](info): TGS_REQ (4 etypes {18 17 16 23}) 172.30.0.3
> : ISSUE: authtime 1578929174, etypes {rep=18 tkt=18
> ses=18}, zkclient/z...@example.com for
> zookeeper/z...@example.com *
>
> The client section in JAAS config file is same in both the cases but the
> server it is looking for is different in both the cases.
> Could someone suggest why there is a difference ?
>
> Thanks
>
>
>
> On Mon, Jan 13, 2020 at 4:17 PM Szalay-Bekő Máté <
> szalay.beko.m...@gmail.com> wrote:
>
>> Also please note, that the 'Configuration.getConfiguration().refresh()'
>> will reload only the jaas.config.
>> If you also need to reload the kerberos client config, then you can add
>> the "refreshKrb5Config=true" line to your jaas.conf file. This will trigger
>> to reload the krb.cfg file as well if needed.
>>
>> I am just working on a PR where I had to use both of these:
>> https://github.com/apache/zookeeper/pull/1204/files#diff-0c01d3c68a71c68701d778cc556c8e0a
>>
>> Cheers,
>> Mate
>>
>> On Thu, Jan 9, 2020 at 10:02 PM Damien Diederen
>> wrote:
>>
>>>
>>> Hi Enrico,
>>>
>>> > There is a method to force JAAS to reload the system property.
>>> >
>>> > Something like Configuration.getConfiguration().refresh()
>>>
>>> Great to know! Thanks!
>>>
>>> > You have to call that method after changing the system property
>>>
>>> Cheers, -D
>>>
>>>
>>>
>>> > Il gio 9 gen 2020, 20:05 Damien Diederen ha
>>> > scritto:
>>> >
>>> >>
>>> >> Hi Arpit, Máté,
>>> >>
>>> >> Arpit wrote:
>>> >>
>>> >> > The solution is to pass JAAS file
>>> >> > with -Djava.security.auth.login.config=/path/to/jaas.conf.
>>> >>
>>> >> Okay—good.
>>> >>
>>> >> > Using System.setProperty does not work for me.
>>> >>
>>> >> Ah, I see. And I'm not surprised; I think Máté is on the right track:
>>> >>
>>> >> >> I also faced this exception not long ago. I think it is an edge
>>> case,
>>> >> most
>>> >> >> probably you have something else, but still... maybe it helps:
>>> >> >>
>>> >> >> I tried to write a unit test which dynamically generated multiple
>>> >> >> jaas.conf files. Then I was setting the
>>> >> >> java.security.auth.login.config system property to the config file
>>> I
>>> >> needed
>>> >> >> in the given testcase, and when I tried to establish a ZooKeeper
>>> >> connection
>>> >> >> in the unit test, I also got the same exception that you got.
>>> >> >>
>>> >> >> The problem was, that the security configuration file I referred
>>> in the
>>> >> >> java.security.auth.login.config system property file was read only
>>> once,
>>> >> >> then stored in memory. And it haven't got reloaded, even if the
>>> file (or
>>> >> >> its path in the system property) changed.
>>> >>
>>> >> My understanding is that the property is read very early after "VM
>>> boot"
>>> >> (the first time any class tries to access the java.security.Provider):
>>> >> the resource it points to is parsed at that point, and the property
>>> >> "never" checked again.
>>> >>
Re: Zookeeper and curator SASL authentication
Also please note, that the 'Configuration.getConfiguration().refresh()' will reload only the jaas.config. If you also need to reload the kerberos client config, then you can add the "refreshKrb5Config=true" line to your jaas.conf file. This will trigger to reload the krb.cfg file as well if needed. I am just working on a PR where I had to use both of these: https://github.com/apache/zookeeper/pull/1204/files#diff-0c01d3c68a71c68701d778cc556c8e0a Cheers, Mate On Thu, Jan 9, 2020 at 10:02 PM Damien Diederen wrote: > > Hi Enrico, > > > There is a method to force JAAS to reload the system property. > > > > Something like Configuration.getConfiguration().refresh() > > Great to know! Thanks! > > > You have to call that method after changing the system property > > Cheers, -D > > > > > Il gio 9 gen 2020, 20:05 Damien Diederen ha > > scritto: > > > >> > >> Hi Arpit, Máté, > >> > >> Arpit wrote: > >> > >> > The solution is to pass JAAS file > >> > with -Djava.security.auth.login.config=/path/to/jaas.conf. > >> > >> Okay—good. > >> > >> > Using System.setProperty does not work for me. > >> > >> Ah, I see. And I'm not surprised; I think Máté is on the right track: > >> > >> >> I also faced this exception not long ago. I think it is an edge case, > >> most > >> >> probably you have something else, but still... maybe it helps: > >> >> > >> >> I tried to write a unit test which dynamically generated multiple > >> >> jaas.conf files. Then I was setting the > >> >> java.security.auth.login.config system property to the config file I > >> needed > >> >> in the given testcase, and when I tried to establish a ZooKeeper > >> connection > >> >> in the unit test, I also got the same exception that you got. > >> >> > >> >> The problem was, that the security configuration file I referred in > the > >> >> java.security.auth.login.config system property file was read only > once, > >> >> then stored in memory. And it haven't got reloaded, even if the file > (or > >> >> its path in the system property) changed. > >> > >> My understanding is that the property is read very early after "VM boot" > >> (the first time any class tries to access the java.security.Provider): > >> the resource it points to is parsed at that point, and the property > >> "never" checked again. > >> > >> (It *may* be possible to flush the "Spi" or something, but it's clearly > >> not the kind of usage it was designed for.) > >> > >> >> Maybe the best in this case is to > >> >> specify separate JAAS config sections for each tests and use a single > >> >> JAAS.conf file per JVM. > >> > >> That's probably the easiest if the set is enumerable. > >> > >> "Real dynamism" might require overriding the "Spi" or "Provider," but > >> that's probably overkill for a few tests. > >> > >> (Now that I think of it… our tests are already run under the JMockit > >> agent, so live-patching JAAS methods using mockit.MockUp might be > >> another option :) > >> > >> Anyway. It looks like setting the property externally worked for Arpit. > >> > >> Cheers, -D > >> >
Re: Zookeeper and curator SASL authentication
Hi Enrico, > There is a method to force JAAS to reload the system property. > > Something like Configuration.getConfiguration().refresh() Great to know! Thanks! > You have to call that method after changing the system property Cheers, -D > Il gio 9 gen 2020, 20:05 Damien Diederen ha > scritto: > >> >> Hi Arpit, Máté, >> >> Arpit wrote: >> >> > The solution is to pass JAAS file >> > with -Djava.security.auth.login.config=/path/to/jaas.conf. >> >> Okay—good. >> >> > Using System.setProperty does not work for me. >> >> Ah, I see. And I'm not surprised; I think Máté is on the right track: >> >> >> I also faced this exception not long ago. I think it is an edge case, >> most >> >> probably you have something else, but still... maybe it helps: >> >> >> >> I tried to write a unit test which dynamically generated multiple >> >> jaas.conf files. Then I was setting the >> >> java.security.auth.login.config system property to the config file I >> needed >> >> in the given testcase, and when I tried to establish a ZooKeeper >> connection >> >> in the unit test, I also got the same exception that you got. >> >> >> >> The problem was, that the security configuration file I referred in the >> >> java.security.auth.login.config system property file was read only once, >> >> then stored in memory. And it haven't got reloaded, even if the file (or >> >> its path in the system property) changed. >> >> My understanding is that the property is read very early after "VM boot" >> (the first time any class tries to access the java.security.Provider): >> the resource it points to is parsed at that point, and the property >> "never" checked again. >> >> (It *may* be possible to flush the "Spi" or something, but it's clearly >> not the kind of usage it was designed for.) >> >> >> Maybe the best in this case is to >> >> specify separate JAAS config sections for each tests and use a single >> >> JAAS.conf file per JVM. >> >> That's probably the easiest if the set is enumerable. >> >> "Real dynamism" might require overriding the "Spi" or "Provider," but >> that's probably overkill for a few tests. >> >> (Now that I think of it… our tests are already run under the JMockit >> agent, so live-patching JAAS methods using mockit.MockUp might be >> another option :) >> >> Anyway. It looks like setting the property externally worked for Arpit. >> >> Cheers, -D >>
Re: Zookeeper and curator SASL authentication
There is a method to force JAAS to reload the system property. Something like Configuration.getConfiguration().refresh() You have to call that method after changing the system property Hope that helps Enrico Il gio 9 gen 2020, 20:05 Damien Diederen ha scritto: > > Hi Arpit, Máté, > > Arpit wrote: > > > The solution is to pass JAAS file > > with -Djava.security.auth.login.config=/path/to/jaas.conf. > > Okay—good. > > > Using System.setProperty does not work for me. > > Ah, I see. And I'm not surprised; I think Máté is on the right track: > > >> I also faced this exception not long ago. I think it is an edge case, > most > >> probably you have something else, but still... maybe it helps: > >> > >> I tried to write a unit test which dynamically generated multiple > >> jaas.conf files. Then I was setting the > >> java.security.auth.login.config system property to the config file I > needed > >> in the given testcase, and when I tried to establish a ZooKeeper > connection > >> in the unit test, I also got the same exception that you got. > >> > >> The problem was, that the security configuration file I referred in the > >> java.security.auth.login.config system property file was read only once, > >> then stored in memory. And it haven't got reloaded, even if the file (or > >> its path in the system property) changed. > > My understanding is that the property is read very early after "VM boot" > (the first time any class tries to access the java.security.Provider): > the resource it points to is parsed at that point, and the property > "never" checked again. > > (It *may* be possible to flush the "Spi" or something, but it's clearly > not the kind of usage it was designed for.) > > >> Maybe the best in this case is to > >> specify separate JAAS config sections for each tests and use a single > >> JAAS.conf file per JVM. > > That's probably the easiest if the set is enumerable. > > "Real dynamism" might require overriding the "Spi" or "Provider," but > that's probably overkill for a few tests. > > (Now that I think of it… our tests are already run under the JMockit > agent, so live-patching JAAS methods using mockit.MockUp might be > another option :) > > Anyway. It looks like setting the property externally worked for Arpit. > > Cheers, -D >
Re: Zookeeper and curator SASL authentication
Hi Arpit, Máté, Arpit wrote: > The solution is to pass JAAS file > with -Djava.security.auth.login.config=/path/to/jaas.conf. Okay—good. > Using System.setProperty does not work for me. Ah, I see. And I'm not surprised; I think Máté is on the right track: >> I also faced this exception not long ago. I think it is an edge case, most >> probably you have something else, but still... maybe it helps: >> >> I tried to write a unit test which dynamically generated multiple >> jaas.conf files. Then I was setting the >> java.security.auth.login.config system property to the config file I needed >> in the given testcase, and when I tried to establish a ZooKeeper connection >> in the unit test, I also got the same exception that you got. >> >> The problem was, that the security configuration file I referred in the >> java.security.auth.login.config system property file was read only once, >> then stored in memory. And it haven't got reloaded, even if the file (or >> its path in the system property) changed. My understanding is that the property is read very early after "VM boot" (the first time any class tries to access the java.security.Provider): the resource it points to is parsed at that point, and the property "never" checked again. (It *may* be possible to flush the "Spi" or something, but it's clearly not the kind of usage it was designed for.) >> Maybe the best in this case is to >> specify separate JAAS config sections for each tests and use a single >> JAAS.conf file per JVM. That's probably the easiest if the set is enumerable. "Real dynamism" might require overriding the "Spi" or "Provider," but that's probably overkill for a few tests. (Now that I think of it… our tests are already run under the JMockit agent, so live-patching JAAS methods using mockit.MockUp might be another option :) Anyway. It looks like setting the property externally worked for Arpit. Cheers, -D
Re: Zookeeper and curator SASL authentication
The solution is to pass JAAS file with -Djava.security.auth.login.config=/path/to/jaas.conf. Using System.setProperty does not work for me. On Thu, Jan 9, 2020 at 3:49 PM Szalay-Bekő Máté wrote: > I also faced this exception not long ago. I think it is an edge case, most > probably you have something else, but still... maybe it helps: > > I tried to write a unit test which dynamically generated multiple > jaas.conf files. Then I was setting the > java.security.auth.login.config system property to the config file I needed > in the given testcase, and when I tried to establish a ZooKeeper connection > in the unit test, I also got the same exception that you got. > > The problem was, that the security configuration file I referred in the > java.security.auth.login.config system property file was read only once, > then stored in memory. And it haven't got reloaded, even if the file (or > its path in the system property) changed. Maybe the best in this case is to > specify separate JAAS config sections for each tests and use a single > JAAS.conf file per JVM. > > Mate > > On Thu, Jan 9, 2020 at 2:56 PM Damien Diederen > wrote: > >> >> Hi Arpit, >> >> > I am trying to do SASL authentication between ZK and curator. […] >> >> Okay. >> >> > I am also setting -Dzookeeper.sasl.clientconfig="Client" system >> > variable. >> >> Looking at my deployments, I am specifying the location of the >> configuration file using another system property: >> >> -Djava.security.auth.login.config=/path/to/jaas.conf >> >> > SASL configuration failed: javax.security.auth.login.LoginException: No >> > JAAS configuration section named 'Client' was found in specified JAAS >> > configuration file: '//jaas.conf'. >> >> It looks like your "JAAS config key" is explicitly set to a bogus value >> (via the aforementioned system property or some other config file): >> >> //jaas.conf >> >> HTH, -D >> >
Re: Zookeeper and curator SASL authentication
I also faced this exception not long ago. I think it is an edge case, most probably you have something else, but still... maybe it helps: I tried to write a unit test which dynamically generated multiple jaas.conf files. Then I was setting the java.security.auth.login.config system property to the config file I needed in the given testcase, and when I tried to establish a ZooKeeper connection in the unit test, I also got the same exception that you got. The problem was, that the security configuration file I referred in the java.security.auth.login.config system property file was read only once, then stored in memory. And it haven't got reloaded, even if the file (or its path in the system property) changed. Maybe the best in this case is to specify separate JAAS config sections for each tests and use a single JAAS.conf file per JVM. Mate On Thu, Jan 9, 2020 at 2:56 PM Damien Diederen wrote: > > Hi Arpit, > > > I am trying to do SASL authentication between ZK and curator. […] > > Okay. > > > I am also setting -Dzookeeper.sasl.clientconfig="Client" system > > variable. > > Looking at my deployments, I am specifying the location of the > configuration file using another system property: > > -Djava.security.auth.login.config=/path/to/jaas.conf > > > SASL configuration failed: javax.security.auth.login.LoginException: No > > JAAS configuration section named 'Client' was found in specified JAAS > > configuration file: '//jaas.conf'. > > It looks like your "JAAS config key" is explicitly set to a bogus value > (via the aforementioned system property or some other config file): > > //jaas.conf > > HTH, -D >
Re: Zookeeper and curator SASL authentication
Hi Arpit, > I am trying to do SASL authentication between ZK and curator. […] Okay. > I am also setting -Dzookeeper.sasl.clientconfig="Client" system > variable. Looking at my deployments, I am specifying the location of the configuration file using another system property: -Djava.security.auth.login.config=/path/to/jaas.conf > SASL configuration failed: javax.security.auth.login.LoginException: No > JAAS configuration section named 'Client' was found in specified JAAS > configuration file: '//jaas.conf'. It looks like your "JAAS config key" is explicitly set to a bogus value (via the aforementioned system property or some other config file): //jaas.conf HTH, -D
Zookeeper and curator SASL authentication
Hi,
I am trying to do SASL authentication between ZK and curator. Principal for
curator is added in Kerberos server. While starting up curator, I see below
message in logs even though JAAS file has "Client" section. I am also
setting -Dzookeeper.sasl.clientconfig="Client" system variable.
*2020-01-06 11:38:06.443+ [L: WARN] [O: o.a.z.ClientCnxn] [I: ] [U: ]
[S: ] [P: platform] [T: localhost-startStop-1-SendThread(localhost:2181)]
SASL configuration failed: javax.security.auth.login.LoginException: No
JAAS configuration section named 'Client' was found in specified JAAS
configuration file: '//jaas.conf'. Will continue connection to
Zookeeper server without SASL authentication, if Zookeeper server allows
it.*
I am using Curator version 4.2.0 and ZK version 3.5.6.
JAAS file looks like this:
*Client { com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true keyTab="//zkclient.keytab"
storeKey=true useTicketCache=false principal="zkclient";};*
I am asking here as someone might have seen this issue and help me proceed.
Thanks
