curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron McKenzie <mckenzie....@gmail.com>
Subject Re: multiple curator frameworks mixed authentication modes
Date Wed, 16 Dec 2015 21:25:01 GMT
Indeed!

I guess you could do some static synchronization, but I think that it would
be error prone and pretty ugly. I think that the ZK client is the sensible
place for it to be fixed. The constructor could presumably just take a flag
indicating whether authentication is desired or not.

On Thu, Dec 17, 2015 at 8:22 AM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:

> jinx
>
> On Dec 16, 2015, at 4:21 PM, Cameron McKenzie <mckenzie.cam@gmail.com>
> wrote:
>
> I would think that anything implemented on the Curator side would be prone
> to race conditions if there were multiple Curator instances running within
> a JVM instance. Because if we clear that global flag to make a connection
> for a Curator instance that doesn't want authentication at the same time
> that another instance wanting to create / reconnect a connection with
> authentication, one of them is going to potentially go wrong.
>
> I guess the simple solution for the initial poster (Dave) is to run in
> separate VMs, but I guess that's not an option?
>
> On Thu, Dec 17, 2015 at 8:18 AM, Jordan Zimmerman <
> jordan@jordanzimmerman.com> wrote:
>
>> Oh - that’s true. I didn’t think of that. Maybe we need a new feature
>> here.
>>
>> On Dec 16, 2015, at 4:15 PM, Cameron McKenzie <mckenzie.cam@gmail.com>
>> wrote:
>>
>> Would that cause problems on an attempt to reconnect (doesn't Curator
>> recreate the ZK client under some circumstances?)?
>>
>> On Thu, Dec 17, 2015 at 7:37 AM, Jordan Zimmerman <
>> jordan@jordanzimmerman.com> wrote:
>>
>>> I just check in the ZK code. It does:
>>>
>>> System.getProperty(Environment.JAAS_CONF_KEY)
>>>
>>> So, just manual set/clear this property before creating the Curator
>>> instance.
>>>
>>> -JZ
>>>
>>> On Dec 16, 2015, at 3:00 PM, Dave Ariens <dariens@blackberry.com> wrote:
>>>
>>> Sorry, don't follow.  Let me try and re-phrase:
>>>
>>> If I launch a JVM with -Djava.security.auth.login.config=jaas.conf
>>>
>>> and that jaas.conf contains:
>>>
>>> Client {
>>>   com.sun.security.auth.module.Krb5LoginModule required
>>>   useKeyTab=true
>>>   keyTab="dariens.keytab"
>>>   storeKey=true
>>>   useTicketCache=false
>>>   serviceName="zookeeper"
>>>   debug=true
>>>   principal="dariens@MY.EXAMPLE <dariens@my.example>";
>>> };
>>>
>>> When my application starts I instantiate a CuratorFramework object
>>> connection to a ZK cluster that authenticates new connections via
>>> SASLAuthenticationProvider and of course this works as expected.
>>>
>>> I now need to instantiate another new CuratorFramework object to another
>>> ZK cluster that does not perform SASL authentication and any attempt to
>>> get/set data results in the errors below.
>>>
>>> Is there a configuration that I can apply when instantiating
>>> CuratorFrameworks that will not automatically use SaslAuthentication when a
>>> JAAS login context is present?
>>>
>>> [2015-12-16 19:47:15,427] ERROR An error:
>>> (java.security.PrivilegedActionException:
>>> javax.security.sasl.SaslException: GSS initiate failed [Caused by
>>> GSSException: No valid credentials provided (Mechanism level: Fail to
>>> create credential. (63) - No service creds)]) occurred when evaluating
>>> Zookeeper Quorum Member's  received SASL token. Zookeeper Client will go to
>>> AUTH_FAILED state. (org.apache.zookeeper.client.ZooKeeperSaslClient)
>>> [2015-12-16 19:47:15,427] ERROR SASL authentication with Zookeeper
>>> Quorum member failed: javax.security.sasl.SaslException: An error:
>>> (java.security.PrivilegedActionException:
>>> javax.security.sasl.SaslException: GSS initiate failed [Caused by
>>> GSSException: No valid credentials provided (Mechanism level: Fail to
>>> create credential. (63) - No service creds)]) occurred when evaluating
>>> Zookeeper Quorum Member's  received SASL token. Zookeeper Client will go to
>>> AUTH_FAILED state. (org.apache.zookeeper.ClientCnxn)
>>> [2015-12-16 19:47:15,427] ERROR Authentication failed
>>> (org.apache.curator.ConnectionState)
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------
>>> *From:* Jordan Zimmerman [jordan@jordanzimmerman.com]
>>> *Sent:* Wednesday, December 16, 2015 2:39 PM
>>> *To:* user@curator.apache.org
>>> *Subject:* Re: multiple curator frameworks mixed authentication modes
>>>
>>> Check your code. There are no static/global values in Curator.
>>>
>>> -JZ
>>>
>>> On Dec 16, 2015, at 2:29 PM, Dave Ariens <dariens@blackberry.com> wrote:
>>>
>>> My Java application needs to talk to two ZK clusters.
>>>
>>> Cluster one is configured with
>>> `authProvider.1=org.apache.zookeeper.server.auth.SASLAuthenticationProvider
>>> SASLAuthenticationProvider` and cluster two is not.
>>>
>>> At first glance it would appear that this isn't possible as all curator
>>> frameworks instantiated in my JVM are attempting to perform SASL
>>> authentication when the JVM is launched with the JAAS configuration
>>> containing 'Client' configuration.
>>>
>>> Any chance I'm missing something or is this a known restriction?
>>>
>>>
>>>
>>
>>
>
>

Mime
View raw message