Re: SASL jaas.conf principal="*" problem

[Martin Gainty]

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 <mgai...@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 Subject are not. Note
> that the "
>   "< code>java.security.Principal class does not implement
> Serializable. "
>   "Therefore ALL concrete Principal implementations
> associated with Subjects MUST"
>"IMPLEMENT Serializable."
>
> 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

Re: SASL jaas.conf principal="*" problem

[Andor Molnar]

oginContext 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 <mgai...@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.o

Re: SASL jaas.conf principal="*" problem

[Martin Gainty]

st 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 <mgai...@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.h...@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=4]<https://github.co

Re: SASL jaas.conf principal="*" problem

[Botond Hejj]

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 <mgai...@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.h...@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=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.h...@morganstanley.com
> >
>



-- 
Botond Hejj
Morgan Stanley | Technology
Lechner Odon fasor 8 | Floor 07
Budapest, 1095
Phone: +36 1 881-3962
botond.h...@morganstanley.com

Re: SASL jaas.conf principal="*" problem

[Martin Gainty]

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.h...@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=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.h...@morganstanley.com
>

Re: SASL jaas.conf principal="*" problem

[Andor Molnar]

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 
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.h...@morganstanley.com
>