great! :)
On Wed, Jan 15, 2020 at 6:38 PM Arpit Jain <jain.arpit6@gmail.com> 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.olivelli@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" <jain.arpit6@gmail.com> 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.olivelli@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" <jain.arpit6@gmail.com> 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.mate@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.arpit6@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/
>> > zoo1@EXAMPLE.COM"
>> > >> .getBytes()).aclProvider(new ACLProvider() {
>> > >>
>> > >> @Override
>> > >>
>> > >> public List<ACL> getDefaultAcl() {
>> > >>
>> > >> return ZooDefs.Ids.CREATOR_ALL_ACL;
>> > >>
>> > >> }
>> > >>
>> > >>
>> > >> @Override
>> > >>
>> > >> public List<ACL> 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/
>> zoo1@EXAMPLE.COM
>> > >> <zoo1@EXAMPLE.COM>; authorizationID=zkclient/
>> zoo1@EXAMPLE.COM
>> > >> <zoo1@EXAMPLE.COM>.2020-01-14 13:27:53,175 [myid:1] -
INFO
>> > >> [NIOWorkerThread-3:SaslServerCallbackHandler@136] - Setting
>> > authorizedID:
>> > >> zkclient/zoo1@EXAMPLE.COM <zoo1@EXAMPLE.COM>2020-01-14
>> 13:27:53,175
>> > >> [myid:1] - INFO [NIOWorkerThread-3:ZooKeeperServer@1170] -
>> adding
>> > SASL
>> > >> authorization for authorizationID: zkclient/zoo1@EXAMPLE.COM
>> > >> <zoo1@EXAMPLE.COM>2020-01-14 13:27:53,182 [myid:1] -
INFO
>> > >> [NIOWorkerThread-7:ZooKeeperServer@1095] - got auth packet
>> > >> /172.30.0.6:36658 <http://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.mate@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/
>> zoo1@EXAMPLE.COM)
>> > >>> AFAIK the ZooKeeper client (after authenticated as zkclient/
>> > >>> zoo1@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 <
>> jain.arpit6@gmail.com>
>> > >>> 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 <
>> jain.arpit6@gmail.com
>> > >
>> > >>>> 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.mate@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
<
>> > jain.arpit6@gmail.com>
>> > >>>>>> 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/zoo1@EXAMPLE.COM
>> > >>>>>>> The client principal is : zkclient/zoo1@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 <http://172.30.0.6>: NEEDED_PREAUTH:
>> zkclient/
>> > zoo1@EXAMPLE.COM
>> > >>>>>>> <zoo1@EXAMPLE.COM> for krbtgt/EXAMPLE.COM@EXAMPLE.COM
>> > >>>>>>> <EXAMPLE.COM@EXAMPLE.COM>, Additional
>> pre-authentication
>> > requiredJan 13
>> > >>>>>>> 15:22:19 kdc krb5kdc[20](info): AS_REQ
(2 etypes {18
>> 17})
>> > 172.30.0.6
>> > >>>>>>> <http://172.30.0.6>: ISSUE: authtime
1578928939, etypes
>> > {rep=18 tkt=18
>> > >>>>>>> ses=18}, zkclient/zoo1@EXAMPLE.COM <zoo1@EXAMPLE.COM>
>> for
>> > >>>>>>> krbtgt/EXAMPLE.COM@EXAMPLE.COM <EXAMPLE.COM@EXAMPLE.COM
>> >Jan
>> > 13 15:22:19 kdc
>> > >>>>>>> krb5kdc[20](info): TGS_REQ (4 etypes {18
17 16 23})
>> 172.30.0.6
>> > >>>>>>> <http://172.30.0.6>: ISSUE: authtime
1578928939, etypes
>> > {rep=18 tkt=18
>> > >>>>>>> ses=18}, zkclient/zoo1@EXAMPLE.COM <zoo1@EXAMPLE.COM>
>> for
>> > >>>>>>> zkclient/zoo1@EXAMPLE.COM <zoo1@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 <http://172.30.0.3>: NEEDED_PREAUTH:
>> zkclient/
>> > zoo1@EXAMPLE.COM
>> > >>>>>>> <zoo1@EXAMPLE.COM> for krbtgt/EXAMPLE.COM@EXAMPLE.COM
>> > >>>>>>> <EXAMPLE.COM@EXAMPLE.COM>, Additional
>> pre-authentication
>> > requiredJan 13
>> > >>>>>>> 15:26:14 kdc krb5kdc[20](info): AS_REQ
(2 etypes {18
>> 17})
>> > 172.30.0.3
>> > >>>>>>> <http://172.30.0.3>: ISSUE: authtime
1578929174, etypes
>> > {rep=18 tkt=18
>> > >>>>>>> ses=18}, zkclient/zoo1@EXAMPLE.COM <zoo1@EXAMPLE.COM>
>> for
>> > >>>>>>> krbtgt/EXAMPLE.COM@EXAMPLE.COM <EXAMPLE.COM@EXAMPLE.COM
>> >Jan
>> > 13 15:26:14 kdc
>> > >>>>>>> krb5kdc[20](info): TGS_REQ (4 etypes {18
17 16 23})
>> 172.30.0.3
>> > >>>>>>> <http://172.30.0.3>: ISSUE: authtime
1578929174, etypes
>> > {rep=18 tkt=18
>> > >>>>>>> ses=18}, zkclient/zoo1@EXAMPLE.COM <zoo1@EXAMPLE.COM>
>> for
>> > >>>>>>> zookeeper/zoo1@EXAMPLE.COM <zoo1@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.mate@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 <
>> > >>>>>>>> ddiederen@sinenomine.net> 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 <
>> > >>>>>>>>> ddiederen@sinenomine.net> 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
>> > >>>>>>>>> >>
>> > >>>>>>>>>
>> > >>>>>>>>
>> >
>> >
>> >
>> > ________________________________
>> >
>> > CONFIDENTIALITY & PRIVACY NOTICE
>> > This e-mail (including any attachments) is strictly confidential
>> and may
>> > also contain privileged information. If you are not the intended
>> recipient
>> > you are not authorised to read, print, save, process or disclose
>> this
>> > message. If you have received this message by mistake, please
>> inform the
>> > sender immediately and destroy this e-mail, its attachments and any
>> copies.
>> > Any use, distribution, reproduction or disclosure by any person
>> other than
>> > the intended recipient is strictly prohibited and the person
>> responsible
>> > may incur in penalties.
>> > The use of this e-mail is only for professional purposes; there is
>> no
>> > guarantee that the correspondence towards this e-mail will be read
>> only by
>> > the recipient, because, under certain circumstances, there may be a
>> need to
>> > access this email by third subjects belonging to the Company.
>> >
>>
>>
>>
>> ________________________________
>>
>> CONFIDENTIALITY & PRIVACY NOTICE
>> This e-mail (including any attachments) is strictly confidential and may
>> also contain privileged information. If you are not the intended recipient
>> you are not authorised to read, print, save, process or disclose this
>> message. If you have received this message by mistake, please inform the
>> sender immediately and destroy this e-mail, its attachments and any copies.
>> Any use, distribution, reproduction or disclosure by any person other than
>> the intended recipient is strictly prohibited and the person responsible
>> may incur in penalties.
>> The use of this e-mail is only for professional purposes; there is no
>> guarantee that the correspondence towards this e-mail will be read only by
>> the recipient, because, under certain circumstances, there may be a need to
>> access this email by third subjects belonging to the Company.
>>
>
|