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 <[email protected]> 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> 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="[email protected] <mailto:[email protected]>"; >> }; >> >> 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 [[email protected] >> <mailto:[email protected]>] >> Sent: Wednesday, December 16, 2015 2:39 PM >> To: [email protected] <mailto:[email protected]> >> 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 <[email protected] >>> <mailto:[email protected]>> 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? > >
