You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@zookeeper.apache.org by Botond Hejj <Bo...@MorganStanley.com> on 2018/02/05 18:21:56 UTC
SASL jaas.conf principal="*" problem
Hi,
Java 8 introduced the possibility to use * for the principal in treadmill
which is great and would allow us to run treadmill behind multiple
interfaces and SASL would pick the right keytab.
Unfortunately this doesn't work in ZooKeeper I have dived in the code a bit
and what I have found is that ZooKeeper is using DIGEST-MD5 in that case
even though I don't use the DigestLoginModule. The reason for that is line
251 here:
https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/zookeeper/util/SecurityUtils.java
It falls back to Digest if the principal list is empty which is the case
when * is specified.
Why is that and why not the login type is checked?
Anyway this can only be fixed in a nonbackward compatible way or with a
flag in a backward compatible way.
I could prepare a patch.
I would just like to understand the reason behind the implementation. Is
there any particular reason why this fallback is there? What would the
implication if I remove that? If I understand the reason maybe I could
patch it without breaking backward compatibility.
There is also a comment: TODO: use 'authMech=' value in zoo.cfg.
Is there any jira or patch for that?
Regards,
Botond Hejj
Morgan Stanley | Technology
Lechner Odon fasor 8 | Floor 07
Budapest, 1095
Phone: +36 1 881-3962
Botond.Hejj@MorganStanley.com
Re: SASL jaas.conf principal="*" problem
Posted by Botond Hejj <Bo...@MorganStanley.com>.
Hi,
Thanks for the pointers. I was playing a bit with the code and I see no
easy way to improve this. The limitation looks to be in
the com.sun.security.sasl.gsskerb.GssKrb5Server. It needs to have a
specific principal.
It is an interesting feature to use * for the principal but it looks like
it can't be used with the sasl server.
I have to make a decision on deployment which principal to use. It is not
the end of the world fortunately.
I am now looking for the same thing in kafka and it has a similar problem
with * principal.
Anyway, thanks for taking the time and help.
Regards,
Botond
On Wed, Feb 7, 2018 at 6:03 PM, Martin Gainty <mg...@hotmail.com> wrote:
> MG>i agree.. DIGEST-MD5 (and not kerberos) seems to be default
> authentication for zookeeper
>
> SaslServer saslServer = Sasl.createSaslServer("DIGEST-
> MD5","zookeeper","zk-sasl-md5",null, login.callbackHandler)
>
> MG>to ask a dumb question..where is DIGEST-MD5.conf located in zookeeper
> binary distro?
> MG>or is it sufficient to supply DIGEST-MD5.conf parameters in jaas.conf?
>
> ________________________________
> From: Andor Molnar <an...@cloudera.com>
> Sent: Wednesday, February 7, 2018 10:29 AM
> To: user@zookeeper.apache.org
> Subject: Re: SASL jaas.conf principal="*" problem
>
> Hi Botond,
>
> I believe the guy who originally implemented this (Rakesh) can give some
> color to your question, but until that you could dig the original Jira:
> https://issues.apache.org/jira/browse/ZOOKEEPER-1045
> [ZOOKEEPER-1045] Support Quorum Peer mutual authentication ...<
> https://issues.apache.org/jira/browse/ZOOKEEPER-1045>
> issues.apache.org
> ZOOKEEPER-938 addresses mutual authentication between clients and servers.
> This bug, on the other hand, is for authentication among quorum peers.
>
>
>
> for more information.
>
> Other than that, if you believe that you can either fix the issue or
> implement it in a better way, your contribution will be highly
> appreciated and it would be very kind of you to open new Jira and new pull
> request on GitHub.
>
> We can discuss further details there.
>
> Thanks,
> Andor
>
>
>
>
>
> On Mon, Feb 5, 2018 at 7:21 PM, Botond Hejj <Botond.Hejj@morganstanley.com
> >
> wrote:
>
> > Hi,
> >
> > Java 8 introduced the possibility to use * for the principal in treadmill
> > which is great and would allow us to run treadmill behind multiple
> > interfaces and SASL would pick the right keytab.
> >
> > Unfortunately this doesn't work in ZooKeeper I have dived in the code a
> bit
> > and what I have found is that ZooKeeper is using DIGEST-MD5 in that case
> > even though I don't use the DigestLoginModule. The reason for that is
> line
> > 251 here:
> > https://github.com/apache/zookeeper/blob/master/src/
> java/main/org/apache/
> [https://avatars3.githubusercontent.com/u/47359?s=400&v=4]<
> https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/>
>
> apache/zookeeper<https://github.com/apache/zookeeper/
> blob/master/src/java/main/org/apache/>
> github.com
> zookeeper - Mirror of Apache Hadoop ZooKeeper
>
>
>
> > zookeeper/util/SecurityUtils.java
> >
> > It falls back to Digest if the principal list is empty which is the case
> > when * is specified.
> > Why is that and why not the login type is checked?
> > Anyway this can only be fixed in a nonbackward compatible way or with a
> > flag in a backward compatible way.
> >
> > I could prepare a patch.
> > I would just like to understand the reason behind the implementation. Is
> > there any particular reason why this fallback is there? What would the
> > implication if I remove that? If I understand the reason maybe I could
> > patch it without breaking backward compatibility.
> >
> > There is also a comment: TODO: use 'authMech=' value in zoo.cfg.
> >
> > Is there any jira or patch for that?
> >
> > Regards,
> > Botond Hejj
> > Morgan Stanley | Technology
> > Lechner Odon fasor 8 | Floor 07
> > Budapest, 1095
> > Phone: +36 1 881-3962
> > Botond.Hejj@MorganStanley.com
> >
>
--
Botond Hejj
Morgan Stanley | Technology
Lechner Odon fasor 8 | Floor 07
Budapest, 1095
Phone: +36 1 881-3962
Botond.Hejj@MorganStanley.com
Re: SASL jaas.conf principal="*" problem
Posted by Martin Gainty <mg...@hotmail.com>.
organised on coding considerations then config
start with easy to verify configuration parameters:
MG>$JRE_HOME/lib/security/java.security entries verification :
> MG>can you verify
> Context.SECURITY_AUTHENTICATION="DIGEST-MD5"
?
MG>can you verify authentication Principal is set to EITHER u as in
> Context.SECURITY_PRINCIPAL="u: cuser"
> MG>OR authentication Principal is set to DistinguishedName
> Context.SECURITY_PRINCIPAL="dn: cn=C. User, ou=NewHires, o=JNDITutorial"
?
MG>what is value of zookeeper.sasl.client.username System Property ?
Martin
______________________________________________
________________________________
From: Andor Molnar <an...@cloudera.com>
Sent: Tuesday, February 13, 2018 1:58 PM
To: user@zookeeper.apache.org
Subject: Re: SASL jaas.conf principal="*" problem
Sorry Marvin, I'm afraid I don't really get your point.
Unfortunately I'm not a Kerberos expert either. :(
I think the best would be to put together a Jira about your suggested
changes explaining them in an organized fashion and I'd be able to dig a
little bit deeper.
Thanks,
Andor
On Thu, Feb 8, 2018 at 9:16 PM, Martin Gainty <mg...@hotmail.com> wrote:
> Boton/Andor
>
> MG>a few questions on modifying Subject Principals
>
> MG>security manager must grant AuthPermissionHolder.MODIFY_PRINCIPALS_PERMISSION
> for your login
>
> MG>assume $JRE_HOME/lib/security/java.policy contains something like:
> grant {
> // There is no restriction to any algorithms.
> permission javax.crypto.CryptoAllPermission;
> //no restrictions to modifying Principals
> permission AuthPermissionHolder.MODIFY_PRINCIPALS_PERMISSION;
> ...
>
> MG>then ZK should pass SecurityManager MODIFY_PRINCIPALS_PERMISSION
>
> java.lang.SecurityManager sm = System.getSecurityManager();
> if (sm != null) {
> switch (which) {
> case Subject.PRINCIPAL_SET:
> sm.checkPermission(AuthPermissionHolder.MODIFY_
> PRINCIPALS_PERMISSION);
>
>
> MG>assuming you have -Djava.security.debug=ALL have you seen permission errors?
>
> MG>Zookeeper implementation consideration:
> MG>if ZK session is quiesced you may lose Principal credentials (as there
> is no serialization for credentials)
>
> "credentials associated with the <code>Subject</code> are not. Note
> that the "
> "< code>java.security.Principal</code> class does not implement
> <code>Serializable</code>. "
> "Therefore ALL concrete <code>Principal</code> implementations
> associated with Subjects MUST"
> "IMPLEMENT <code>Serializable</code>."
>
> MG>Zookeeper devs where are Zookeeper Principal concrete classes (which implement Serializable)?
>
> MG>Jaas.conf CallbackHandlers are *usually* one of predefined LoginModules:
>
> - JndiLoginModule
> <https://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/JndiLoginModule.html>
JndiLoginModule (Java Authentication and Authorization ...<https://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/JndiLoginModule.html>
docs.oracle.com
The module prompts for a username and password and then verifies the password against the password stored in a directory service configured under JNDI.
> - KeyStoreLoginModule
> <https://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/KeyStoreLoginModule.html>
KeyStoreLoginModule (Java Authentication and Authorization ...<https://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/KeyStoreLoginModule.html>
docs.oracle.com
Provides a JAAS login module that prompts for a key store alias and populates the subject with the alias's principal and credentials. Stores an X500Principal for the ...
> - Krb5LoginModule
> <https://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html>
Krb5LoginModule (Java Authentication and Authorization ...<https://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html>
docs.oracle.com
This LoginModule authenticates users using Kerberos protocols. The configuration entry for Krb5LoginModule has several options that control the authentication process ...
> - NTLoginModule
> <https://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/NTLoginModule.html>
NTLoginModule (Java Authentication and Authorization Service )<https://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/NTLoginModule.html>
docs.oracle.com
This LoginModule renders a user's NT security information as some number of Principals and associates them with a Subject. This LoginModule recognizes the debug option.
> - UnixLoginModule
> <https://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/UnixLoginModule.html>
UnixLoginModule (Java Authentication and Authorization ...<https://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/UnixLoginModule.html>
docs.oracle.com
This LoginModule imports a user's Unix Principal information (UnixPrincipal, UnixNumericUserPrincipal, and UnixNumericGroupPrincipal) and associates them with the ...
>
> MG>questions on Zookeeper org.apache.zookeeper.server.auth.DigestLoginModule
>
>
> MG>org.apache.zookeeper.server.auth.DigestLoginModule implements
> LoginModule
>
> public void initialize(Subject subject, CallbackHandler
> callbackHandler, Map<String,?> sharedState, Map<String,?> options) {
> //assume options is JAAS options
>
> if (options.containsKey("username")) {
> // Zookeeper client: get username and password from JAAS conf
> (only used if using DIGEST-MD5).
> this.subject = subject;
> String username = (String)options.get("username");
> this.subject.getPublicCredentials().add((Object)username);
> String password = (String)options.get("password");
>
> MG>since following is NOT overridden by ZK concrete class.. can we can
> lose credentials during session quiesce?
> this.subject.getPrivateCredentials().add((Object)password);
> }
> return;
> }
>
> public boolean login() {
> //Unlike Krb5LoginModule, we don't do any actual login or credential
> passing here:
> //authentication to Zookeeper is done later, through the SASLClient
> object.
>
> return true;
> }
>
> MG>DigestLoginModule::login authentication would happen @
> MG>ZooKeeperSaslClient.ZooKeeperSaslClient(final String
> serverPrincipal) which calls to createSaslClient below:
>
> MG>createSaslClient reference from ZK .\org\apache\zookeeper\client\ZooKeeperSaslClient.java
> synchronized private SaslClient createSaslClient(final String servicePrincipal,
> final String loginContext) throws LoginException {
> try {
> if (login == null) {
> if (LOG.isDebugEnabled()) {
> LOG.debug("JAAS loginContext is: " + loginContext);
> }
> // note that the login object is static: it's shared amongst ALL zookeeper-related connections.
> // createSaslClient() must be declared synchronized so that login is initialized only once.
> login = new Login(loginContext, new ClientCallbackHandler(null));
> MG>where ClientCallbackHandler is inner class
> login.startThreadIfNeeded();
> }
> Subject subject = login.getSubject();
> MG>Regular/Public/Private Principals *should* be contained with Subject (from login
> SaslClient saslClient;
> // Use subject.getPrincipals().isEmpty() as an indication of which SASL mechanism to use:
> // if empty, use DIGEST-MD5; otherwise, use GSSAPI.
> if (subject.getPrincipals().isEmpty()) {
> // no principals: must not be GSSAPI: use DIGEST-MD5 mechanism instead.
> LOG.info("Client will use DIGEST-MD5 as SASL mechanism.");
> String[] mechs = {"DIGEST-MD5"};
> MG>Login *contains* Subject *which contains* PublicCredentials/PrivateCredentials
> String username = (String)(subject.getPublicCredentials().toArray()[0]);
> String password = (String)(subject.getPrivateCredentials().toArray()[0]);
> // "zk-sasl-md5" is a hard-wired 'domain' parameter shared with zookeeper server code (see ServerCnxnFactory.java)
> saslClient = Sasl.createSaslClient(mechs, username, "zookeeper",
> "zk-sasl-md5", null, new ClientCallbackHandler(password));
> return saslClient;
>
>
> MG>instead of obtaining thru Private Creds via (String)(subject.
> getPrivateCredentials().toArray()[0])MG>confused on reason 4 hardcoded
> 'zookeeper' password referenced from above Sasl.createSaslClient?
>
> MG>$JRE_HOME/lib/security/java.security entries verification :
> MG>can you verify
> Context.SECURITY_AUTHENTICATION="DIGEST-MD5"
>
> MG>can you verify authentication Principal is set to EITHER u as in
> Context.SECURITY_PRINCIPAL="u: cuser"
> MG>OR authentication Principal is set to DistinguishedName
> Context.SECURITY_PRINCIPAL="dn: cn=C. User, ou=NewHires, o=JNDITutorial"
>
> MG>ZooKeeperSaslClient considerations:
>
> ZooKeeperSaslClient(final String serverPrincipal) is instantiated in
> org.apache.zookeeper.ClientCnxn.java
>
> String principalUserName = System.getProperty("zookeeper.
> sasl.client.username", "zookeeper");
> if(principalUserName!=null) zooKeeperSaslClient =
> new ZooKeeperSaslClient(
> principalUserName+"/"+addr.
> getHostString());
>
> MG>what is value of zookeeper.sasl.client.username System Property
> ?
> Martin
>
>
> ------------------------------
> *From:* Martin Gainty <mg...@hotmail.com>
> *Sent:* Wednesday, February 7, 2018 12:03 PM
> *To:* user@zookeeper.apache.org
> *Subject:* Re: SASL jaas.conf principal="*" problem
>
> MG>i agree.. DIGEST-MD5 (and not kerberos) seems to be default
> authentication for zookeeper
>
> SaslServer saslServer = Sasl.createSaslServer("DIGEST-
> MD5","zookeeper","zk-sasl-md5",null, login.callbackHandler)
>
> MG>to ask a dumb question..where is DIGEST-MD5.conf located in zookeeper
> binary distro?
> MG>or is it sufficient to supply DIGEST-MD5.conf parameters in jaas.conf?
>
> ________________________________
> From: Andor Molnar <an...@cloudera.com>
> Sent: Wednesday, February 7, 2018 10:29 AM
> To: user@zookeeper.apache.org
> Subject: Re: SASL jaas.conf principal="*" problem
>
> Hi Botond,
>
> I believe the guy who originally implemented this (Rakesh) can give some
> color to your question, but until that you could dig the original Jira:
> https://issues.apache.org/jira/browse/ZOOKEEPER-1045
[ZOOKEEPER-1045] Support Quorum Peer mutual authentication ...<https://issues.apache.org/jira/browse/ZOOKEEPER-1045>
issues.apache.org
ZOOKEEPER-938 addresses mutual authentication between clients and servers. This bug, on the other hand, is for authentication among quorum peers.
> [ZOOKEEPER-1045] Support Quorum Peer mutual authentication ...
> <https://issues.apache.org/jira/browse/ZOOKEEPER-1045>
[ZOOKEEPER-1045] Support Quorum Peer mutual authentication ...<https://issues.apache.org/jira/browse/ZOOKEEPER-1045>
issues.apache.org
ZOOKEEPER-938 addresses mutual authentication between clients and servers. This bug, on the other hand, is for authentication among quorum peers.
> issues.apache.org
> ZOOKEEPER-938 addresses mutual authentication between clients and servers.
> This bug, on the other hand, is for authentication among quorum peers.
>
>
> [ZOOKEEPER-1045] Support Quorum Peer mutual authentication ...<
> https://issues.apache.org/jira/browse/ZOOKEEPER-1045>
[ZOOKEEPER-1045] Support Quorum Peer mutual authentication ...<https://issues.apache.org/jira/browse/ZOOKEEPER-1045>
issues.apache.org
ZOOKEEPER-938 addresses mutual authentication between clients and servers. This bug, on the other hand, is for authentication among quorum peers.
> [ZOOKEEPER-1045] Support Quorum Peer mutual authentication ...
> <https://issues.apache.org/jira/browse/ZOOKEEPER-1045>
[ZOOKEEPER-1045] Support Quorum Peer mutual authentication ...<https://issues.apache.org/jira/browse/ZOOKEEPER-1045>
issues.apache.org
ZOOKEEPER-938 addresses mutual authentication between clients and servers. This bug, on the other hand, is for authentication among quorum peers.
> issues.apache.org
> ZOOKEEPER-938 addresses mutual authentication between clients and servers.
> This bug, on the other hand, is for authentication among quorum peers.
>
>
> issues.apache.org
> ZOOKEEPER-938 addresses mutual authentication between clients and servers.
> This bug, on the other hand, is for authentication among quorum peers.
>
>
>
> for more information.
>
> Other than that, if you believe that you can either fix the issue or
> implement it in a better way, your contribution will be highly
> appreciated and it would be very kind of you to open new Jira and new pull
> request on GitHub.
>
> We can discuss further details there.
>
> Thanks,
> Andor
>
>
>
>
>
> On Mon, Feb 5, 2018 at 7:21 PM, Botond Hejj <Botond.Hejj@morganstanley.com
> >
> wrote:
>
> > Hi,
> >
> > Java 8 introduced the possibility to use * for the principal in treadmill
> > which is great and would allow us to run treadmill behind multiple
> > interfaces and SASL would pick the right keytab.
> >
> > Unfortunately this doesn't work in ZooKeeper I have dived in the code a
> bit
> > and what I have found is that ZooKeeper is using DIGEST-MD5 in that case
> > even though I don't use the DigestLoginModule. The reason for that is
> line
> > 251 here:
> > https://github.com/apache/zookeeper/blob/master/src/
[https://avatars3.githubusercontent.com/u/47359?s=400&v=4]<https://github.com/apache/zookeeper/blob/master/src/>
apache/zookeeper<https://github.com/apache/zookeeper/blob/master/src/>
github.com
zookeeper - Mirror of Apache Hadoop ZooKeeper
> java/main/org/apache/
> <https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/>
[https://avatars3.githubusercontent.com/u/47359?s=400&v=4]<https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/>
apache/zookeeper<https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/>
github.com
zookeeper - Mirror of Apache Hadoop ZooKeeper
> apache/zookeeper
> <https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/>
[https://avatars3.githubusercontent.com/u/47359?s=400&v=4]<https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/>
apache/zookeeper<https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/>
github.com
zookeeper - Mirror of Apache Hadoop ZooKeeper
> github.com
> zookeeper - Mirror of Apache Hadoop ZooKeeper
>
>
> [https://avatars3.githubusercontent.com/u/47359?
> s=400&v=4]<https://github.com/apache/zookeeper/blob/master/
> src/java/main/org/apache/>
>
> apache/zookeeper<https://github.com/apache/zookeeper/
> blob/master/src/java/main/org/apache/>
> <https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/>
> apache/zookeeper
> <https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/>
> github.com
> zookeeper - Mirror of Apache Hadoop ZooKeeper
>
>
> github.com
> zookeeper - Mirror of Apache Hadoop ZooKeeper
>
>
>
> > zookeeper/util/SecurityUtils.java
> >
> > It falls back to Digest if the principal list is empty which is the case
> > when * is specified.
> > Why is that and why not the login type is checked?
> > Anyway this can only be fixed in a nonbackward compatible way or with a
> > flag in a backward compatible way.
> >
> > I could prepare a patch.
> > I would just like to understand the reason behind the implementation. Is
> > there any particular reason why this fallback is there? What would the
> > implication if I remove that? If I understand the reason maybe I could
> > patch it without breaking backward compatibility.
> >
> > There is also a comment: TODO: use 'authMech=' value in zoo.cfg.
> >
> > Is there any jira or patch for that?
> >
> > Regards,
> > Botond Hejj
> > Morgan Stanley | Technology
> > Lechner Odon fasor 8 | Floor 07
> <https://maps.google.com/?q=Lechner+Odon+fasor+8+%7C+Floor+07+%0D+%3E+Budapest&entry=gmail&source=g>
> > Budapest
> <https://maps.google.com/?q=Lechner+Odon+fasor+8+%7C+Floor+07+%0D+%3E+Budapest&entry=gmail&source=g>,
> 1095
> > Phone: +36 1 881-3962 <+36%201%20881%203962>
> > Botond.Hejj@MorganStanley.com
> >
>
Re: SASL jaas.conf principal="*" problem
Posted by Andor Molnar <an...@cloudera.com>.
Sorry Marvin, I'm afraid I don't really get your point.
Unfortunately I'm not a Kerberos expert either. :(
I think the best would be to put together a Jira about your suggested
changes explaining them in an organized fashion and I'd be able to dig a
little bit deeper.
Thanks,
Andor
On Thu, Feb 8, 2018 at 9:16 PM, Martin Gainty <mg...@hotmail.com> wrote:
> Boton/Andor
>
> MG>a few questions on modifying Subject Principals
>
> MG>security manager must grant AuthPermissionHolder.MODIFY_PRINCIPALS_PERMISSION
> for your login
>
> MG>assume $JRE_HOME/lib/security/java.policy contains something like:
> grant {
> // There is no restriction to any algorithms.
> permission javax.crypto.CryptoAllPermission;
> //no restrictions to modifying Principals
> permission AuthPermissionHolder.MODIFY_PRINCIPALS_PERMISSION;
> ...
>
> MG>then ZK should pass SecurityManager MODIFY_PRINCIPALS_PERMISSION
>
> java.lang.SecurityManager sm = System.getSecurityManager();
> if (sm != null) {
> switch (which) {
> case Subject.PRINCIPAL_SET:
> sm.checkPermission(AuthPermissionHolder.MODIFY_
> PRINCIPALS_PERMISSION);
>
>
> MG>assuming you have -Djava.security.debug=ALL have you seen permission errors?
>
> MG>Zookeeper implementation consideration:
> MG>if ZK session is quiesced you may lose Principal credentials (as there
> is no serialization for credentials)
>
> "credentials associated with the <code>Subject</code> are not. Note
> that the "
> "< code>java.security.Principal</code> class does not implement
> <code>Serializable</code>. "
> "Therefore ALL concrete <code>Principal</code> implementations
> associated with Subjects MUST"
> "IMPLEMENT <code>Serializable</code>."
>
> MG>Zookeeper devs where are Zookeeper Principal concrete classes (which implement Serializable)?
>
> MG>Jaas.conf CallbackHandlers are *usually* one of predefined LoginModules:
>
> - JndiLoginModule
> <https://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/JndiLoginModule.html>
> - KeyStoreLoginModule
> <https://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/KeyStoreLoginModule.html>
> - Krb5LoginModule
> <https://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html>
> - NTLoginModule
> <https://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/NTLoginModule.html>
> - UnixLoginModule
> <https://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/UnixLoginModule.html>
>
> MG>questions on Zookeeper org.apache.zookeeper.server.auth.DigestLoginModule
>
>
> MG>org.apache.zookeeper.server.auth.DigestLoginModule implements
> LoginModule
>
> public void initialize(Subject subject, CallbackHandler
> callbackHandler, Map<String,?> sharedState, Map<String,?> options) {
> //assume options is JAAS options
>
> if (options.containsKey("username")) {
> // Zookeeper client: get username and password from JAAS conf
> (only used if using DIGEST-MD5).
> this.subject = subject;
> String username = (String)options.get("username");
> this.subject.getPublicCredentials().add((Object)username);
> String password = (String)options.get("password");
>
> MG>since following is NOT overridden by ZK concrete class.. can we can
> lose credentials during session quiesce?
> this.subject.getPrivateCredentials().add((Object)password);
> }
> return;
> }
>
> public boolean login() {
> //Unlike Krb5LoginModule, we don't do any actual login or credential
> passing here:
> //authentication to Zookeeper is done later, through the SASLClient
> object.
>
> return true;
> }
>
> MG>DigestLoginModule::login authentication would happen @
> MG>ZooKeeperSaslClient.ZooKeeperSaslClient(final String
> serverPrincipal) which calls to createSaslClient below:
>
> MG>createSaslClient reference from ZK .\org\apache\zookeeper\client\ZooKeeperSaslClient.java
> synchronized private SaslClient createSaslClient(final String servicePrincipal,
> final String loginContext) throws LoginException {
> try {
> if (login == null) {
> if (LOG.isDebugEnabled()) {
> LOG.debug("JAAS loginContext is: " + loginContext);
> }
> // note that the login object is static: it's shared amongst ALL zookeeper-related connections.
> // createSaslClient() must be declared synchronized so that login is initialized only once.
> login = new Login(loginContext, new ClientCallbackHandler(null));
> MG>where ClientCallbackHandler is inner class
> login.startThreadIfNeeded();
> }
> Subject subject = login.getSubject();
> MG>Regular/Public/Private Principals *should* be contained with Subject (from login
> SaslClient saslClient;
> // Use subject.getPrincipals().isEmpty() as an indication of which SASL mechanism to use:
> // if empty, use DIGEST-MD5; otherwise, use GSSAPI.
> if (subject.getPrincipals().isEmpty()) {
> // no principals: must not be GSSAPI: use DIGEST-MD5 mechanism instead.
> LOG.info("Client will use DIGEST-MD5 as SASL mechanism.");
> String[] mechs = {"DIGEST-MD5"};
> MG>Login *contains* Subject *which contains* PublicCredentials/PrivateCredentials
> String username = (String)(subject.getPublicCredentials().toArray()[0]);
> String password = (String)(subject.getPrivateCredentials().toArray()[0]);
> // "zk-sasl-md5" is a hard-wired 'domain' parameter shared with zookeeper server code (see ServerCnxnFactory.java)
> saslClient = Sasl.createSaslClient(mechs, username, "zookeeper",
> "zk-sasl-md5", null, new ClientCallbackHandler(password));
> return saslClient;
>
>
> MG>instead of obtaining thru Private Creds via (String)(subject.
> getPrivateCredentials().toArray()[0])MG>confused on reason 4 hardcoded
> 'zookeeper' password referenced from above Sasl.createSaslClient?
>
> MG>$JRE_HOME/lib/security/java.security entries verification :
> MG>can you verify
> Context.SECURITY_AUTHENTICATION="DIGEST-MD5"
>
> MG>can you verify authentication Principal is set to EITHER u as in
> Context.SECURITY_PRINCIPAL="u: cuser"
> MG>OR authentication Principal is set to DistinguishedName
> Context.SECURITY_PRINCIPAL="dn: cn=C. User, ou=NewHires, o=JNDITutorial"
>
> MG>ZooKeeperSaslClient considerations:
>
> ZooKeeperSaslClient(final String serverPrincipal) is instantiated in
> org.apache.zookeeper.ClientCnxn.java
>
> String principalUserName = System.getProperty("zookeeper.
> sasl.client.username", "zookeeper");
> if(principalUserName!=null) zooKeeperSaslClient =
> new ZooKeeperSaslClient(
> principalUserName+"/"+addr.
> getHostString());
>
> MG>what is value of zookeeper.sasl.client.username System Property
> ?
> Martin
>
>
> ------------------------------
> *From:* Martin Gainty <mg...@hotmail.com>
> *Sent:* Wednesday, February 7, 2018 12:03 PM
> *To:* user@zookeeper.apache.org
> *Subject:* Re: SASL jaas.conf principal="*" problem
>
> MG>i agree.. DIGEST-MD5 (and not kerberos) seems to be default
> authentication for zookeeper
>
> SaslServer saslServer = Sasl.createSaslServer("DIGEST-
> MD5","zookeeper","zk-sasl-md5",null, login.callbackHandler)
>
> MG>to ask a dumb question..where is DIGEST-MD5.conf located in zookeeper
> binary distro?
> MG>or is it sufficient to supply DIGEST-MD5.conf parameters in jaas.conf?
>
> ________________________________
> From: Andor Molnar <an...@cloudera.com>
> Sent: Wednesday, February 7, 2018 10:29 AM
> To: user@zookeeper.apache.org
> Subject: Re: SASL jaas.conf principal="*" problem
>
> Hi Botond,
>
> I believe the guy who originally implemented this (Rakesh) can give some
> color to your question, but until that you could dig the original Jira:
> https://issues.apache.org/jira/browse/ZOOKEEPER-1045
> [ZOOKEEPER-1045] Support Quorum Peer mutual authentication ...
> <https://issues.apache.org/jira/browse/ZOOKEEPER-1045>
> issues.apache.org
> ZOOKEEPER-938 addresses mutual authentication between clients and servers.
> This bug, on the other hand, is for authentication among quorum peers.
>
>
> [ZOOKEEPER-1045] Support Quorum Peer mutual authentication ...<
> https://issues.apache.org/jira/browse/ZOOKEEPER-1045>
> [ZOOKEEPER-1045] Support Quorum Peer mutual authentication ...
> <https://issues.apache.org/jira/browse/ZOOKEEPER-1045>
> issues.apache.org
> ZOOKEEPER-938 addresses mutual authentication between clients and servers.
> This bug, on the other hand, is for authentication among quorum peers.
>
>
> issues.apache.org
> ZOOKEEPER-938 addresses mutual authentication between clients and servers.
> This bug, on the other hand, is for authentication among quorum peers.
>
>
>
> for more information.
>
> Other than that, if you believe that you can either fix the issue or
> implement it in a better way, your contribution will be highly
> appreciated and it would be very kind of you to open new Jira and new pull
> request on GitHub.
>
> We can discuss further details there.
>
> Thanks,
> Andor
>
>
>
>
>
> On Mon, Feb 5, 2018 at 7:21 PM, Botond Hejj <Botond.Hejj@morganstanley.com
> >
> wrote:
>
> > Hi,
> >
> > Java 8 introduced the possibility to use * for the principal in treadmill
> > which is great and would allow us to run treadmill behind multiple
> > interfaces and SASL would pick the right keytab.
> >
> > Unfortunately this doesn't work in ZooKeeper I have dived in the code a
> bit
> > and what I have found is that ZooKeeper is using DIGEST-MD5 in that case
> > even though I don't use the DigestLoginModule. The reason for that is
> line
> > 251 here:
> > https://github.com/apache/zookeeper/blob/master/src/
> java/main/org/apache/
> <https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/>
> apache/zookeeper
> <https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/>
> github.com
> zookeeper - Mirror of Apache Hadoop ZooKeeper
>
>
> [https://avatars3.githubusercontent.com/u/47359?
> s=400&v=4]<https://github.com/apache/zookeeper/blob/master/
> src/java/main/org/apache/>
>
> apache/zookeeper<https://github.com/apache/zookeeper/
> blob/master/src/java/main/org/apache/>
> <https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/>
> apache/zookeeper
> <https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/>
> github.com
> zookeeper - Mirror of Apache Hadoop ZooKeeper
>
>
> github.com
> zookeeper - Mirror of Apache Hadoop ZooKeeper
>
>
>
> > zookeeper/util/SecurityUtils.java
> >
> > It falls back to Digest if the principal list is empty which is the case
> > when * is specified.
> > Why is that and why not the login type is checked?
> > Anyway this can only be fixed in a nonbackward compatible way or with a
> > flag in a backward compatible way.
> >
> > I could prepare a patch.
> > I would just like to understand the reason behind the implementation. Is
> > there any particular reason why this fallback is there? What would the
> > implication if I remove that? If I understand the reason maybe I could
> > patch it without breaking backward compatibility.
> >
> > There is also a comment: TODO: use 'authMech=' value in zoo.cfg.
> >
> > Is there any jira or patch for that?
> >
> > Regards,
> > Botond Hejj
> > Morgan Stanley | Technology
> > Lechner Odon fasor 8 | Floor 07
> <https://maps.google.com/?q=Lechner+Odon+fasor+8+%7C+Floor+07+%0D+%3E+Budapest&entry=gmail&source=g>
> > Budapest
> <https://maps.google.com/?q=Lechner+Odon+fasor+8+%7C+Floor+07+%0D+%3E+Budapest&entry=gmail&source=g>,
> 1095
> > Phone: +36 1 881-3962 <+36%201%20881%203962>
> > Botond.Hejj@MorganStanley.com
> >
>
Re: SASL jaas.conf principal="*" problem
Posted by Martin Gainty <mg...@hotmail.com>.
Boton/Andor
MG>a few questions on modifying Subject Principals
MG>security manager must grant AuthPermissionHolder.MODIFY_PRINCIPALS_PERMISSION for your login
MG>assume $JRE_HOME/lib/security/java.policy contains something like:
grant {
// There is no restriction to any algorithms.
permission javax.crypto.CryptoAllPermission;
//no restrictions to modifying Principals
permission AuthPermissionHolder.MODIFY_PRINCIPALS_PERMISSION;
...
MG>then ZK should pass SecurityManager MODIFY_PRINCIPALS_PERMISSION
java.lang.SecurityManager sm = System.getSecurityManager();
if (sm != null) {
switch (which) {
case Subject.PRINCIPAL_SET:
sm.checkPermission(AuthPermissionHolder.MODIFY_PRINCIPALS_PERMISSION);
MG>assuming you have -Djava.security.debug=ALL have you seen permission errors?
MG>Zookeeper implementation consideration:
MG>if ZK session is quiesced you may lose Principal credentials (as there is no serialization for credentials)
"credentials associated with the <code>Subject</code> are not. Note that the "
"< code>java.security.Principal</code> class does not implement <code>Serializable</code>. "
"Therefore ALL concrete <code>Principal</code> implementations associated with Subjects MUST"
"IMPLEMENT <code>Serializable</code>."
MG>Zookeeper devs where are Zookeeper Principal concrete classes (which implement Serializable)?
MG>Jaas.conf CallbackHandlers are *usually* one of predefined LoginModules:
* JndiLoginModule<https://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/JndiLoginModule.html>
* KeyStoreLoginModule<https://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/KeyStoreLoginModule.html>
* Krb5LoginModule<https://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html>
* NTLoginModule<https://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/NTLoginModule.html>
* UnixLoginModule<https://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/UnixLoginModule.html>
MG>questions on Zookeeper org.apache.zookeeper.server.auth.DigestLoginModule
MG>org.apache.zookeeper.server.auth.DigestLoginModule implements LoginModule
public void initialize(Subject subject, CallbackHandler callbackHandler, Map<String,?> sharedState, Map<String,?> options) { //assume options is JAAS options
if (options.containsKey("username")) {
// Zookeeper client: get username and password from JAAS conf (only used if using DIGEST-MD5).
this.subject = subject;
String username = (String)options.get("username");
this.subject.getPublicCredentials().add((Object)username);
String password = (String)options.get("password");
MG>since following is NOT overridden by ZK concrete class.. can we can lose credentials during session quiesce?
this.subject.getPrivateCredentials().add((Object)password);
}
return;
}
public boolean login() {
//Unlike Krb5LoginModule, we don't do any actual login or credential passing here:
//authentication to Zookeeper is done later, through the SASLClient object.
return true;
}
MG>DigestLoginModule::login authentication would happen @
MG>ZooKeeperSaslClient.ZooKeeperSaslClient(final String serverPrincipal) which calls to createSaslClient below:
MG>createSaslClient reference from ZK .\org\apache\zookeeper\client\ZooKeeperSaslClient.java
synchronized private SaslClient createSaslClient(final String servicePrincipal,
final String loginContext) throws LoginException {
try {
if (login == null) {
if (LOG.isDebugEnabled()) {
LOG.debug("JAAS loginContext is: " + loginContext);
}
// note that the login object is static: it's shared amongst ALL zookeeper-related connections.
// createSaslClient() must be declared synchronized so that login is initialized only once.
login = new Login(loginContext, new ClientCallbackHandler(null));
MG>where ClientCallbackHandler is inner class
login.startThreadIfNeeded();
}
Subject subject = login.getSubject();
MG>Regular/Public/Private Principals *should* be contained with Subject (from login
SaslClient saslClient;
// Use subject.getPrincipals().isEmpty() as an indication of which SASL mechanism to use:
// if empty, use DIGEST-MD5; otherwise, use GSSAPI.
if (subject.getPrincipals().isEmpty()) {
// no principals: must not be GSSAPI: use DIGEST-MD5 mechanism instead.
LOG.info("Client will use DIGEST-MD5 as SASL mechanism.");
String[] mechs = {"DIGEST-MD5"};
MG>Login *contains* Subject *which contains* PublicCredentials/PrivateCredentials
String username = (String)(subject.getPublicCredentials().toArray()[0]);
String password = (String)(subject.getPrivateCredentials().toArray()[0]);
// "zk-sasl-md5" is a hard-wired 'domain' parameter shared with zookeeper server code (see ServerCnxnFactory.java)
saslClient = Sasl.createSaslClient(mechs, username, "zookeeper",
"zk-sasl-md5", null, new ClientCallbackHandler(password));
return saslClient;
MG>instead of obtaining thru Private Creds via (String)(subject.getPrivateCredentials().toArray()[0])MG>confused on reason 4 hardcoded 'zookeeper' password referenced from above Sasl.createSaslClient?
MG>$JRE_HOME/lib/security/java.security entries verification :
MG>can you verify
Context.SECURITY_AUTHENTICATION<http://Context.SECURITY_AUTHENTICATION>="DIGEST-MD5"
MG>can you verify authentication Principal is set to EITHER u as in
Context.SECURITY_PRINCIPAL="u: cuser"
MG>OR authentication Principal is set to DistinguishedName
Context.SECURITY_PRINCIPAL="dn: cn=C. User, ou=NewHires, o=JNDITutorial"
MG>ZooKeeperSaslClient considerations:
ZooKeeperSaslClient(final String serverPrincipal) is instantiated in org.apache.zookeeper.ClientCnxn.java
String principalUserName = System.getProperty("zookeeper.sasl.client.username", "zookeeper");
if(principalUserName!=null) zooKeeperSaslClient =
new ZooKeeperSaslClient(
principalUserName+"/"+addr.getHostString());
MG>what is value of zookeeper.sasl.client.username System Property
?
Martin
________________________________
From: Martin Gainty <mg...@hotmail.com>
Sent: Wednesday, February 7, 2018 12:03 PM
To: user@zookeeper.apache.org
Subject: Re: SASL jaas.conf principal="*" problem
MG>i agree.. DIGEST-MD5 (and not kerberos) seems to be default authentication for zookeeper
SaslServer saslServer = Sasl.createSaslServer("DIGEST-MD5","zookeeper","zk-sasl-md5",null, login.callbackHandler)
MG>to ask a dumb question..where is DIGEST-MD5.conf located in zookeeper binary distro?
MG>or is it sufficient to supply DIGEST-MD5.conf parameters in jaas.conf?
________________________________
From: Andor Molnar <an...@cloudera.com>
Sent: Wednesday, February 7, 2018 10:29 AM
To: user@zookeeper.apache.org
Subject: Re: SASL jaas.conf principal="*" problem
Hi Botond,
I believe the guy who originally implemented this (Rakesh) can give some
color to your question, but until that you could dig the original Jira:
https://issues.apache.org/jira/browse/ZOOKEEPER-1045
[ZOOKEEPER-1045] Support Quorum Peer mutual authentication ...<https://issues.apache.org/jira/browse/ZOOKEEPER-1045>
issues.apache.org
ZOOKEEPER-938 addresses mutual authentication between clients and servers. This bug, on the other hand, is for authentication among quorum peers.
[ZOOKEEPER-1045] Support Quorum Peer mutual authentication ...<https://issues.apache.org/jira/browse/ZOOKEEPER-1045>
[ZOOKEEPER-1045] Support Quorum Peer mutual authentication ...<https://issues.apache.org/jira/browse/ZOOKEEPER-1045>
issues.apache.org
ZOOKEEPER-938 addresses mutual authentication between clients and servers. This bug, on the other hand, is for authentication among quorum peers.
issues.apache.org
ZOOKEEPER-938 addresses mutual authentication between clients and servers. This bug, on the other hand, is for authentication among quorum peers.
for more information.
Other than that, if you believe that you can either fix the issue or
implement it in a better way, your contribution will be highly
appreciated and it would be very kind of you to open new Jira and new pull
request on GitHub.
We can discuss further details there.
Thanks,
Andor
On Mon, Feb 5, 2018 at 7:21 PM, Botond Hejj <Bo...@morganstanley.com>
wrote:
> Hi,
>
> Java 8 introduced the possibility to use * for the principal in treadmill
> which is great and would allow us to run treadmill behind multiple
> interfaces and SASL would pick the right keytab.
>
> Unfortunately this doesn't work in ZooKeeper I have dived in the code a bit
> and what I have found is that ZooKeeper is using DIGEST-MD5 in that case
> even though I don't use the DigestLoginModule. The reason for that is line
> 251 here:
> https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/
[https://avatars3.githubusercontent.com/u/47359?s=400&v=4]<https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/>
apache/zookeeper<https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/>
github.com
zookeeper - Mirror of Apache Hadoop ZooKeeper
[https://avatars3.githubusercontent.com/u/47359?s=400&v=4]<https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/>
apache/zookeeper<https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/>
[https://avatars3.githubusercontent.com/u/47359?s=400&v=4]<https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/>
apache/zookeeper<https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/>
github.com
zookeeper - Mirror of Apache Hadoop ZooKeeper
github.com
zookeeper - Mirror of Apache Hadoop ZooKeeper
> zookeeper/util/SecurityUtils.java
>
> It falls back to Digest if the principal list is empty which is the case
> when * is specified.
> Why is that and why not the login type is checked?
> Anyway this can only be fixed in a nonbackward compatible way or with a
> flag in a backward compatible way.
>
> I could prepare a patch.
> I would just like to understand the reason behind the implementation. Is
> there any particular reason why this fallback is there? What would the
> implication if I remove that? If I understand the reason maybe I could
> patch it without breaking backward compatibility.
>
> There is also a comment: TODO: use 'authMech=' value in zoo.cfg.
>
> Is there any jira or patch for that?
>
> Regards,
> Botond Hejj
> Morgan Stanley | Technology
> Lechner Odon fasor 8 | Floor 07
> Budapest, 1095
> Phone: +36 1 881-3962
> Botond.Hejj@MorganStanley.com
>
Re: SASL jaas.conf principal="*" problem
Posted by Martin Gainty <mg...@hotmail.com>.
MG>i agree.. DIGEST-MD5 (and not kerberos) seems to be default authentication for zookeeper
SaslServer saslServer = Sasl.createSaslServer("DIGEST-MD5","zookeeper","zk-sasl-md5",null, login.callbackHandler)
MG>to ask a dumb question..where is DIGEST-MD5.conf located in zookeeper binary distro?
MG>or is it sufficient to supply DIGEST-MD5.conf parameters in jaas.conf?
________________________________
From: Andor Molnar <an...@cloudera.com>
Sent: Wednesday, February 7, 2018 10:29 AM
To: user@zookeeper.apache.org
Subject: Re: SASL jaas.conf principal="*" problem
Hi Botond,
I believe the guy who originally implemented this (Rakesh) can give some
color to your question, but until that you could dig the original Jira:
https://issues.apache.org/jira/browse/ZOOKEEPER-1045
[ZOOKEEPER-1045] Support Quorum Peer mutual authentication ...<https://issues.apache.org/jira/browse/ZOOKEEPER-1045>
issues.apache.org
ZOOKEEPER-938 addresses mutual authentication between clients and servers. This bug, on the other hand, is for authentication among quorum peers.
for more information.
Other than that, if you believe that you can either fix the issue or
implement it in a better way, your contribution will be highly
appreciated and it would be very kind of you to open new Jira and new pull
request on GitHub.
We can discuss further details there.
Thanks,
Andor
On Mon, Feb 5, 2018 at 7:21 PM, Botond Hejj <Bo...@morganstanley.com>
wrote:
> Hi,
>
> Java 8 introduced the possibility to use * for the principal in treadmill
> which is great and would allow us to run treadmill behind multiple
> interfaces and SASL would pick the right keytab.
>
> Unfortunately this doesn't work in ZooKeeper I have dived in the code a bit
> and what I have found is that ZooKeeper is using DIGEST-MD5 in that case
> even though I don't use the DigestLoginModule. The reason for that is line
> 251 here:
> https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/
[https://avatars3.githubusercontent.com/u/47359?s=400&v=4]<https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/>
apache/zookeeper<https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/>
github.com
zookeeper - Mirror of Apache Hadoop ZooKeeper
> zookeeper/util/SecurityUtils.java
>
> It falls back to Digest if the principal list is empty which is the case
> when * is specified.
> Why is that and why not the login type is checked?
> Anyway this can only be fixed in a nonbackward compatible way or with a
> flag in a backward compatible way.
>
> I could prepare a patch.
> I would just like to understand the reason behind the implementation. Is
> there any particular reason why this fallback is there? What would the
> implication if I remove that? If I understand the reason maybe I could
> patch it without breaking backward compatibility.
>
> There is also a comment: TODO: use 'authMech=' value in zoo.cfg.
>
> Is there any jira or patch for that?
>
> Regards,
> Botond Hejj
> Morgan Stanley | Technology
> Lechner Odon fasor 8 | Floor 07
> Budapest, 1095
> Phone: +36 1 881-3962
> Botond.Hejj@MorganStanley.com
>
Re: SASL jaas.conf principal="*" problem
Posted by Andor Molnar <an...@cloudera.com>.
Hi Botond,
I believe the guy who originally implemented this (Rakesh) can give some
color to your question, but until that you could dig the original Jira:
https://issues.apache.org/jira/browse/ZOOKEEPER-1045
for more information.
Other than that, if you believe that you can either fix the issue or
implement it in a better way, your contribution will be highly
appreciated and it would be very kind of you to open new Jira and new pull
request on GitHub.
We can discuss further details there.
Thanks,
Andor
On Mon, Feb 5, 2018 at 7:21 PM, Botond Hejj <Bo...@morganstanley.com>
wrote:
> Hi,
>
> Java 8 introduced the possibility to use * for the principal in treadmill
> which is great and would allow us to run treadmill behind multiple
> interfaces and SASL would pick the right keytab.
>
> Unfortunately this doesn't work in ZooKeeper I have dived in the code a bit
> and what I have found is that ZooKeeper is using DIGEST-MD5 in that case
> even though I don't use the DigestLoginModule. The reason for that is line
> 251 here:
> https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/
> zookeeper/util/SecurityUtils.java
>
> It falls back to Digest if the principal list is empty which is the case
> when * is specified.
> Why is that and why not the login type is checked?
> Anyway this can only be fixed in a nonbackward compatible way or with a
> flag in a backward compatible way.
>
> I could prepare a patch.
> I would just like to understand the reason behind the implementation. Is
> there any particular reason why this fallback is there? What would the
> implication if I remove that? If I understand the reason maybe I could
> patch it without breaking backward compatibility.
>
> There is also a comment: TODO: use 'authMech=' value in zoo.cfg.
>
> Is there any jira or patch for that?
>
> Regards,
> Botond Hejj
> Morgan Stanley | Technology
> Lechner Odon fasor 8 | Floor 07
> Budapest, 1095
> Phone: +36 1 881-3962
> Botond.Hejj@MorganStanley.com
>